Progress update…

A Complete Game

Over the last several months, I’ve been working primarily with web-related technologies (basic HTML, CSS, PHP, some CMS customization, etc.). In my spare time, I’ve been playing around with the more graphical / game-aspects HTML5. I’ve written a couple “draft” quality JQuery plug-ins: one for basic image effects (saturation effects, etc.), a seamless image tiler / previewer, a seamless image generator, a fire effect, and one more thing: a complete game.

I’m interested in graphics, engine architecture, and games, but often find myself exploring a specific technology rather than trying to create something “complete.” In other words, I tend to take a deep and narrow approach to coding rather than a broad, shallow approach.

My goal this time is to produce a small, maybe-not-that-impressive, but complete game. I realize I’ve never really done this before…

Gravity Tide

I’ve decided to code name it Gravity Tide. So far:

• 2D Graphics via an HTML Canvas element
• Music via the HTML5 Audio element (and via opengameart.org since I’m not a musician!)
• A main menu and credits screen
• 1 Level currently…

Once I add a splashscreen, load/save functionality, a couple more levels, a few power-ups, a few new enemies, end-of-level “bosses”, and a generic minimal game story, I think it – again, may not be epic quality – but it will be a complete game.

As mentioned in the prior post, I’ve taken a break from the lower-level graphics programming that I’ve been posting about on this blog.

I’ve started a small project creatively called “Adventure”.  The vision (which isn’t very well-defined at this point) is to create a small game that is some sort of cross-breed between a linear, story-driven adventure game (e.g. King’s Quest) and a simulation game (e.g. SimCity).  What exactly this means will evolve, but overaching theme is to create a “complete” engine that heavily utilizes existing third-party toolkits, is part “sim” and part “story.”  I want to take some time away from a single low-level component and spend more time on understanding the big picture – not to mention honing my skills battling the Not Invented Here tendency many developers, my self included, seem to have.

About Adventure…
As I mentioned, completeness is a higher priority than anything else.  Therefore, I’ve start out simple with version 0.0 being a simple text adventure game.  In the current incarnation there are only a half dozen rooms and the player simply needs to figure out the right commands to enter in order to win.

(Needless to say, with a name like “Adventure”, I’ve  put creativity in the game concept and story on the back burner as well.)

About the Technology…
While it is a simple, text-based game at this point, I am trying to build a solid base to expand it into a more technically noteworthy game.  For example, the build system uses a nested CMake hierarchy.  The code is linking against Boost, which opens up a lot of doors for reuse of some solid, useful code.  The game data is loaded from Lua files which allow for custom scripted actions in each room.  

The Adventure code itself is not much, but the intention is to establish a good base to build upon where code is added, to replaced, as more advanced functionality comes on-line.  I intent to spend a significant amount of time building a very clean base so that the architecture evolves fluidly.

Architectural Concepts

The game architecture at this point revolves around three key concepts.  They are fairly simple, but the interesting part is that even though they are simple, it’s quickly apparent how these concepts allow for a fairly complex game system to be constructed.

Cell
A Cell is a self-contained part of the game world.  The player is in one and exactly one Cell at any point during game play.  The only way to exit a Cell is via a well-defined connection to another Cell.   Any actions that take place by the player are local to that Cell.

These restrictions keep the game space well-defined so that the game simple to code for, stable, and logical.  Of course, exceptions to these rules (for example, some actions may affect other Cells) but as a general guideline this works well.

This concept works well for a single text-based game, but it also should works for a  graphical game.  The cell is basically the current “area” whether that’s a single enclosed room or a large outdoor map.  The concept can be expanded upon by making Cells into a heirarchy or expanding the notion of locality of action to chain to neighboring cells to an N-th degree.

Action
The next concept is an Action.  An Action is simply the user doing something that causes the game world to react.  Quite simple.

In the text-based world, the Action is usually just a command like “get”, “look”, “listen”.  It’s a verb that – depending on the verb – may act upon a particular Entity in the Cell or act upon the Cell itself directly.

In a graphical world, the Action may include additional details implicit from where in particular the player is located or looking.  However, the basic notion concept of a single discrete Action, with accompanying Entity and some details about the Action, more or less translate equivalently whether it is text or graphics.

Entity
An Entity is an object in a Cell that can be receive an Action.  This may be a non-playable character, a lamp, a whisp of fog – it’s anything that an Action can be applied to.

State of the Code

The current build has fairly decent starting points defined for Cells and Actions.  Next is a good, generic, scriptable Entity concept.

Recently added the ability to dynamically reload the game data while in game.  It stores the file modification time of each cell it loads and reloads and newly modified files upon an update command.   Given that the system is using reference counted boost::shared_ptr<> objects, this works correctly even if the cell that the player is actively in is reloaded (the old version won’t be discarded until it is no longer referenced).

On a related note, I also updated my perforce server to the latest version (thank you to Perforce for making it so straightforward – server upgrades of personal data always sound like potential for disaster) as part of starting this project.