Tales of a Game Engine: A Simple Game

Here’s my first project for my game design class.  As it turns out, it was due far sooner than I thought, and I was extremely rushed.  It’s mostly just a proof of concept for the engine, as I spent a really long time fixing bugs with the engine, and I even scrapped my fancy but ultimately not thread-safe event system.  In the end, I like the new object system I came up with more anyway.  It’s extremely simple, and while it doesn’t have all the functionality of the fancy system, the lower overhead and ease of use make up for it.


  • Left click to push buttons, pick up coins.
  • Right click to drop food ($5).

The JAR download should be able to simply run if you have Java installed.

Download Runnable .JAR

We weren’t allowed to use images, only graphics primitives and text, hence the appearance.  The source download only includes the source, you’ll need a Java compiler to run it.  (Eclipse is free and awesome.  If you’ve never used Java before, you should try learning it!  It’s really easy to pick up, very user friendly feature set, and it has awesome documentation.)

Download Source

Some things I’ve learned so far about game engine design in Java:

  1. mouseInputListener, the class used to get mouse input, is extremely useful.  It took me a long time to implement it correctly, but once I figured out what I was doing wrong it was easy.  To use it, you must call 2 methods to add it to your window, not just one.  I used frame.addMouseListener at first.  This only adds events corresponding to mouse clicking, and can’t be used to track the motion of the mouse, so for a while I wondered why my mouse tracking events weren’t working.  Eventually I realized I also needed to use frame.addMouseMotionListener to track the mouse motion as well.
  2. Defining events and triggering them in each of your objects is cool, but you need to be careful you’re doing it in a thread-safe manner.  My first attempt had mouse events trigger events in objects directly, not really considering that since input is handled on a separate thread I’d run into all kinds of synchronization problems.  I spent several stress-filled hours trying to get rid of ConcurrentModificationExceptions, and eventually I decided to instead make the input events simply store input in a few arrays.  Before I let my objects access anything, I copy the stored input to a new array.  (The reason the input is copied to a new array before the objects can use it is that the input events can occur at any time, even when other code is being run.  I don’t want my input changing as the objects are using it, as that could lead to a huge variety of bugs.)
  3. Though object-oriented design is good, public static variables aren’t always bad.  I’ll admit to using them too much, but it was very nice to be able to get screen information from my Game class using Game.width.

The engine is of course buried beneath my messy game code, and it’s not as clean as I want it to be yet.  I did get a few really good new ideas from this project (the Context class for handling “rooms”), and finished my input system though.  Still a long way to go, but it is nice to know that it works as is.

Also, if anyone sees anything wrong with the way I’m using delta time, let me know.  It seems off/slow to me… I’ll have to run some tests.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: