This article follows from the Application Class article and assumes that you are familiar with that article.

Messaging is one of the most important subsystems in a game engine.  It allows the developer to decouple the occurrence of an event from the handling of that event.

Why Coupling Events with Event Handling is Bad

The design paradigm of responding to an event immediately can limit performance and cause the developer to write bad code.

Say you’re writing a stealth espionage game, let’s call it Plastic Gear Liquid.  The “Process Inputs” step might look conceptually like this:

• Player presses the Shoot Gun button.
• Game immediately triggers the character’s Shoot Gun action.

So far, so good.  But how would enemy responses work?

For example, when the main character (let’s call her Liquid Salamander) fires her gun, several things may need to happen. To name a few examples:

• Animation System plays an animation of Liquid Salamander raising and firing her weapon.
• Particle System causes a flash, and maybe some gun smoke, to be drawn.
• Sound System plays an appropriate sound effect.
• AI System alerts enemies to Liquid Salamander’s presence.

Without some kind of messaging in place, Plastic Gear Liquid would prove to be difficult to write.

Using messaging, the design is fairly straightforward:

• During the application class’ “process user input” step:
  • Input Handler collects the user’s input (pressing the “shoot” button), and places a message on the message queue that the user pressed the shoot button.
• During the “process commands” step:
  • Animation System looks at the “user pressed the shoot button” message and initiates Liquid Salamander’s shoot-weapon animation.
  • Particle System looks at the same message and begins the light flash/gun smoke particle effect.
  • Sound System looks at the same message and plays the appropriate sound effect.
  • AI System looks at the same message and initiates the notify-nearby-enemies routine (likely based on distance from the character and whatever other inputs).
• During the “update actors” step:
  • Liquid Salamander’s animation advances.
  • The particle effects continue.
  • The sound effect keeps playing.
  • The AI enemies track down Liquid Salamander.

Implementing a Messaging Subsystem

There are probably many ways to implement messaging in a game.  The Falldown engine (and the WIP Gamma Engine) uses a message queue.  The message queue is, as the name suggests, a central queue of messages.  It is “central” because there is only one MessageQueue in the engine.  Any game objects (GameObjs) that participate in messaging will write to, and read from it.

The message queue interacts with Writers and Readers.  A Writer is any GameObj that leaves a message for any Reader; a Reader is any GameObj that reads messages left by any Writer.  Any GameObj can Reader, or a Writer, or both.

The key to the message queue is that messages are destinationless. Writers don’t know which specific Readers will receive their message, and similarly, Readers don’t know which Writers will leave messages of interest.  Instead, Writers publish their messages with a given Topic, and Readers subscribe to whatever Topics they’re interested in (this is called the publish/subscribe pattern).

An IRL Example

In Falldown, the message queue is implemented by a MessageQueue object.  The MessageQueue is an object that has the following:

• a queue of Message objects
• a collection of lists of registered Readers (in Falldown, I called them “RegisteredListeners”).

To register a listener, the MessageQueue object has a RegisterListener function that adds a specified listener to a list of listeners for a given topic.  The function looks something like this:

def RegisterListener(self, listener_name, listener, topic):
    self._registeredListeners[topic].append( { 'name': listener_name, 'ref': listener} )

The code snippet is a member function of the MessageQueue class. “_registeredListeners” is the container of lists of listeners for each message Topic..

NOTE: This function does not test for duplicate entries before adding/replacing items, but it is a good idea to do so in real life.

Once the listeners are registered, the rest of the messaging flow goes something like this:

• During the “process inputs” step of the game loop:
  • The input handler collects keyboard presses and enqueues keypress event messages (e.g., Topic = ‘PlayerInput’) onto the MessageQueue object’s message queue.
    • Side note: To be clear, lower-case “message queue” is the concept we’re talking about; camel-case “MessageQueue” is the name of the object in the engine. The MessageQueue object contains a message queue, as well as other things.
• During the “Process Commands” step of the game loop:
  • The MessageQueue dequeues a message off the queue, to be processed.
  • The MessageQueue then steps through the list of registered listeners for the message’s Topic.
  • For every RegisteredListener subscribed to the Topic:
    • The RegisteredListener “makes a note to self” to act on the contents of the Message. (Note that the RegisteredListener does not actually begin acting yet. That happens later.)
    • In Falldown, the Ball “makes a note to self” by setting state variables: “Moving Left = True/False”, or “Moving Right = True/False”
• During the “Update” step:
  • The Actor processes its “notes to self” and acts
  • In Falldown, the Ball acts by actually changing its position to the left or right, depending on its state variables.

… And then after all that, we draw the scene (not pictured here)

About Message Objects

In Falldown, every Message contains:

• A Topic, and
• a Payload

The Topic is a string, e.g. “PlayerInput”.

The Payload is more complex.  In Falldown, the Payload contains:
* an Action, and
* Other Stuff, depending on the Action.

What constitutes “Other Stuff” depends on the programmer’s design.  It’s probably best to show a real example from Falldown:

message =
{
    'topic': 'PlayerControl'
,   'payload': {
                   'action': 'call_function'
               ,   'function_name': 'setLeftKeyPressedTrue'
               ,   'params' : ''
               }
}

In this example, the Payload contains:

• an action, “call_function”
• a function_name, “setLeftKeyPressedTrue”, which is the name of a function that sets a state variable for the ball.
• params, a list of parameters to be sent into the function.

The Falldown engine uses the message above to compose a call to a function that does something useful.  For example, the above message will make the Ball call its own setLeftKeyPressedTrue() function.

In practice, you can design Messages to contain whatever Payload will be useful in your game. The design described in this article is meant to give you ideas to experiment with.

Happy gamedeving!

What is an Application Class?

The Application Class is a class that defines how the application will interact with the system it’s running on. It is the part of the engine that is responsible for interacting with hardware (input, display, sound, etc.) and other software components that make the system go.

A well-designed Application Class abstracts away the hardware and software interfaces so the game developer (i.e., the person using the engine to write a game) never has to know the particulars of, for example, taking input from a touch screen, or a keyboard, mouse, joystick, gamepad, microphone, VR wand, etc. Ideally, the engine developer (i.e. the person creating the engine) would want the input functions to be as simple as:

myInput = engine.getInput()

and automagically, the value of myInput would be something like KEYBOARD_KEY_SPACEBAR, or TOUCHSCREEN_TAP (maybe with some screen coordinates), or GAMEPAD_BUTTON_1..

Of course, in practice, it’s never quite that simple.  But the goal is to get close.

How Does One Make an Application Class?

Fundamentally, the Application Class for a game needs to do 3 things, and 3 things only:

1. Collect inputs
2. Process inputs/Crunch Data
3. Output something

Of course, the details of those 3 steps can be immensely complex.  In the list above, “collect inputs” means to any gather input data which the game logic will use to compute stuff. “Inputs” can actually be user/game controller input, AI input, networking input, etc.

Similarly, the term, “process inputs,” is broad. For example, the game can process game controller input and turn it into commands (e.g. walk forward).

The controller input might lead to AI input, as mentioned above. For example, the user might press a gamepad button that causes the player to launch a homing missile at a target. In the same way that the controller generated an input that the game interpreted as a command to launch the missile, the missile itself, and the target, also generate input data that help the game calculate where the missile should go.

Lastly, “output something” entails drawing the scene, playing sound effects, vibrating the controller, etc. The outputs are feedback items that let the game player know what’s happening.

An IRL Example:

The Application class for Falldown x64, my entry for Low Rez Jam 2016 adds some complexity/structure to the 3-step model above:

• Process user input
• Process game commands
• Update actors
• Do pre-render stuff
• Render the game scene
• Do post-render stuff

In a bit more detail:

• The “process user input” step involves collecting user input and translating it into game command messages.
• The “process game commands” step involves consuming game command messages and executing the actions they instruct. In Falldown, game commands are things like “SetMovingLeftTrue” or “SetMovingLeftFalse”, for the ball.
• The “update actors” step runs the game’s “simulation.” For example, the update step moves objects, performs collision detection, etc.
• The “pre-render” step entails cleaning things up before drawing the scene. In Falldown, it involves constraining the ball to stay within the boundaries of the screen (after the “update actors” step already moved the ball based on gravity and user input).
• The “render” step draws the game scene.
• The “post-render step draws overlays, such as the score, level, etc. In a 2D game like Falldown, the game stats “overlay” doesn’t look like much. It makes more sense in a 3D game, where the overlay might be oriented relative to the “camera” looking into the virtual world.

Some notes:

• Why is the “process input” step separated from the “process game command” step? The separation ensures that all game commands are executed when they’re supposed to be (more on this in the messaging article).
• Why is there a pre-render, render, and post-render step? The short story is: I have read that breaking the scene rendering into those 3 stages is good practice, especially in more complex games.
• Falldown uses Pygame (which is a Python wrapper around SDL) to interact with the computer’s hardware. Even though we are writing our own engine, we <strong>do not</strong> want to write our own low-level code.

Happy gamedeving!

I’ve decided to try my hand at writing about writing a game engine.  The reason is: I’ve put a lot of time and energy into learning how to write a game from scratch, and I believe I can fill in gaps left by the materials I tried to learn from.

But, before I launch into discussing how to write a game engine (or maybe just to stall for time.. :-D), I’d like to talk to about what an engine is.

What Exactly Is A Game Engine?

To be honest, I’m not sure. Once upon a time, “game engine” used to refer to the guts of a game that made it think. In that sense, the a game engine was just a bunch of logic, math, and programming code. Nowadays, the term “game engine” has expanded to include entire toolkits.

The software kits known as “engines” have all sorts of goodies today that extend far beyond the old-school definition of “game engine,” including (but DEFINITELY not limited to):
* Graphical/node-based editors (tools that allow developers to create games without actually writing code)
* Wizards/helpers to compile the game to run on different platforms (e.g., web, mobile devices, computers, etc.)
* Scripting languages to abstract away computer science/programming details
* Art/graphic design tools
* … and also the ability to create the logic, math, and programming code that old-school “engine” refers to

That Sounds Intimidating; Where Do I Start?

The prospect of making all those tools sure does sound intimidating. That’s why I am only going to talk about the old-school “engine” parts: the programming code and math. (Truth be told; I have never tried to create visual tools or other sweet “new-school” engine parts. Maybe I’ll write about how to make those if I get around to it.)

This series of articles aims to shed some light on the development of Falldown x64. My handmade code is no Unity or Unreal Engine, but it taught me a few things about how those big-time engines might work under the hood. Because sharing is caring, and I care, I will share.

Some preface notes:

• This article series is geared to be accessible to the near-absolute beginner, yet informative to intermediate/advanced developers.
• I am relatively new at gamedev myself, so if any experts reading have comments, I’d love to get your input!
• To any beginners reading this, know that any kind of computer programming, let alone game development, can be insanely difficult. You will feel like you have to learn 10 things at the same time, to accomplish 1 goal. (That feeling is completely valid and correct :-)). Hopefully these articles help with that.
• This article series will be written using Python code samples because Falldown x64 was written in Python. But I hope to make the code sensible enough to be ported to any language.

Launchpad

1. The Application Class
2. Messaging
3. Game States (the State Pattern) (Coming Soon!)

As I promised back whenever ago, I am making the source code to Falldown Low Rez available: https://github.com/masskonfuzion/falldown_low_rez

In some places, the code is straight-up ugly; in other places, it’s stubbed and not totally complete.  But in other places, I think the code is pretty slick, if I do say so myself.  Regardless of how it looks, it works!

Being a learning project, the emphasis is on the engine/code (I recognize that the aesthetic looks plain; I’ll make future projects look better).  To that end, the source code is open and free.  Of course, I’m happy to take donations 😉 If you’re feeling generous, you can Paypal me: masskonfuzion@masskonfuzion.com.

About the game, a few things have changed since I first submitted the game for the Low Rez Jam.  Now the game has:

• A working UI/menus (using keyboard or mouse)
• Customizable options
• Somewhat of a difficulty curve
• Keyboard input and game logic bug fixes

The UI stuff looks like this:

And the game looks like this:

In the video, you can see that the game moves faster than it did.  That was by choice.  Originally, I wanted the game to move in slow, staccato, single steps.  The difficulty would increase by reducing the amount of space between each row (i.e., adding more rows to the screen), as the player progressed through the game.  But during the jam, I ran into problems implementing that design. So instead, I reduced the amount of space between each row, and made the difficulty increase by slowly adding to the distance between gaps on consecutive rows.  That design choice required a faster-moving level.  Since the jam, I have had time to fix bugs, but I never returned to the slow-moving level design.

Stay tuned for more.  I can’t seem to put this project away, so I’m sure I’ll have another update.

Until next time!

While this video might give the impression that I’m back where I started, I have actually progressed a long way since my last post.  Falldown is coming along, and the engine I am working on supports many features, which I will get into after the video.  But first, feast your eyes:

What’s New?

The engine has a name: Gamma (or perhaps Gamma Engine).  The name is derived from “game” or “gamer.”  It is written in C++ and sports the following design/features:

• Game Actors are containers for Actor Components.
  • Any object or character in the game can be an Actor.
  • Actor Components control the ways in which Actors behave/interact. For example:
    • Render Components enable Actors to be drawn (with or without texture mapping)
    • Input Components enable the user to control Actors using mouse/keyboard/etc.
    • Collision Components enable collision detection/response among Actors.
    • Physics Components enable different physics simulation methods, e.g. Euler, Verlet, RK4 to be used on Actors.
      • Different physics sims may be applied to different Actors at the same time. For example, a rocket may be simulated with Euler integration, while particles in the rocket’s smoke trail may use Verlet integration.
      • The user can define sims, such as constant-velocity (ignoring gravity/other forces).
• An Actor Factory makes easy work of spawning Actors.
  • A Resource Loader parses Actor information from files, enabling Actors to be defined by templates.
• An Application class encapsulates function calls necessary for the game to interact with the operating system.
  • An Event Queue class gathers events from the operating system and from game subsystems. The Event Queue is a base class for, e.g., Input Event Queue, Sound Event Queue, OS Event Queue, etc.
  • A Command Queue class translates system events into game commands.
• A Game Logic class contains Actors, Event/Command Queues, and Event Handlers, such as a collision event handler.
• A Game State class enables state transitions (e.g., the switch from the splash screen state to the playing state, in the video above, is a state transition).
  • Each Game State may contain a Game Logic object, which enables state-specific behavior, e.g., keyboard inputs being interpreted differently in State A than in State B.
  • The Game State class implements a stack-based game state management system. So, for example, a pause menu state can be stacked on top of a playing state.  When the user exits the pause menu, the playing state resumes.

Design Notes

• Gamma is designed to be generic and scalable.
  • Previous iterations of Falldown (and their engines) took shortcuts that eventually led to my becoming stuck and unable to finish the projects.
• The object classes in Gamma are designed polymorphically, to allow the developer to extend the engine to meet his or her needs.
• The engine is cross-platform:
  • It primarily employs SDL (I plan one day to support DirectX)
  • It is compiled using gcc on Linux and mingw on Windows.  (I have not developed/tested on Mac, because I do not have a Mac.. yet).

Future development

To Falldown, I plan to add:

• A proper game menu, with configurable options
• Score keeping
• “Scripted” levels (currently, levels are randomly generated)
• 3D?
• Multiplayer?

To Gamma, I plan to:

• Add any updates necessary to build whatever Falldown features I think up.
• Squash bugs.
• Perhaps share on GitHub.

Thanks for reading, and stay tuned!

 

Shout-outs:

Thanks to Michael Kissner and his GamaSutra series on game engine development.  Gamma is based in part on his articles, which condense a lot of information from textbooks into easy-to-consume web articles.

Also, people like Chris DeLeon and his game development club/community keep me motivated when the going gets rough. (And it gets ROUGH sometimes…)

I also have to thank my wife, who puts up with me talking about programming computers all the time, coming to bed at 2 AM night after night. <3

There are many, many others out there — too many to list!

 

Remember this?   Well, I’m still working on Falldown, but It’s been a while since my last post (over 8 months!!).  The reasons for the lag time are:

1. My wife and I had a baby.  Well, she had the baby.  They’re both doing well, and they’re awesome, and we’re looking for a place to live; and
2. I’m re-working the game engine for Falldown from the ground up.

On point 1, it’s awesome being a dad and a family man, but this blog is about the games! 😀

So, to be more specific on point 2, I have been writing a new game engine to power Falldown and also a few other simple game ideas I have in my back pocket.  I am basing the engine on the book: Game Coding Complete, 4th Edition (GCC4) and a host of other resources available around the web.

“But,” you ask, “Why are you writing Falldown again? You already had what looked like a working game!”

Well, I almost had a working game. However, I designed it poorly, and I reached a point where I would implement features sloppily, with notes “to be finished/improved later.” Each addition I made in that manner became more difficult to integrate into the game.  I decided to redesign some of the underlying engine, to make it more modular and scalable.

“But still,” you ask, “Why would you write your own game engine, when there are umpteen free, ready-made options available, from Unreal Engine to Unity to Cocos (2D and 3D) to Godot to xyz engine?”

The answer is: I simply want to.  I want to understand how to build and customize every piece of the game.  One day, I will use a professionally-developed engine.  Over the long term, I, as one nerd with a laptop, will likely not be able to keep pace with the quality of an engine developed and maintained by a team of dedicated people.  But, for now, from-scratch is the way to go.

I chose the GCC4 book because it presents a good mix of guidelines and tips/tricks, without giving away too many implementation details. (It so happens I am also using a different gcc, the GNU Compiler Collection for my development environment, but I digress…)

The book is a strange duality: It aims to teach good design practices and habits to beginner-level game development students, but it assumes the students are at least intermediate to advanced-level computer people.  To feel comfortable with writing a game engine based on GCC4, I had to learn quite a bit about programming in C++, and for that matter, math, physics, collision detection, artificial intelligence, sound, networking (ok, truth be told, I’m not so well-studied in the networking just yet, but I’ll get there).

Somehow, the duality works for me.  Once upon a time in undergrad, I studied computer engineering, so none of the game development subtopics intimidate me.  I was a bit surprised by how much I’ve forgotten over the years, and by how much I realized I never learned in school in the first place.

The process of getting back into it has been fun at times and frustrating at others.  But the frustration and confusion make the eventual epiphanies even more rewarding than they otherwise would have been.

There are more “complete” books about writing games or a game engine, but I like the GCC4 approach (i.e., the hard way).  That is what has delayed my blog updates.  But I will keep writing about the progress of the game, and I will also write some instructional posts on how to do things and stuff in game development.  Stay tuned!