Posts Tagged ‘game engine’

LD33 – Post-Morterm – Engine design

Posted by (twitter: @tehPHEN)
Thursday, 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:

Update about gist-txt: a text adventure engine

Posted by (twitter: @johnnyaboh)
Monday, March 16th, 2015 9:19 pm

Twelve days ago I posted about gist-txt: a tool I created to build text adventures.
Since then it grew with simple, but powerful, new features.

I’d like to cite some that could be really helpful to create non trivial adventure games:

The tool is still underdevelopment, but I think it’s almost ready and it would be great if you would like to use it to develop a game for the next Mini LD #58. I’m definitely going to use it to build a text adventure for the AdventureJam!

If you’re interested about gist-txt you can watch the repo at, I’ll also post periodic updates about its development at /r/gamedev.

A minimal tool to create text adventures

Posted by (twitter: @johnnyaboh)
Thursday, March 5th, 2015 11:55 am

Yesterday I published the very first version of a minimal tool to create and publish text adventures.
It’s called gist-txt and you can find the source code at

The inspiration for this project came from two pieces of software:

  1. Twine (, an open-source tool for telling interactive, nonlinear stories
  2. (, a simple viewer for code examples hosted on GitHub Gist

Tool’s features are very limited. What it does is basically reading GitHub public gists and handle links to browse between files of the gist (scenes in gist-txt’s vocabulary). The cool part is that you can create your text adventure simply by creating a new gist. This lets you easily share and track updates of your work (gists are git repositories). Another cool part of this tool is that the hosting is as simple as a specially crafted url: just share an URL in the form<your-gist-id> to let people play your game.

I made simple example gist at, this can be shared as a text adventure with the link

I’m going to use it to prototype text adventures, but I’d like to know what do you think about it and I’m looking forward to see what people could achieve with this minimal set of features.

Update 03/16/2015: I posted about tool’s updates and new features as of version 1.6.0.

Yamanu Game Engine 1.0

Posted by (twitter: @jonahisadev)
Thursday, July 17th, 2014 11:28 pm


A couple of days ago, I said I would make a game engine to better help the creation of 2D Java games, which is what I make, and I can tell you, this engine is SO helpful! The download, documentation, and source can be found here:

Take a look!


– Gandalf1209

LDML New engine!

Posted by (twitter: @TosicDev)
Thursday, June 5th, 2014 5:20 am

Hey, I built a new game engine: LDML, Try it out! :DDDDDDDDDD


Ludumdare 28

Posted by (twitter: @strong99)
Wednesday, December 11th, 2013 4:44 am

This will be my third year of Ludum Dare and I’m going to keep a live blog which can be found here.

This year I’ll be using InCourse® GameCreator. It’s  a webbased game engine developed by Islandworks and dubbed ‘GameCreator’. It’s made in HTML5 and such, it will be quite different from my previous entries which were made in C++ and the 3d graphics engine Irrlicht. It’s going to be a challenge to make a game using only 2d art :)

OS of choice: Windows 8

Game engine of choice: InCourse 2.0 – Gamecreator

Graphics: Photoshop/Illustrator

Audio: Audicity & Anvil.


I’ll post a “How did I do it” on the end as I did the last times.

Other year’s entries were: World Alone and Be the Villain.

Worldalone - the lost bedroom The deathray

Have a great Ludum Dare everyone!

BitmapCaching engine for upcoming ludum dare

Posted by (twitter: @jacklehamster)
Thursday, November 28th, 2013 6:54 am

Hey it’s Jack again,

So for he upcoming ludum dare, it is my understanding that we can use game engines that were produced before the 48h period. Since I’m planning to use mine, I wanted to release the code. It’s now on an open source license, and you can shoot me an email if you want some help on how to use it.

The engine simply consists of saving Flash vector drawings into a bitmap at runtime, and reuse it later. It’s a common trick for boosting performance in Flash, and I’ve been using it lately.

Can you use the Cryengine 3 in ludum dare?

Posted by
Thursday, April 11th, 2013 8:46 pm

hello! I was wandering, can i use the Cyengine 3 in ludum dare? and what would i do about the source code? give them the project file?

The Frank Engine

Posted by
Tuesday, December 4th, 2012 10:22 am

Howdy, Ludum Dare people! I’m an indie developer and I’ve been working on an opensource 2D game engine for a few years now called The Frank Engine. After being in the industry for over 10 years and working on so called “triple a” games with crippling iteration times and garbage code I decided to build my own dream engine from scratch in C++. One of the biggest problems with mainstream games is they focus too much on the final result and not enough on whether development process itself is fun. I wrote my engine so I could have more fun developing games in my spare time while also making faster progress. My philosophy is that a clean system with fast iteration is the key to having a fun process, and if the process is fun then chances are final result will be too.

It has some cool features like an integrated level editor, streaming worlds, dynamic lighting, Box2d physics, sub frame interpolation, a debug console, ogg vorbis music etc. So far it has been used for 3 Ludum Dare comps and several other projects. Probably the biggest project so far is “Faster Blaster” a Metroid/Blaster Master mashup. I plan to use it for Ludum Dare 25 and you can too if you want. Feel free to copy parts of it an use them in your own engine like my half life style debug console, it’s all fully open source!   Here are some links where you can get more info and video…

Open sourcing my game engine

Posted by
Wednesday, August 18th, 2010 10:37 pm

This will be my first time participating in a Ludum Dare.  I will be using a game development framework that I’ve been working on for a while now and finally decided to open source.  It’s written in C++ with DirectX rendering, Box2d physics, and Ogg Vorbis music.  Dev environment is Visual C++ Express 2010 and DirectX SDK.

There are some pretty nice features included like a built in level editor, huge streamable worlds, particle system, fixed step interpolation, gamepad support, and debug console.  It comes with a clean slate project to build off and an example game.  You read more on my website or the project page on sourceforge. It’s called Frank Engine.

[cache: storing page]