Rantings and Ramblings of Vaelzan

Got our Cyberpunk Jam game submitted!

Please take a look and vote. :)

I took a break from writing the "Game Engine" articles for a while because I ended up in hospital and have been pretty sick since then. Turns out that's a pretty good distraction from getting any writing done.

But now I need to get back into some game development, and what better way than a game jam?

At the start of next month is the Cyberpunk Game Jam, which is pretty damn awesome (for those who know me, Cyberpunk is one of my favourite subgenres ever). Later in the month, and overlapping the Cyberpunk Game Jam is the 7DRL Challenge (Seven Day Roguelike Challenge).

Decisions have to be made - I can't really do both, at least, not to the best of my ability, since I'd have to cut one or both short due to the overlap and also jam for over two weeks straight. Not going to happen. And I'm pretty addicted to Cyberpunk, so that makes my decision easier. What I do want to do is take a bit of inspiration from the fact that 7DRL is on by taking some pretty commonly used things in roguelike games, such as procedural generation, maybe permadeath.

But what language? I want to do a web based game, because it's by far the best way to get a jam game noticed. In the past I've used Java (Slick2D) and previously Flash (FlashPunk) for Game Jams. I feel like if I were to use Java again I'd have to learn something like LibGDX to actually make the game easily accessible to enough people (because it can be used to create HTML5 and Android games). I haven't really had too much LibGDX experience though, but it's certainly a valid option.

I want to try something different this time though, and I'm looking at Google's Dart language. I played around with it for a couple of days a while back and was surprised at how quickly I was able to write a game thanks to the easily accessible libraries publicly available. The only thing that really annoyed me about it was the Dart Editor IDE, so I'll have to go get a plugin for some other IDE (probably Eclipse or Sublime Text).

Obviously the game that I end up creating is going to be theme dependent, but I'd really like to do a heist type game (break into the corporation building) with guns, stealth, and hacking via something like The Matrix from Neuromancer / Shadowrun. The buildings would be procedurally generated, with the "Matrix" changing based on the types of tech inside the building.

This is the third part of my series on creating a 2D game engine. You can view the full list of articles here.

Configuration

I'm implementing config file parsing early on because it comes in handy throughout the development process. Straight away we can use it while creating the game window to set resolution, as well as windowed or fullscreen mode. Later, it'll be used to hold keybindings, settings of all sorts, user preferences, that sort of thing.

I want to be able to both load and save key-value pairs into the config file.

Key + Value Pairs

An INI config file is basically just a way to supply a value for a given key. The keys are usually short strings. Values can be strings, integers, decimals, booleans, etc. and our code will allow to read in any of those.

Sections

The other thing that the INI format does is divide things up into sections. In our engine, sections are included in the key string when reading and writing entries. So a key like "display.width" would correspond to this in an INI file:

[display] width=800

File Location

Depending on platform, there are specific locations designed to write preference files to. On Windows, this is inside the AppData folder. On my system, a good folder to use would be something like this: "E:\Users\Vaelzan\AppData\Roaming\The Evil Cult\Hello World". The way in which this folder is determined depends on the language, platform and libraries you're using, but it's important to be able to find out where to write, so that you don't try writing to a read only folder.

Don't Reinvent the Wheel

There are loads of libraries that can parse an INI file. Similarly, if you choose to use another format such as XML or JSON, there are many for those as well. Pick one that you like and use that, there's no need to go implementing the entire thing from scratch!

Defaults

When we read in a value from the config file, we should pass along a default value with it to use in case the entry isn't in the file. Something like this:

// false is the default value here:

bool fullscreen = game.config.readBool("display.fullscreen", false);

In our engine, if a key doesn't exist, it gets created with the default value and saved into the file to make it easy to adjust settings by hand in a text editor.

If a preferences file can't be read due to an error, the default can be returned to keep the game working.

Further Reading

http://en.wikipedia.org/wiki/INI_file

Next Up

The next article will be on geometry - points, lines, circles, rectangles, etc. You may think it fairly early to be addressing these, but they'll get used all over the place. For example, mouse coordinates (x/y) will be represented by a Point when we move onto Input.

Feedback? Questions?

So I dived straight in an started writing these blog posts without really giving an overview of the proposed systems and what the end goals of the project are. Better late than never.

These are the things off the top of my head that I'm interested in adding, in the rough order that I'll be doing them in. This is subject to change, probably quite a few times.

Game Loop: The core game loop.

Screen Management: Game screens / states to switch between menus and other screens.

Configuration Parser: Loading INI files for game preferences and keybindings.

Geometry - Point, Line, Circle, Rectangle and similar geometry classes.

Input - Keyboard and mouse support initially.

Resource Management:  Loading files for rendering, audio, scripts, and user interface, among other things.

Rendering:  Initially probably just blitting, geometry, and text. To be expanded upon later quite significantly.

Entity Component System: A way to create entities as the sum of their data components. These are then dealt with via systems, which contain the functionality behind the entities.

Console: An in-game Quake-style console with commands.

Scripts: Loading external scripts, probably LUA for my engine.

Animation:  Traditional spritesheet based animation initially, but also 2D skeletal animation in future.

User Interface:  Probably using XML files to construct the interface, as well as scripts to give things functionality.

Tiled Map Support:  This is a pretty frequently used map format, and it'd be handy to be able to load in these maps easily.

Audio:  With simple positional audio, effects (such as sound changing when underwater).

Creating a Simple Game: Creating some sort of retro game clone to test out everything created previously. Should make use of as much of the engine functionality as possible.

The above group of features is what I'm considering the first milestone. Notably absent is networking. That's beyond the scope of milestone 1, but it should be considered at least a little when implementing everything else, as it will often shape how other things need to function.

Once I have all these things written to a basic level, I'll be going through and revisiting stuff to expand upon the functionality. Chances are that will happen while I'm writing the first game that uses the engine, as I'll be able to see exactly what is lacking in the engine and what may not be working as well as it should be.

Some other things to think about (but not necessarily implement straight away):

Localisation: Although I'm personally only going to be writing games in English, if any of them get big enough to be translated in the future, it'd be helpful to be able to swap out languages easily.

Networking: Something to keep in mind for the future.

This is the second part of my series on creating a 2D game engine. You can view the full list of articles here.

What is a screen?

By screen, I'm referring to what can also be called game states. Screens are a way of dividing the game up into sections. A simple example game might have the following screens:

Splash Screen

Title Screen

Main Menu Screen (Start, Settings, Controls, Credits, Exit)

Settings Screen (Video, Audio, Gameplay etc. settings)

Controls Screen (Keybindings)

Play Screen

Game Over Screen

Victory Screen

Credits Screen

A few things can be determined from this list of screens.

Only one screen can be active at a time.

That screen should be the only one updated and rendered during the game loop. The others should be "frozen".

Screens might need to call code when they're activated or frozen.

It should be easy to switch between these screens at any time.

The following is what I ended up with.

The GameScreen Interface

A GameScreen will be an interface with a number of functions. These are the main ones that every screen has:

init() - Initialise the screen.

destroy() - Destroy the screen.

update(delta) - Update the screen by delta milliseconds.

render() - Render a frame of the screen.

enter() - Called when the screen is transitioned to from another screen. This could also be considered resuming the screen state.

leave() - Called when the screen is transitioned away from to another screen. This could also be considered pausing the screen state.

static getID() - Return the unique ID of the screen.

This GameScreen interface then gets implemented as individual screens, such as by a TitleScreen class.

The Screen Manager

The screen manager is a class in charge of adding, switching, removing, and updating screens. It should contain a list of all the registered screens, and know which one is current.

init() - Initialise the manager.

destroy() - Shutdown the manager.

update(delta) - Update whichever screen is currently active by delta milliseconds.

render() - Render the current screen.

And the screen controlling functions:

addScreen(screen) - Register and initialise a screen.

changeScreen(screen ID) - Transition from the current screen to this new screen. Call leave() on the former and enter() on the latter.

removeScreen(screen ID) - Remove a screen. This probably won't be used often as screens typically don't need to be removed, but is here for completeness.

getCurrentScreen() - Returns the currently active screen.

Integrating with the Game Class

The screen manager and at least one screen needs to be added to the screen manager during the Game class's init() function.

The update function of the Game class should be changed to something like this:

update(delta) {     screenManager.update(delta); }

The render() function should also be adjusted similarly, as should the destroy() function.

Some Notes

The first time a screen is added via addScreen(screen), the screen specified will become the active screen (and have enter() called on it). This is so that there will always be an active screen as long as at least one screen has been added to the game.

Further Reading

http://gamedev.stackexchange.com/questions/13244/game-state-management-techniques

Next Up

The next article will be on setting up a configuration / preferences parser, in this case, an INI file (though XML, JSON etc. are quite popular now too, and you could vary your implementation to suit).

Feedback? Questions?

Index

The full list of articles in this series can be found here.

What is this?

This is the beginning of a series of articles on putting together a 2D game engine. It'll start small and gradually get bigger. I'm going to try to avoid focusing these articles on the actual source code and instead on the structure of the engine and the components that come together to form it. Having said that, I'm going to be using the C++ language with the SDL and Boost libraries, but most of my previous experience in game development has been in Java (this will be my first big C++ project).

Along the way I'll be creating a few games using the engine as it reaches various milestones. Actually using the engine as it is being created will allow me to notice where it is lacking in features, and make sure everything is working correctly. The first game will probably be a simple retro game clone (like Pong), to demonstrate input, rendering, etc. Later games will grow in complexity and will be used to test out new features that are added.

The engine will be created incrementally with a number of classes revisited later on to add extra functionality or fix problems.

I'm aiming to release a new part each week, in order to motivate me to regularly work on my engine. By writing about what I'm doing, it also hopefully means that I'm understanding it in enough depth to explain it to others.

Who am I?

I'm Vaelzan of The Evil Cult, and most of my past game development has been in the form of a number of Ludum Dare jam entries. You can find a list of some of them here.

Who am I not?

I'm not an author or a teacher. This is my first blog, ever. I've never really written anything in the way of articles, tutorials, or anything like that in my life. I'm also mainly writing these articles as a way to motivate me to finish my engine. As such, I may not cover everything in enough detail. I might be assuming too much, or I might focus too much one one area and not enough on another. If you think there is anything that needs changing, explaining further, or is confusing, please let me know!

What you should know.

You should be pretty familiar already with your programming language of choice and the environment that you code in. These articles assume that you will know how to create a project, use your preferred IDE, include libraries, create classes, functions, variables, etc. The articles are designed with some sort of Object Oriented language in mind.

Starting the Project

Let's dive straight in. The core of most game engines is a game loop. Each loop is called a frame. Thus the term, frames-per-second, referring to the number of times the game loop repeats each second. Each loop updates the game logic and renders the game to the screen. Often the game logic is timed separately from rendering - logic might be at a fixed 60 FPS while rendering may fluctuate significantly.

Code Layout

I've created a Game class to hold the game loop as well as initialisation and shutdown code. 

These are the main functions used in our core Game class:

init() - Initialise the game. This should create and setup all the various managers and core classes used by the game.

update(delta) - Update the game by delta milliseconds.

render() - Render a frame.

destroy() - Shutdown the game, including anything created inside init().

getDelta() - Return the number of milliseconds that have passed since the last frame.

The Loop

Firstly, this article explains game loops significantly better than I do, so it's worthwhile reading.

The idea here is that update and render are called over and over again in a loop. To start with, it's a very simple loop like this:

bool running = true; init(); while (running) {     update(getDelta());     render(); } destroy();

Later, this will get more complicated - I'll be adding a few things such as framerate limiting and a semi-fixed time step.

For now, though, and realising that it does have some limitations that will need to be addressed (see Further Reading), this will serve our purposes and is a reasonable basic solution.

Something to note is that on most platforms you'll need to have some way for the platform to process stuff too (for events and similar). This is platform-specific, and you'll need to consider this based on what you're coding in and for what platform.

Initialisation

All that needs to be done during initialisation at this point is to create an empty Window and initialise the timer prior to the first frame (see below).

Timing

The delta time is the number of milliseconds that has passed since the last frame. The functions getDelta() is used to calculate this. The delta time is calculated by getting the current time in milliseconds, subtracting the time of the last frame, and returning the resulting value. Every frame, the current time is saved for use in the next frame.

Often, the delta time will be zero. This is fine, as it just means that no time will pass in the game - animations won't move for this frame, for example.

How you'll get the current time depends on the language and libraries you're using. As I'm using SDL, I'm using their built in function SDL_GetTicks() that returns the number of milliseconds since SDL was initialised. It doesn't matter at what time the timer starts, as long as you can get the difference between frames.

Further Reading

http://gameprogrammingpatterns.com/game-loop.html

http://gafferongames.com/game-physics/fix-your-timestep/

http://www.koonsolo.com/news/dewitters-gameloop/

Next Up

The next article is screen management - splitting the game into screens such as title, menu and play screens. This sort of thing is also commonly referred to as game state.

Feedback? Questions?