I must confess, my original post on optimization of game levels was, well, incomplete and inaccurate. Optimizations were not fully complete. There were a lot of T-Junctions that were left behind after optimization (, Sandeep was probably the only person to catch that). However, I managed to remove those too. They were causing a lot of problems with A* navigation and I am glad they are gone! So here are the updated screens. Some extra level geometry has been added so the screens might not look exactly the same as the earlier post.
Just an update on the Doofus game and on what I have been working on for the past couple of weeks. The past couple of weeks have seen me seriously working at getting the triangle count down in the game levels. The tri count had been increasing steadily for the last few levels and it just started hitting on the FPS value real bad. That is why I had no option but to go for Triangle decimation. The amount of triangles for even moderately complex levels started turning out to be surprisingly high and most triangles were all but useless. The reason; Doofus 3D levels use brush based geometry and the tris are a result of successive CSG (Constructive Solid Geometry) splits. The more detail I added to the levels, the more redundant splits occurred with the brushes. Meaning the FPS started falling like a rock for arbitrarily complex levels.
The optimization technique I was working on reduces the number of triangles by a) Removing redundant vertices and b) Collapsing unwanted edges. Simple right, not quite. Triangle decimation turned out to be somewhat more complex than I had anticipated. Fortunately and after some real hard brainstorming I managed to get it working just as I wanted it to. Now in some situations the triangle count reduces to as much as 4%. But an average value of around 10 to 20 % is what I usually get. That is also quite significant to say the least. Thank God my effort has not been in vain after all. It was a real pain to get that working correctly. Check out the images below to actually see the optimizations at work.
I have also been working on completing the AI. Sorry but I don’t have screens for those, maybe the next time. The AI still needs some amount of tweaking to get things working perfectly. I am not saying too much at this point in time; maybe in one of my next posts I will get into more details. Hopefully I can finish this last pending thing in the game soon.
Just before logging off of the Gutsy, I tried running the 0.0.5 beta version of Doofus 3D via Wine and “Voilà”, it actually ran! On Linux, with no tweaks of any kind, no nothing! Obviously only with the OpenGL driver, Wine has near absent DirectX support so it was only OpenGL, but still I was like blown away. I didn’t even expect it to work and I must say I could see no performance issues. Almost the same speed as Windows. I ran most of the unit tests and managed to finish the first 7 levels without any problems (, didn’t try any more but I am sure they will work just as well). To be frank I didn’t expect the game to run, and I mean run at all, let alone with the same speed as Windows.
I had no idea Wine had no DirectX support. I guess it must be very difficult to port the DirectX APIs (, but who’s complaining when the engine can run on OpenGL just as well) . The engine logs show Wine hooks in the native OpenGL driver on Linux, so I guess there is no visible performance loss while running the game using OpenGL renderer via Wine.
Update (Dec 17th, 2007): After reading Dan’s comments and some experimentation I could in fact run Doofus 3D via the DirectX renderer. However, the DirectX renderer will not run out of the box and there might be other legal issues associated with it, which are as yet unclear. You can read the entire comments here. I like to thank Dan for pointing out the error in the above post, Wine does have DirectX 9 support.
I have had a lot of questions from people on the status and progress of the game. The favorite question is “When is the game going to get released?” I have a separate blog open for this but since I don’t put any technical stuff on that blog, I decided to throw in some more details on the things that are happening with the game. First, the game is on track and we are doing great thus far. Most of the team is contributing little to nothing at the moment. Except the beta testers, who are busy at work. So for the time I am pretty much pulling the programming side of things alone. There isn’t much left anyways but there are just too many small small things to take care of.
First the AI. It is not yet up to my satisfaction. Enemies sometimes get stuck into walls, fall off cliffs or behave weird. I don’t think this is going to be too much of an issue. Such issues are generally solved by clever heuristics and eliminating obvious redundant conditions. All entities in the O2 Engine’s AI module are handled by individual state-machines and are fully modeled on state transition logic. These redundant conditions are in fact eliminated quite nicely with the state logic, i.e. having a specific state to handle a specific condition. Also some tweaks here and there are due. I had initially feared that the AI would take significant CPU cycles, and since I am doing all shadow silhouette calculations on the CPU, the game would become significantly CPU bound. That is clearly not the case. The game does not go CPU bound except for some low end single core machines and you generally do not have any problems with CPUs 1.8 GHz and above. With shadows turned OFF, the game can run on a P III 1 GHz easy.
In fact I am finding things are quite the opposite. The game has difficulty pushing geometry on lower end graphics cards and is probably more fill rate intensive than I would have liked. Of course this is when running with shadow volumes ON. That was expected since stenciling, especially for stencil shadows, is the most time consuming activity for the GPU. The engine does aggressively cull out shadows when it can, and just yesterday I finished a new optimization technique that decimates shadow volumes for static geometry at the cost of some CPU overhead. Even so, stenciling can be suicidal on lower end cards with limited fill rate, especially when occlusion geometry has high polygon count. Having said that, I am getting an FPS of about 30-34 on a card like the old Geforce 6200 TC with everything from glow effects to full screen bloom turned on. For any higher level card and for that matter even a mid-range card, pushing Doofus 3D level geometry along with volume shadows is a walk in the park.
However, we are marketing the game as a casual game and as with most casual games, it must run with bare minimum hardware. Most casual gamers don’t have a clue what a graphics card is, or what an update of a driver means. They have nothing more than an on-board card. True, these days mother-boards do ship with ATI and NVIDIA chipsets, bit unfortunately not all. My main concern is the game running on on-board Intel cards. Intel cards are lousy, and that is putting it mildly. These cards can sometimes exhibit ridiculous behavior and are giving me maximum headaches as of now. A few days back I was running the game on a machine with an on-board Intel card and the game used to run at 10 FPS at a resolution of 640×480, and at a nice 34 FPS at a resolution of 800×600, then used to drop again for higher resolutions. Explain that! No it wasn’t some program running in the background. I stopped all programs and some services and disconnected from the internet. Still this wired behaviour.
The fact is the game needs to scale to hardware so that it can run even on crappy GPUs. This is easier said than done and my current task is to see that the game detects and adjusts itself to even the most basic graphics hardware. There are also issues which are too specific to cover here like driver issues, render-to-texture issues and things like that. I also need to work on further optimizations to juice out higher FPS values. In the meantime the beta testing is also throwing up new bugs. Fortunately there have been no major bugs like GPFs or crashes reported by any of the beta testers. The game ran on most of the systems tested thus far. Sometimes a little slower than expected, sometimes with a lot of z-fighting of shadows, but the main thing is it ran.
That’s about it. The march continues, and I hope I can wind things down slowly and come out of this almost infinite beta.
It’s been a very busy week. Not only on the coding side of things, but had to finalize some major business related issues. The progress on the game has been a tad bit slow on the coding side, but nothing that can’t be picked up in the coming week. I also had a run-in with a couple of senior colleagues/friends and had some interesting discussions on the future of the engine in general. (Things like an Editor/Scene-Builder for the Engine, future projects and things like that. Maybe in my coming posts I will elaborate further on that.) I generally take the Sunday off, but I am working today on some long remaining issues with the game.
For our entire game project the 3D modeling and animation package we have used is Blender. It was pretty much used to make the main character and all the mesh assets in the game excepting the world. We are using another software package for world creation and scene composition, but more on that later. I selected blender for variety of reasons. The most important is of course, it is free, but that was not the only reason for its selection. Don’t let the free thing fool you, blender is a mature piece software with features that can rival even the best 3D modelers out there. In fact some of the features like multires mesh modeling, UV unwrapping, multi UV unwrap and powerful animation system are are cutting edge and the very best.
The second most important reason why I selected blender is its amazing flexibility! OK, so if you have used blender then you might disagree with me. I said might, a veteran blender user might actually agree with me, but for some reason blender has got this nasty reputation of not having a very user friendly GUI. I tend to disagree with that view because it is biased. Yes blender has an unconventional interface that takes a little getting used to, but to say outright that it is bad just because of that, is judging a book by it’s cover. Anyways, that is an argument for other day.
As I said, I selected blender for its flexibility. Blender offers an amazing plug-in support. It supports a full Python plug-in system which is very easy to use. The plug-in system allows blender to be extended very very easily. In fact blender is fully written in Python and is open-source. That is an added bonus, it allows you to have a peek at the source if you want to or if you are stuck somewhere. I personally found blender to be very easy to extend via plug-ins. Python is one of my favorite languages because of its simplicity. No doubt my previous experience with Python also helped.
Since programming plug-ins for blender is easy, you can easily export blender assets into your custom formats. Blender already comes bundled with a lot of exporters and you can open the python code for one and have a look at it and maybe, modify one to suite your needs. However, to dabble with the code, you must have solid 3D graphics and 3D programming concepts. Blender offers very little help or documentation on its design, so you have to understand why certain things are the way they are.
The other thing that helps a lot is the huge blender community support. Help is always at hand, people are willing to help out. That is not to say that blender documentation is bad, it is really good, though I must say the plug-in system docs are a little bit cryptic. But on the whole using blender to create game assets has been a win-win situation for me thus far. I have included some screens of art assets created in blender and then used in the game.
For any blender noob (, that is not to say I consider myself a pro,) the best way to get started is the blender video tutorials. They guide you through properly and allow you get you hands set on the blender interface. After doing that it’s just a matter of following the blender documentation. That is all you actually need to get started with the software. Yes, it will take a great deal more to master it, but this should be enough to get any newbie started.
UPDATE: The O2 Engine has come a long way after this post. It is now is directly tied into content pipelines with modelers like Blender and is capable of achieving far better lighting than what is presented here. This post talks about lighting in a fixed function pipeline which is pretty old technology. The Doofus game is released and can be found at www.doofuslongears.com.
Some preview of the lighting technology used in the game. This is not an in-depth explanation of it, but is just a preview so don’t expect technical details here. Maybe sometime later, (I will fill in the details) or you can just ask and I will be glad to explain it.
The lighting in Doofus works on several levels, ie passes. The passes are then composited to give a final image. This technology is not revolutionary and I certainly haven’t invented anything new, but I have used in a clever way so that it can run even on old h/w without much difficulty. It also gives the scene a nice cartoon effect.
First the scene is rendered normally with the basic lighting of OpenGL or DirectX. The O2 engine abstracts over both APIs and can use any one. The results of basic lighting can be seen in this image. (Click on the images to see a larger version of that image.)
This type of lighting is pretty basic. The scene seems pretty bland and devoid of any real excitement. This lighting shown here is the default vertex based lighting given by the rendering APIs.
The real excitement comes to the scene when shadows get added to the scene. In case of the O2 engine and the Doofus game I am using Stencil Shadows. Stencil shadows give hard crisp edges. That goes nicely with the cartoon theme of the game. In the next image you can see the shadows added to the scene. Along with shadows I have added a extra brightening pass i.e. Portions not in shadows are brightened up. That gives an illusion of soft sunlight (, the kinda sunlight you have very early in the morning).
Shadows add cohesion and drama to the scene. You can see a stark contrast between the two images, the one above without and the one on the right with shadow. The “drabness” of the scene is gone.
Things don’t end here. To have actual sunlit environments you have to have a super-bright component to the sunlight. Meaning, if you watch actual sunlight you will see that it is extremely bright with a halo like effect created at each shadow’s edge. For this, the engine does on more pass and applies a bloom filter to the scene to emulate sunlight.
The resulting scene looks actually sunlit, with the sunlight shining off bright surfaces. Watch the shadows boundaries closely, you will see what I mean. Now the scene looks correctly lit by sunlight.
Finally I want to show how the engine displays the sun. Observe the image on your right. You can see the sunlight bleeding through the edges of the roof just like an actual sun would when viewed across occluding geometry and notice the sun rays filtering through. The engine uses a similar variation of the multi render pass system explained earlier to achieve this effect. Just comes off looking great!
All images are actual game images captured while running the game in real-time. You can find more images of the game in the gallery section on my site.