Archive for the ‘ Programming ’ Category

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.

Download

GMC Topic

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.

Download

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)
Update
Render
If there is any time left over,
     While there is enough time left,
          Update
Sleep

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: