LD33 – Post-Morterm – Engine design

Posted by (twitter: @tehPHEN)
August 27th, 2015 5:56 am

Thank you all for this great jam! This was my Ludum Dare. I barely made something ‘playable’ and I had a blast doing it! (Link at the end)

Things I’ve learned about designing a fully functional game engine. There’s tons of subtle things I’ve learned over the years of programing and the 4 months I’ve been developing a silly 2D engine.

First of all, if you want to make a game. Don’t start with the engine. Start with the game!  I’ll reiterate this again!

There’s a very distinct lesson in there about making engines. This post-mortem is all nerdy-programmer engine problems talks. So unless you’re into that, this post isn’t for you!

So for those of you crazy enough to venture down this road I’m here to talk about my experience about using my engine.

Why do this?
I find there is a unique design problem when designing a system for games. With games the problem set is very distinct, yet no one has one right way of doing it. I find it fun trying to approach these problems in different ways, and learn why they were made.

Second reason: I love C++, and wanted to try some of the new features introduced in C++11.

Why Ludum Dare?
I’ve been working on my current engine for about 4 months now (every odd weekend, and weekdays.) I haven’t actually made anything out of it, other than making some squares collidable on screen.

I feel having a solid criteria such as making a playable game in 72 hours seemed like good way to test drive your engine, as a great way to see if your original designs worked the way you wanted to. The timing of Ludum Dare was just right, so why not I said!

My engine of course wasn’t done going into this, so this was as good as a train wreck as you think it might of been for someone’s first ludum dare.

So what are your take home lessons?

Lesson One:

A modern ‘game engine’ isn’t just the code you write to get your game running, but it should encompass all the tools and built-in scripts to get the dirty work out of the way.

My engine had none of these said tools. No tools to align hitboxes, No tools to preview how large this magic ‘64’ units is on screen, no tools to preview the scene/camera in game. I had to manually write the code to spawn game objects in a particular position on the screen (translating from game cords to screen coords).

There’s a ton of things established game engines provide, and I fear should anyone designing a game engine should address these problems to even be considered a modern feasibility useable engine.

This lack of tools caused Iteration time during the ‘working on the game’ part was extremely slow. I either had to: Program in a solution (which has nothing to do with the game itself) or Hack together some solution that solves it for this game, and doesn’t really apply to any other game. Hacks made my stomach churn as I *knew* I’m going to remove this code as it really doesn’t belong in the *engine*.

Solution: none other than to provide plenty of tools for your designers and developers. Low level engine details should be left for the crazy people like me to work on. Things like game logic, game rules, positioning hitboxes and animations should be done in tools designed for the engine. Even the engine itself could be a tool if designed well.

Lesson Two:
A modern  ‘game engine’ should have fast iteration times in every aspect of design.

I knew this would be a problem, so I introduced a game object serializer. I can modify the base version of a game object in plain tex, reload the game and bam! the object has been changed.

Unfortunately, this was strictly just that, one game object, one file. My game had hundreds of trees and chickens flying everywhere. It just wasn’t feasible to do everything using the serializer, so some values *had* to be computed at run time.

Every time I wanted to change how fast something spawned on screen, I had to either: Finish writing the serializer to support loading in this value at run time (this could of taken precious hours!). Or change a magic static number and re-compile a small portion of the engine (this took 2-5 minutes).

That wasn’t bad, until I realized things spawned too slow. *recompile*
Still too slow *recompile*
Then I made everything collidable, now things spawned too fast.  *recompile*
Then I …

You get the point, those add up! Game design truely at its core is iterative. 

Lesson 2.5:
A modern  ‘game engine’ should have fast iteration times in every aspect of design.

Reiterating this again, fast iteration is key! A engine should not impede its designers!

Next thing to boot, was animations! Boy, changing a file name was a PITA. Every time I renamed my file, I had to re-open and re-edit all my game object text files. To boot ontop of that, I couldn’t think of a elegant way to frame-rate using the serializer, so I just hardcoded the animation frames in code.

This meant, each time I added a new frame of animation, I had to update all text files that references this new image, recompile the engine itself because I hardcoded the frame time for this animation.

The amount of work it took to get a 5 frame animation in was so much work, I *completely* abandoned animations for the sake of getting something done.

I think Scripting will solve this issue. Implement a way to talk about your game objects, modify your game objects, and do all game related logic in your scripts. I really regret not prioritizing having a fully scriptable elements in my game prior to entering this.

@indieprogram recommended me Squirrel (a variant of LUA, used by tonnes of valve games).  I’ll definitely look into this!

Lesson Three:
A modern ‘game engine’ should not be a PITA to deploy to your users.

I knew NOTHING about releasing binaries on Windows. Boy, does windows make it hard! In the end I couldn’t solve the issue. I had to get users to install the Visual Studio 2015 ‘Universal Common’ Runtime libraries.

“Universal Common” my butt!

My engine was only 2megs big, half of it being game assets! Why do I have to include a 14MB microsoft installer for it to work on a Windows machine!?!

This was something I didn’t consider going into the Jam, and boy. I spent hours on hours trying to get a half decent solution.

I have yet to look into ways of solving this, short of not including standard runtime libs.

Wind down:
It was a blast for my first Ludum Dare. I honestly think I would of had a better game if I dropped my engine and paired up with someone and just worked on game in established engine (such as GameMaker, RPGMaker, Unity, Unreal… anything really where I didn’t have to struggle with lack-of-tooling)..

The game design (or what little of game designing I did) were quite fun. Things such as Brainstorming, Player Feedback, General “look” and “feel” of the game where things I touched on this Jam!

I found it especially engaging to come out to my local meetup group (@calgarygamedevelopers) to brainstorm and work on ideas. I highly recommend going out to these and engaging with your local community!

I’ll likely keep working on my engine post-jam as I’m having tons of fun. I’ll hopefully bring it to another Competition with a better game next time :0

Feel free to hit me on twitter! @tehPHEN

If you want to see the results of this checkout:

http://ludumdare.com/compo/ludum-dare-33/?action=preview&uid=54976

Tags: , ,


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]