Archive for the ‘Bold Pixel Engine’ tag

Bold Pixel Update: IT’S ALIVE!

It’s a bit more than an update. I can confirm that our engine is now born and is currently being used for the current contract project. I will be telling you more about it in the next couple of weeks as we fine tune it, but here’s a bit of info about it.

Basically I recoded most of the current engine in order to make classes more logical and easy to use. Coded proper singletons for all manager classes that had a use for that particular pattern, moved classes around to make the engine more tidy and commented all classes from top to bottom.

Added a couple of nice things, for instance, we had a Preloader class that was supposed to be extended to the preloader movieclips all games have. Problem with it is that preloaders from portals rarely fit this class. I recoded it to be a Load Manager class that handles all loading processes, from external files to the preloading while giving info about the current progress of it. This way I have one class that handles all loading needs (including preloading) and that doesn’t need to be extended… so sweet.

The Bold Pixel

Bold Pixel Engine is the name I selected to honour the work of my partner Marco. I’ll write a funny fact about it one of these days. Anyway, Bold Pixel is our engine’s name as soon as I can call it a game engine, and now I can. The missing link was the blitting engine we have planned for some time.

The blitting engine is made of a texture manager, a layer manager, a render engine which handle textures, layers and entities. It currently supports frame independent animation for entities as well as rotation, pivot points per texture. A lot of thought was put in finding a good balance between flexibility, speed and reusability.

I’m quite happy with the results although moving the current project to this version of the engine is more work than I anticipated considering how well the actual staging of it went. Production is always tougher than staging I guess.

Later,
Vlad

From refactor to library

Or how to refactor the code from your last game to build up your reusable libs.

First and foremost, thanks to the people at FGL chat that brainstormed a jolly good topic to write about. This post also helps me to rethink my strategy about an issue I have with our core libs that I’ll hopfully address in the future as soon as I make sense.

Basic question is how do I handle the code I used in the previous game to reuse it… I’ll give several examples of how our core classes appeared or changed hoping that you find something useful for your own code and games.

In the beggining there was music

When we wrote Tech Wars, I had to write a music manager that would know when to change tracks. There are three tracks in Tech Wars, all with the same beats per minute, two share the melody but with different instruments and one has a slight variation of the melody. Each track served a part of the game, such has menus, level, and post-level.

Our current music manager has code from Tech Wars. That code evolved from a game specific class to a generic sound manager class and then to two separate classes: sound manager and music manager. These shifts occured as the next games needed or between projects.

What started with Tech Wars is now what we call the core, which is simply a bunch of abstract, cross-project oriented organization of directories and classes that goes from one project to another. It is not something you do, it is something you keep doing, building and evolving. That sound manager class was a bad case of refactoring, but a good start since we had no reusable AS code.

Generalization

To create your libs you should make each class abstract from the game code. This maybe trickier than it sounds. For instance, we have a Scene Manager. What it does is quite simple:

1. ensures that one and only one scene is running
2. ensures that one and only one dialog is running
3. ensures that when a scene is started the current scene and current dialog are closed
4. ensures that when a dialog is started the current dialog is closed

And this has to work in every game. To be sure that it works in every game I made sure that a scene or a dialog is always a movie clip that is linked in the fla library and that I can pass up to five arguments to it. I also made sure that the Scene Manager is a singleton.

Get yourself organized

To be sure that your code is generic, organize it! Create a structure outside your game logic, as an example, when I start a project I copy the core directory from the previous project to the root of the current project and I create a separate directory “game” where all the game specific classes go.

It’s that simple.

Refactoring

Refactoring plays a big role in all of this. Now that the core classes are a few and that most of the nasty work is done, the process of refactoring tunes it and adds to it.

Again… an example. Some hours ago I was using a static method MathKit.AngleBetweenPoints(p1, p2) which is pretty obvious, but for some reason the code did not produce the results I predicted, so I wrote a bit of code to ensure the output I was looking for.

The issue was that MathKit.AngleBetweenPoints(p1,p2) returns an angle in radians and I wanted degrees. I already have two static methods in the MathKit class to convert radians in degrees and vice-versa, so in the next refactoring session I’ll rename MathKit.AngleBetweenPoints to MathKit.RadiansBetweenPoints and create a new DegreesBetweenPoints.

The refactoring will eliminate generic code from game specific code, it will reuse static methods we already have in the MathKit class, make the method already there more intuitive and create an additional method for other uses.

Managers = Singletons

Managers are classes that take care of a specific aspect of your game. Scenes, music, sound and so on. You should be sure that your managers are singletons and that you can access them everywhere. To be sure of it, all our managers are loaded by the Application Manager which is what all our document classes extend. Neat trick and quite useful.

Tools = Static

All our tools are static methods. We don’t want our tools to be instantiated. We don’t want our tools to hold data. We want our tools to do something specific and produce an output.

At the end of the day

Like I said, when we start a new game I copy the core directory of the latest game to the new one. Usually I take a look a t it or look for //TODO remarks for something I want to review. While the code base was growing this was very useful, right now it’s a matter of tunning some details since most work is done while refactoring.

I do have a damn project to go though… writing the graphic handling classes… but I still have a load of doubts to sort first.

Oooops… big one… Vlad out!

Bold Pixel Structure

Here’s a real headache. I’m not really a coder… I don’t have the mindset and I lack a lot of knowledge so I tend to do things my own way. Sometimes, that’s good! Often when a more imaginative solution is necessary. But more than often, I’m trying to reinvent something that already exists.

When I started the current project, I decided that first thing to do was to rebuild the code base. The structure that was born is something like this:

core.algorithms.* is where all algorithms reside. By the time I’m writting this post, the sole habitant of this package is a yet to finish A* algorithm.

core.managers.* is the home of all managers. A manager is a central system of the core. By definition, other systems depend of the existence of one or more managers to function properly. By the time I’m writing this post I have an application manager, a scene manager and a loop manager.

core.services.* A service is an isolated class that serves some purpose. It has no impact or usefulness behond a determined task, for instance, preloading the game.

core.structures.* Data structures go here. In the before-engine version of our core base, this was filled with a re-packaged version of Polygonal Labs Data Structures for Game Developers. I decided to restart the work here to keep code standards equal throughout the engine.

core.systems.* Systems are all the main classes that are relevant and play an important role through a game but that are dependencies of other classes. By the time I’m writing this post I have an audio system, a file system, an input system and a music system.

core.tools.* Tools go here… who would have thought of that?! From collision to math passing through little tools like getting the domain name to site lock the games, almost anything can fit here.

Thoughts?

Presenting Bold Pixel

Bold Pixel is the name I gave to our own AS3 game engine. As we stand, it does not exist. The current version is a organized group of classes that will serve as base to the actual engine. Want to hear about it?

Motivation

All the games we created from August until now pushed the creation of code that we want to reuse. From simple math stuff to the inclusion of classes from other developers, a bit of everything has happened. Until Atomik Kaos 2 and a project we were contracted to do in the meantime, this code base grew and was becoming less and less modular and clean. With the upcoming projects we have planned, more processing power will be needed and the necessity of a graphics bliting engine became obvious.

The tests with the blitting code were interesting and I ended up deciding to rebuild the code base to accommodate my coding needs and at the same time make it similar to what I would like a 2D game engine to be.

Objective

The creation of an SDK that controls all non-logic related aspects of game development that allows simple and direct management of all application in order to reduce and simplify the development process.

And that’s about it for now. I will go into further detail in the next couple of days, probably as soon as I consider the non-blitting part finished.

    Newer Entries »