Engines!

Ok, so we’re back! After an entire summer of dead air, this blog is alive and running again!

So yeah-

We’re Back!

Without further ado, let’s start from where we left off.

(Note: This entry, together with some of the next entries, may not have a picture for obvious reasons, since we are not talking about something normal players would seen.)

When we last left, we discussed a series of “techniques” and “algorithms” in order to create effects for our games. However, these are ultimately, methods. To use this methods, we need something that’s more basic, that’s an Engine.

Yes, we could totally work our game from ground up, coding what the game needs and came out with a good game, just like we did last year. However, it’s not feasible in the long run because of the following reasons.

The Problems

• Scope
  • The scope of a game is one of the basic property of game design, for small games that is a tech demo, or has short game play, there are no reason to not stick with “code-as-you-go” tactics. However, for a larger game with lots of content and assets, there are codes to be reused, exceptions to be thrown and track, and assets to load. If we don’t organize them it could be a disaster.
• Organization
  • From prior experience, to make a game with decent gameplay and appearance, a lot of assets will be needed, this include but is not limited to physical assets such as models, textures, sound files/music, but also coding assets such as shaders and codes that read the physical assets. These assets need a place to be read, but the programmer probably want to organize them so they don’t all went under “/resources” (which is exactly what happened months ago with our own game, though we don’t have that much resource in the beginning so we let that slide.)
• Debugging
  • Now let’s consider a bad case scenario in which something in the OBJ Loader went wrong and results in distorted models (don’t laugh, even Pokemon X/Y got that glitch). Programmers need to know if it’s because the model is flawed (thus has a bad output) or the OBJ Loader itself went wrong. Since in both cases the error messages would be similar, that provides a very hard tracking and debugging process.

So, we basically need something that will erase all these repeated codes, manage assets for us, and is easier to debug. This is where an engine comes in.

The Solution

Engines came with different kinds, the simplest Engine out there is probably RPG Maker, it’s more a game maker than an engine, but the most recent reasons enabled the game designers with coding skills to directly mess with the project’s code, making it a semi-engine since it has all functions a game engine would have already. However, what we need, and what we’re talking about, are much harder to deploy while allowing us to do much more than a simple maker that produces RPG Games.

Now here we will work with a special engine called 2LoC for the time being, which is quite special since it’s assembled by people at UOIT, meaning it’s academic instead of the common commercial work such like Havoc or Unreal. However, the basic idea are the same, while 2LoC did has wrappers for some Havoc functions and would be curiously familiar to people (such like me) that has experience with XNA or similar engines.

So what do we have here…

To address the above problems (no, not the familiarity of engines, the bigger problem above), 2LoC has the following characteristics.

• Function Overrides, or to use the better and bigger word, Polymorphism (πολύςμορφή, click for the wikipedia entry). Basically it works like this: First we got “base classes”, barebone classes that draw an outline of a series of functions. Then we have separate classes that divide from those base classes that override the base and provide the actual implementation. This is a very familiar practice since it also exists in XNA.
• However, the divided classes themselves on the other hand, are pretty much singled out with each class have implementations for just a single function. Combined with the fact that we can divide the implementation from our base class, this is a good design practice that makes sure one function only got one class while getting rid of the need of copying code for reuse – since they should be in the base class by now.
• The engine is also easy to deploy (well, I saw people had problems, but it runs smoothly here so yeah) via CMake,  We had this script that will deploy the engine files according to the version of Visual Studio installed. No more moving files from Visual Studio to the project files, or set up the properties in Project files since the CMake script did it all. We only need to import what we need into the generated solution and-
• Said importing is also easy since everything is organized. Plus, this engine has a clear exception handling so say if a model get displayed incorrectly, it’s now easier to see if it’s caused by the OBJ Loader, in which situation the engine will throw the exception, or by the model itself, in which the OBJ Loader itself will throw another exception.

By using this engine, we solved all the problems stated in the beginning of this blog article. Isn’t that a great thing?

But Wait…

Yes, maintaining an engine is not as easy as coding freely anymore. For example, to add something that’s a function, you need to follow the standards of overriding classes and write a new class that extends the base class. This needs a good understanding of the engine itself to carry out – but it’s still better than writing entire methods and reusing codes. As of now, I’m still looking into importing assets and functions into the existing and deployed engine, I’ll update the blog when I have something to show here. As of now, Nemo out and back into reading engine code.

Until next time, Be Lucky.