GDC is behind us. Back to work…
So we managed to get that GDC demo out the door in due time, and from what I gather it has done really well at GDC. The 3DVIA folks had it running at the booth with a competition playing a 60 (or was it 90?) seconds level.
I didn’t get to go to GDC myself, as I had my ski vacations planned the same week, and it was all organized back in december (which was before we actually even pitched the game idea to the 3DVIA team). Third year in a row without attending GDC, I definitely need to fix that next year 
Not that I didn’t enjoy my vacation, of course (nothing beats skiing with the kids). Anyway, Klaus was there, and maybe he’ll post something about it. I got some live coverage from him, through photos and videos, and the game looked pretty good at the booth, displayed on that funky huge screen powered by an AMD/ATI monster graphics card (running a 5760×2160 res).
We delivered the playable version on friday, march 5th, which was close to a week before the show. Now how many times has that happened in my professional life, delivering a demo for a tradeshow more than 6 hours before the show actually starts ??? 
Anyway, now we’re back to work, with a little more time to plan upcoming tasks. I spent this week refining our internal level design tool (see screenshot), running on Virtools 5. We have 20 levels to make for the final game, so having a solid tool in the hands of game designers as early as we can is certainly a good investment.
Next week, I’ll go back to the game itself, with a fresh eye on the code that’s already there. In terms of gameplay, I don’t see major changes happening, as we have something that works and the is fun, so it’s likely that I’ll spend a lot of my time on polishing and polishing and polishing. I’m also eager to see what people in the community make of the game, and the kind of ideas that they’ll throw at us.
One key area for polishing will definitely be rendering speed. Keep in mind that what’s available at this point on the site (both the playable version and the related source code) was intended to run on a powerful machine, so we didn’t really bother much about optimization. Now, the final game is intended to run on facebook, so we’ll have to support a much wider range of hardware (including the legendary slow Intel integrated chipsets that come with probably half of the laptops sold in the world). Fortunately, there’s a lot of untapped potential for speeding up the game. I don’t have enough experience with the engine to know for sure, but here’s what comes to mind:
- single pass shading (right now we have ambient lighting + 2 directional lights, so that’s three shading passes, I’m confident we can do the same in a single pass with some custom shader code)
- LOD. I haven’t played with it yet, but it seems 3DVIA Studio has some simple integrated LOD system for switching meshes. It’s likely that the depth of field effect will also help hiding the LOD popping. For low LOD, we can also use a simpler shader (no bump, no specular lighting?)
- material packing –> not sure how much we want to focus on that, but packing textures (at least for low LOD) should help reducing the number of materials switching and draw calls
- effects switches, to turn off some of the effects on low end hardware. Right now the game has a brute force anti aliasing through super sampling, which runs fine on my GeForce9600, but will definitely kill any low end machine’s framerates.
- texture size. To be honest, we haven’t even looked at how much video ram the game uses Not that we have that many textures either, but maybe on low end hardware we’ll have to slash texture resolution a bit to improve speed and avoid texture swapping
Targetting facebook is a real challenge for any 3D games, so I’m eager to see how a combination of the above will help the game fly even on very basic PCs… Wait and see…
[...] you probably discovered from reading Francois’ latest post, we are fresh back from [...]