Console Programming 3-Week Project 2 - DFGame Expansion

Hello again! After a few weeks of toil, I've finished my second 3-week project for Console Programming. I opted to make this project about building up DFGame to a more usable level, and I'm happy to say that the project was quite successful!

Project Overview

My ultimate goal for DFGame is to be able to build the base of a game from scratch, editor and all, in a single week. I decided that a nice way to cap this project off (and test the viability of DFGame in the process) would be to try and make a super-basic game/tech demo without an editor in a single week. I'm pleased to say that the result way a success!

To make this game happen, as well as improving Halberd a bit, I decided to implement the following features during weeks 1 and 2:

• A script for generating new DFGame-based projects
• Some UI widgets for editor development
• Input handling code
• Sprite loading/drawing code
• Some initial project management code

In the downtime between projects, I also started work on audio loading/playback.

Project Script

One of the main differences between DFEngine and DFGame is one of approach. DFEngine's goal was to make a fully-featured game engine, but with DFGame I add features that will benefit me directly in game projects. As a result, I can get things done faster because my focus is specifically on making games.

The project script is a great example of such a feature. It's designed to set up a new DFGame-based project as quickly as possible, while also being easy to modify and extend.

DFGame now creates a folder in /usr/share (on *nix-based systems, of course), and adds folders which act like templates to it. This means that users can add their own, as well. It also installs the script to /usr/bin, so you can create a project just by calling "dfgame new project-name folder-name". folder-name is optional too, if you omit it, it'll set up the default project. The script moves over the contents of the template folder, and then checks for a special script within the folder. If the script is found, it's executed as well, to allow for extra customization. The current template scripts set up a config.mk file, for instance. Finally, the script initializes Git and builds the project, ensuring that everything is in working order.

UI Widgets

I've been meaning to move several parts of Halberd's UI over to dfgame for some time now. Most of the more 'generic' UI elements, such as the asset pan and missing files window are mostly self-contained, so moving them over was quite simple.

I also took the opportunity to make something new: a log viewer. I've wanted this for a while, so that I could debug issues without having to look at several windows at once. Now, it's in!

It's not an enormous addition, but it feels like another good step towards making my editors more professional.

Input

 My input code has always been fairly simple, but this time I decided to try and make a more powerful system.

This new system lives up to my expectations quite nicely! It revolves around mapping inputs of any kind to either (or both) of two input types, actions and axes. An action is any kind of digital input. It generally used to represent singular in-game actions, such as opening a menu or attacking an enemy. Axes, on the other hand, are 2D analog inputs. An axis can be thought of as a 2D vector, like a joystick input. Axes should be used to describe inherently directional actions, such as movement or aiming. Any keyboard, controller, or mouse input should be translatable to any actions and/or axes.

So, we have a decent base here. But what makes this so powerful is the way it's implemented. DFGame's input code is broken up over 2 of its modules: the base game module, which is used everywhere, and the game frontend module which is only used in released copies of a game, not the editor. This means that the editor and game are responsible for handling their own inputs, and passing the result to the base input system.

Not only does this separation make inputs inherently rebindable, since the actual keys are disconnected from the in-game actions, but it also allows the editor to simulate inputs and the game to take inputs from custom sources and input devices. Ultimately, this makes input code way easier to deal with, and it also makes adding or changing controls during development a cinch.

Sprites

DFGame's new sprite system is mostly identical to Halberd's, with one main exception.In addition to the sprite/animation system that I described in this post, DFGame's implementation has an additional layer of abstraction.

In order to speed up rendering and save on memory, I've split sprites into two parts, the spriteset and the sprite [player]. This is a similar approach to the one I took with audio: One struct controls data access, while others act as interfaces to play back this data. The spriteset holds the texture atlas and animations, while the sprites hold information about the currently playing animation.

Project Management

One of the most important features that you can put into an engine is the ability to create new projects. Even if you plan to only use an editor once, being able to go back and create brand-new content with it can be quite useful. In addition, it gives the editor potential for a decent public release. For that reason, I've moved Halberd's project management code into DFGame. It could still use a bit of cleaning, but for now it'll do the trick.

The Game

All of this technical talk is good, but you might've noticed that I mentioned a game earlier. In addition to the DFGame improvements, I also created a small game as a test. I planned to spend a week on it, but instead I only ended up with 3 1/2 days. Despite that, I still managed to make a small, well-scoped twin-stick arena shooter.

The game isn't currently packaged and available for download, although I'm considering that right now. The game's code is quite messy, since the point was simply to use it as a quick test of my library's capabilities, rather than to start a 'serious' development project. It's more of a game jam-style game.

Regardless, I took the time to make a video of the gameplay. Since there aren't any sound effects anyway, and the music was borrowed from one of my old game jam entries, I decided not to record the audio. Feel free to add whatever background music you like while watching.

Conclusion

I'm really happy with the progress that I've made in the past 3 weeks. I took a simple collection of asset loaders and turned it into a wonderful budding library of game development tools. Now that I've proven that rapid development is possible with this engine, I'm going to try and participate in more game jams again. In addition, I think I might try to make some smaller games as well.

Most of that will have to wait until after I graduate though. This is a very tough semester for me.