The last few years of development (2018/08/06)
Hello again after a long time :)
I would like to summarize what happened in the past years of Resistance Force development. We were developing RF right into 2014, there was an improved unpublished version of the game, but since some things were in a state of flux it wasn't releasable.
At the time I was working on improving the physics and collision engine as I was unhappy with the Bullet physics engine. So I went into working on my own little physics library, only to realize that rigid body physics is much more about various hacks and that certain behaviors are inherent to it.
There was also an issue with the engine not being able to scale to "bigger" worlds, there was some work on occlusion based visibility checking, but it wasn't helping much really. Other parts were also cumbersome.
In addition to that, the asset creation was also very cumbersome. I've found some nice techniques for modelling, but it involved many manual steps between Blender and GIMP. I was able to work on some assets that way but quickly burned out with all the steps involved.
During 2015-2016 I went more into rethinking the whole thing, finding solutions to the problems encountered. For physics it was obvious that the classical rigid body approach wouldn't work with all the issues inherent to it. It works quite well on a macro level, but if you observe the details it's quite horrible and you can't easily control it. I've decided to go with the much simpler and easier to control Verlet integration approach, esp. when the main use case is ragdoll physics and some breakable stuff. The rest can be handled with a pure collision detection code.
Also got the idea for the new renderer and asset creation. I've been using the Subsurf modifier in Blender to make overall shapes of objects and then adding details at specific places by attaching the more detailed shape at specific places. Then I've created a lowpoly version that contained all the shapes involved and baked normalmaps from the more detailed shapes. Then I had to manually blend the normalmaps in GIMP, scissoring it by hand and merging. If I had to modify anything from the previous steps I had to redo the next steps.
The Subsurf modifier is nice but has several downsides. One can't mix well a coarse shape editing with details in one shape. That's why I went with the technique outlined in the previous paragraph. Other is that when you're changing the level of tesselation the overall shape is changing which is not good.
These issues made my way to abandon classic polygons for modelling and instead using the Bézier patches (including a fully automated UV mapping). These are very similar to Subsurf modifier in Blender, however the overall shape is basically the same no matter what tesselation level you choose. This is great for creating multiple LODs (level of details) for models.
The other issue of mixing coarse shape with details is just a tools issue. Previously I thought that 3D modelling should be external to the game engine. So I used Blender for 3D models, GIMP for texturing and a separate map editor for world modelling. But I've found that all this stuff is all tied very closely to the particular engine and having different renderers and handling, esp. when it's 3rd party tools that are not exactly aligned with your goals, is not a good idea.
So this time I went with an approach of a single engine that does both the editing (including the 3d modeller and the texture editor) and the normal game usage. As an interesting twist, the new renderer is based on software rendering even when used with GPU rendering. It turns out the software renderer can nicely handle visibility determination (including properly sorted translucent polygons) and either be used directly or just rendering nothing and instead feeding the GPU with the stuff to render (in a GPU friendly way of course, no individual polygons feeding).
Actually I'm quite amazed at the performance of the software renderer and it's capabilities, it achieves about 60-70 FPS in a 720p resolution on an old 2.4GHz quad core CPU (Q6600). All this while handling per-pixel cubemap effects and translucent polygons. We'll see if it will stay that way even further into the development, but I'm quite optimistic about it based on how it works. This will allow to have a very good compatibility on alternative operating systems as well as having a good fallback in case of GPU related troubles.
As for further development, I've decided to switch to a microblogging approach instead of the more traditional article based blogging. This will allow me to inform you about various development advances much more easily and more frequently. I think I've reached to a point where all the major new foundations were built and decided on and that there is just some pretty straighforward development path in front of me.
I will be posting the microblog entries on this address: http://www.resistanceforce.com/blog
So be sure to check it out from time to time if you're interested in Resistance Force development :)
1. peabeeleo (2018/08/31 22:02)
that are good news, keep the good work