Jump to content
  • Advertisement
  • entries
  • comments
  • views

Over Engineering

Sign in to follow this  
Mike Bossy


The fun thing about my current code base is that I started it strictly as an educational excersize. A lot of the stuff I work on in my day job is on "Next-Gen" platforms so I've been dealing in the world of multi-processors. Unfortunately even though I have a technical background with a CS degree my current job is more heavily focused on project management/producing. That means I don't get to get my hands dirty into the fun stuff at work. So to get a real feel for what working on a multi-proc machine meant I set about creating a multi-threaded game engine on my own.

Now this engine didn't need to be doing any crazy Doom 3 graphics. After all I'm not really a graphics guru and I never planned on shipping anything with this engine. I was just looking for simple 2D graphics and some simple sound effects. With that in mind I set about making things as clean and simple as possible to allow for things to be done in parallel.

I've always been a fan of up front design and tackling things from an OO perspective but I decided early on that while I wanted my object model to be good I didn't want to over engineer. I didn't want to have to take every case into account when I did my first UML mock up. In my day job we've been using so called "Agile" development methods and it's really been great. It's taken a lot of those 4 hour long bitch sessions about "what method goes where for this object we might never use" out of the equation. You're left giving it your best shot on a first stab and adjusting on the fly as things change. Sounds a little scary but it actually works well in practice. And the reality is that you're going to have to change some things down the road anyways as things change. Why put all that lost work in up front when it keeps you from seeing forward progress?

So I started plugging away with some quick engine work and had a basic engine up in a few weeks using Direct Draw in DX7. After all I didn't need flashy graphics. Using this I whipped up a simple little game in only a few hours using some art assets I had from fiddling with MIDP games in a previous side project.

With this quick success I had convinced myself that over engineering is another thing that has killed my other side projects. I don't know how many hours I've wasted engineering some highly extensible system or design that ends up being useless. Just get to the rubber hitting the road.

Now this isn't to be confused with just sitting down blind and coding. I had a basic outline of what I wanted my engine to look like and went with it. To prove that my basic engine architecture was indeed robust I replaced my renderer with a new one using Textured Quads in DX8. The rest of my engine continued to function seemlessly. Better yet my snappy little game sample compiled first shot with no code changes and now had free hardware accelleration. How cool is that?

Here are a couple quick pics of that amazing mobile game running on a PC. Look at the brilliant developer art created in Gimp!!!

Amazing UI!!!!

I am not a UI Designer!

Asteroid Dodging Gameplay!!!

Watch out for those asteroids! And no you don't have any weapons of any kind. Just your agility.

Explosions even have sound!!

Oops. It got me.

The scary thing is that I went crazy on the multi-threading. I have almost every major system on it's own thread. So for this little 2D game I actually have 8 worker threads plus the main thread handling the windows loop. A little overkill but it served it's purpose of getting my brain around creating a multi-threaded game engine.

I promise I'll upload some screens from my current project soon. I'm just venting on my past few months now that I have this journal space.
Sign in to follow this  


Recommended Comments

You wanna make an entry or something about the techniques and design you used for your multi-threaded engine? I'm considering a few multithreaded game engine designs but it doesn't quite gel for me.

Share this comment

Link to comment
I agree with Ravuya.

How is the workload distributed between the threads? Does the engine handle them or does the user have to assign each thread a task? Have you tested the system to see what the magnitude of difference between single-threaded and multi-threaded?

Threads scare me :(

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!