The fungine chronicles

A journal to both teach and document my work, for Chen

State of the game

on February 7, 2012

 

A lot of changes have happened since last summer. I’ve started work on a new game. Its a platformer, you collect things and solve puzzles. Here’s the current state of things right now:

feb 7 (number 1) [blog post]

feb 7 (number 2) [blog post]

feb 7 (number 3) [blog post]

The first change you should notice is that its all in stunning 3d. There’s a metric boatload and a half of things that’s changed since the last game.

The Renderer

I’m using geometry instancing to draw all of the platforms. Before I was making a separate draw call for each platform, which even though the level shown only has about 100 platforms, took too much time for my laptop to handle. Now they’re all drawn in one draw call.

I added a feature to my shader system that allows me to edit a shader and recompile it as the game is running. This means that you can change the shader in a provided text box and see your changes without having to save it. This is a reoccurring theme for my game, you can edit basically everything as the game is running. Shown here is a basic shader that does procedural texturing. It cuts up each platform into little squares with interleaved colours. I plan to use procedural texturing for everything in the game, since I can’t draw well and its just cool.

I also added a debug renderer for physics. It collects wireframe data from Bullet and then draws that on top of the level geometry. This allows me to see if the physical and graphical representations of stuff is in sync or not. The way I was handling this was rather simple, in my renderer I had code that was basically:

clearRenderBuffer()
clearDepthBuffer()

(*first pass: draw all shapes*)
renderBoxes instances positions

(*second pass: draw wireframes*)
clearDepthBuffer()
renderDebugLines debugLines

So debug rendering was hardwired into my renderer. Now I abstracted it so the renderer just processes a list of commands like [ClearDepth, ClearRender, DrawInstanced, ClearDepth, DrawMesh]. Now its a lot easier to make changes to the way I render things. This will allow me to do some cool post processing stuff later on.

 

The console

I’ve implemented a basic console that can handle about 20 commands. This was a nice side effect of my message based engine, all the functionality was already there so the console just basically parses text and then sends the appropriate message. I’m looking into turning it into a basic scripting language to make it more generalized and easier to add functionality to.

 

The future

I have a lot of plans for the future. There’s a ton of physics stuff that I want to add, like constraints, motors, springs, different materials. Then of course I’ll add a scripting language for the game objects, which may or may not be the same as the console script. There’s also plenty of graphical stuff I’d like to explore, I’ve only scratched the surface with procedural textures, then there’s lighting and shadows, post processing effects like depth of field, motion blur.


Leave a comment