GMCG Inventory Engine Alpha 2

Over the weekend I worked some more on my inventory engine for the GMCG.  I finished a few more features, like picking up items from the game world and dropping items from containers.  I also fixed some bugs which caused unexpected behavior when trying to add or remove zero items.
Additionally, I shamelessly borrowed databot‘s idea of using strings as keys for item data.  Far, far better than using named constants.


GMC Topic


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.

GMCG Inventory Engine Alpha

Here’s an alpha of my inventory system.  Anything TES Oblivion’s inventory could do, it can do.  It has containers, individual item enchantments, picking up items.  Most of the stuff we need is implemented already, still need to do some testing and add a few features.  I normally wouldn’t post something this unfinished, but it seems that the GMCG team wants a more rapid development cycle.


Tales of a Game Engine: The Game Loop

I’m writing a game engine in Java for a university game design course.  The scope of the course is rather limited, and I could easily hack together a satisfactory game without a good engine.  However, since I’m interested in game design, I’m attempting to make a versatile, efficient engine that I can use for my future game design experiments.  I like learning new things, and I thought I’d post a log of the things I find interesting as I build this game engine so that others can learn from my experiences, successes, and mistakes.

This is my first game engine, and though I’m not new to programming, I am new to game development in Java.  By no means do I consider myself an expert.  This is all new and exciting to me, as I get to experience first-hand the kinds of decisions programmers have to make when designing an application.  One of these experiences I’m currently working on is the game loop.

Hypothetical Scenario:

Say you have a state-of-the-art computer, and you want to write a game for this computer.  If you have a basic update-then-render loop (what Game Maker does by default), no matter how fast of a computer you use, the number of updates will only equal your frames per second setting at best.  Increasing the number of frames per second under this system is the only way to increase the number of updates per second, but we have to keep in mind that monitors have a limit on how many frames they can render in a given second: after you set the FPS over that limit, you’re just wasting your time.  In a simple update-render game loop, using an FPS setting of 60 will give you 60 frames per second and 60 updates per second.  Any leftover time is spent sleeping, which is nice and friendly to other applications, but typically most of this time is wasted, as most users don’t play games and run CPU-intensive applications at the same time.

So, since I hate seeing time wasted, I decided I’d try a system I’d read about but never worked with before: Separating the update and the render steps.

The general idea:

Run at the goal fps, and use the remaining time to perform as many updates as you can.  If the previous system was update-render, this system could be described as update-render-update-update-update… you get the idea.

Why this is a good thing to do:

This is great for things like physics -specifically raster collision-checking- which increase in accuracy when run more often. It means that your game isn’t “wasting” large amounts of time, and depending on your engine’s structure, it is probably more efficient than using separate render and update threads.

The algorithm:

Each period of time (1/FPS, so about 30 or 60 or 75 times a second)
If there is any time left over,
     While there is enough time left,

Simple, isn’t it?  Using some logic and tuning (i.e. what “enough time” is), I’ve been able to get my (mostly-empty) game to run at 60 FPS while performing almost 200 updates per second. Worst case it performs the same as a system that links updates and rendering, best case you get a huge number of extra updates every second.

There you have it.  A simple algorithm for separating the frame rate and the update rate.  If all the “real” games are doing it, why can’t mine?

Further reading:

Website Link Index

This is an index of all the content I posted on my website before migrating to this blog. If a link breaks, email me and I’ll try to fix it. The website got a little messed up during the transition from Google Pages to Google Sites, so I apologize if it’s difficult to navigate.

Disclaimer: I no longer support most of the things below.  I wrote most of this a long time ago, and a lot of it was proof-of-concept stuff.

If you use something that requires credit, you must give me credit. If you want to use something in a commercial project, you must contact me (don’t worry, I haven’t turned down anyone yet.)

My favorites:

The rest: