Tuesday, December 17, 2013

Update and Preview - Input System

Hello again,

as some of you may know, I am focusing more on getting things done than on writing about them here. Since this tutorial is supposed to be at a harder level than most of those we already find over the web, it is indeed more complex and I, as expected, am making some mistakes on the process of engineering/coding it. But now, I am focusing on the input system part as I aim to create an article here explaining part of it. The article is supposed to go to gamedev.net as well.

For our input system, I'll be using an events (or messages) approach, where we capture events from our library (Allegro 5, in this case), morph them into one of our own events and then queue it for grabbing.

These are the base classes we'll be using:


First Phase Complete (80%)

  • A class that is simply a container for all desired information on any generated input event, such as its type and time of generation. Examples of child classes are:
    • KeyInputEvent;
    • MouseMovementInputEvent;
    • MouseKeyInputEvent; and so on.


Keyboard part Complete, mouse partially, and missing gamepads (30%)

  • A controller actually communicates with Allegro in order to create new InputEvent objects based on the events Allegro may spit at us at a given time. It has a local event queue that stores them until we check out on an event (or call a purge function or destroy the controller). Every controller should have an independent controller object and we can have as many as we need. This way, we'll be able to have more than one player on the same screen (one on the kb/mouse and two on two separate usb gamepad).


Yet to be implemented (0%)

  • A gesture is an input behaviour. It is supposed to hold recognizable patterns to compare with the input events stored on a Controller object. Will hold all the translation necessary to go from a raw keycode to an internal input information (that can be a simple translated keycode). The code right now is using a temporary translation system where you can register the translations yourself.

The code

As of now, the code is all messy and full of test commands, not documented at all and completely untested. The memory cycle isn't complete, the events are being all forwarded but never deleted. This is stupid, I know, but I'll get to it when I get to it.

To summarize
  • The code has a functional event queue that hold on to these until you ask for them.
  • It will give you access to the events one by one, in order.
  • The time of generation is independent from the time you actually read them or update the controller; It marks the actual time of the generation.
  • The code lacks all memory management and documentation.
  • The Gesture Interpreter is still missing, and it will be the soul of this input system (and responsible for the memory cleaning, since it will be the last step of any events).
  • As of now, I am planning on a way to create the pattern recognition using a composite pattern registration approach. Will need some more thinking on that.
  • What the Gesture Interpreter will do when it recognize a pattern is yet to be decided. Possibilities are:
    • Call a callback registered along with the pattern.
    • Update a variable while the pattern is still valid for polling.
    • Generate an event and dispatch it somewhere.
    • Or, ideally, all three options, so anyone using this can choose what to do.

But if you're crazy enough to be interested in this, here's a link for the Code::blocks project:

You'll need a working compiler and Allegro5 with TTF support to be able to compile and run the simple test program. It'll probably need some Build Options tweaks (sorry for that).  There's not much to see though, just it popping translated codes into the screen using a font I got from here. But I find it quite amusing to see how it captures input even during a Debug breakpoint.

But don't worry, things will fall in place; I hope!

Over and Out.

Friday, December 6, 2013

Complete Rework

Hello Again,

As most of you readers know, I am in the middle of writing an engine for our SpaceRock Miners game. Not only that, but a generic engine that can be used for other games as well, including platformers, puzzle games, virtually any 2D games. The engine is going to be open-source and based on some other engines and libraries such as multimedia and input engines (Allegro, SDL, SFML) and a 2D physics engine (Box2D, the best one).

I was architecting the engine (HLGE, that stands for Higher Level Game Engine) and was pretty satisfied with it as it was. But, as I started to code it, I decided to actually study the subject more formally; got a book on architecture of game engines, found some resources online, read some articles... In the end, I learned a lot more than I expected. I should never had underestimated my own ignorance on the subject; never underestimate your own ignorance!

I really should have studied the creation of game engines sooner. That "create games, not engines" phrase is somewhat to blame; creating engines is a part of creating games, whether people want it or not. It opened my mind to possibilities that I failed to think of. Some stuff I read made me feel really stupid, while others I wasn't so far off. Of course, I got the basics right, but why being sufficient if you could be awesome? Don't you agree?

That's why, as stated on my last post, I basically discarded my first project, its architecture and any code I already had. Just so you guys understand, this hobby project has been on for months before I even thought of creating this blog, who'd say registered it; that's a lot of work out the window. It was a tough decision, but I had to do it, I would hate to work on an engine while knowing its architecture was flawed.

Now, back to the drawing board, I'm back to the basics. Designing interfaces for every system on it, thinking of the tools i'll need, all that. Repeating this process is fun, I'll tell you; imagining all the possibilities again, but I must not let myself drift too much. If I don't take care, I'll end up spending months just thinking about it and architecting it and never get to implement it.

As changes, I can list some that I think are pertinent.
  • I won't be using XML anymore
    • I plan on using YAML now; if you know of a possible alternative, comment it please.
  • I'll introduce the concept of Time Line
    • This is a major change that was incompatible with my previous architecture. With this we'll be able to create effects like, for example, slow-motion without having to output even a single command to the physics simulation.
  • Improved "views" system
    • I'm completely remaking the views system in a way that will allow us to change between game states way easier than before. My previous design was exactly the same I used on my first C++ game (what, as you can imagine, is pretty amateur).
  • Improved sprite rendering
    • A little extra memory in exchange for a faster rendering and shorter sprite loading times. Partially related to the "Locking Surfaces/Bitmaps" concept.
  • Abstractions
    • Create an abstraction layer for several problematic types such as time, angles, strings, so you don't need to think if it is on radians and seconds or degrees and milliseconds.
And an endless list of changes that wouldn't make sense to put in here since the previous wasn't even public yet.

I hope to get this ready as soon as possible, but, given my usual coding speed, it can take pretty long. Worry Not! Meanwhile, go to gamedev.net, work on a simple game project using a good framework such as LÖVE2D.

I'll try not to decide to start over again!
Over and Out.