About this blog
Current reflections and thoughts by Martin Nordholts aka Enselic
Entries in this blog
I'm just wondering. In case someone does, I might put some time in this.
While you're not reading this, check out this awesome picture of the sun.
My GDNet+ membership expires in a few hours, and I thought I'd make a last (and among the first :P) journal update, only because I still can.
Umm.. so.. well..
Ah yes, I've got my first programming job, I hope it turns out well and that I will still have time to finnish my studies at LTH.
Btw, I wonder if the images at my GDNet webspace will be wasted?
Hello there all Journal enJoyers!!
Yesterday I watched a gaming program on one of the swedish public-service TV channels. They had an interview with a swedish gamedevelopment company named Avalanche Studios with like 60 employed workers about their soon to be relased game, and their graphics engine. The engine looks amazing. Check out the pictures and videos at their site.
I just decided to do another gameengine rewrite of my current project, Spatra 2, written in C#.
This must be the, like what, fourth rewrite? I recently rewrote it from the noobish while(notQuit) run; structure to the Kernel/Task structure presented by superpig in his awesome Enginuity series
Moving to a taskbased engine made it *so much more* scalable and modifiable. For instance, if you want a fancy explosion, you just create a RenderExplosionTask which deletes itself from the Kernel after the simulation is done. So the only thing you do is
And the object renders an explosion, and after it is done, it just deletes itself with
// In RenderExplosionTask.Update()
if (explosionRadius > 500.0f)
I.e. no if (shouldRenderExplosion) updateAndRenderAllExplosions(); mess in some gameloop somewhere.
Anyway, I have tasks that handles core functionallity of the engine. Like there's a InputTask that updates the state of the input, but as it is now, it is hardcoded for DirectInput, so the rewrite will consist in creating generic interfaces for the core classes, and implementing these interfaces with API specific solutions. That way porting the game to Linux will be a *lot* easier since it will only consist of writing a Linux-based inputhandler that implements the generic Input-interface.
Now go rewrite your engine too!
I've completly forgotten that I have one of these journals.
Anyway, I don't have big news so often, but now I have:
I've been contacted by a graphics artist!
The graphcis guy saw my Help Wanted Post.
That means that my >1 year game project will soon be to an end!
Today I also went through the ~60 C# game engine/game source files and added a GPL note on top of them all. I also cleaned a lot of code, and removed obsolete 2005-05 code which still were left in some files. There's not much to code now, I am just waiting for the graphics guy to do his part.
My hope now is that the graphics guy have the same kind of result in mind as I have (his portfolio contains absolutly amazing artwork), and that he don't abandon me. He is after all doing this for free. I offered him a symbolic sum, but he said he just wanted to have something to do.