Archive for the ‘Bold Pixel Engine’ tag

Bold Pixel Engine Blit Performance Test

Hi all, Vlad here!

Wrote a quick performance test yesterday comparing movieclips with our own blit engine. Usually tests are performed with a number of objects. To test several loads, usually a different number of objects is used to test the results. I didn’t want that since we all know that many games don’t have a fixed ammount of objects rendered. Even if object pooling is used, what concerns me is the objects rendered.

What I did was to create one object per frame and then move all the existing objects away from the starting point. This would give an instant visual reference about how well blit performs against movieclips.

Give it a try and then read on.

Tried it? Cool!

Movement is time-based in both tests, this means that test 1, ran with movie clips took longer since the spread is bigger. This indicates a frame drop, but if you run it again and notice that there are different spreads, so not only it drops but it drops in a rather inconsistent way. Obviously the test also took longer to conclude.

On the other hand, blit engine performs rather smoothly, to the point where frame drop is not inconsistent and allows the objects to stay pretty close to each other. Above that, the test is damn quick compared to the first one, proved by the small spread (although I could’ve included a clock, I admit).

This is nothing we didn’t already know, I agree! The true testing will be with animation, rotation and scaling of blit entities.

Bold Pixel Engine v0.9 refactor

Hi everyone!

As promised, as soon as BPE has a couple of games under its belt, it will be made available. There are a couple of games going on with it and those are almost done, but the engine’s part is finished.

With all we’ve been through with it, refactoring was needed so I put a bit of work in the engine this evening (coding on a Saturday evening… geek!) and I’d like to show you how to do something with it.

I’d love that you take a look at the code and let me know if you think it is easy to follow, since this is the philosophy behind most of BPE’s classes.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

package 
{
    import bpe.blit.*;
    import bpe.managers.*;
    import flash.display.MovieClip;
    import flash.events.Event;
 
    public class BoldPixelEngine extends MovieClip
    {
        public function BoldPixelEngine():void
        {
            addEventListener(Event.ADDED_TO_STAGE, init);
        }
 
        private function init(e:Event)
        {
            var engine:Engine = new Engine(640, 480);
            var layer:Layer = engine.layer.create();
            var actor:Entity = layer.entity.create();
            var animation:uint = TextureManager.createCollectionFromMovieClip(idle);
 
            addChild(engine.render.window);
 
            actor.x = 320;
            actor.y = 140;
            actor.animation.loop(animation);
 
            Loop.AddListener(engine.update);
        }
    }
}

What this code does is to create a blit engine instance in the stage and draw a time based animation in it.

What I’d like to know is, without any further explaining, does this look simple and intuitive to you?

Thanks!

Downgrading from engine to toolkit

While I was discussing the release or not of Bold Pixel Engine, I came to the conclusion that it was not an engine, but a framework. What’s really the difference I wonder… I don’t know, but I did conclude that. Without googling for some reasoning and from the experience I have with game engines (not a lot but enough for what I’m about to write) I’d say that an engine runs while your game logic is processed.

On the other hand, a framework is a pre-build codebase that you use to raise your productivity. It does most of the work and takes control of the most obnoxious tasks. Our engine does that but it does not run while processing logic.

So it was kinda easy to conclude it is a framework, but not an engine.

Then I found out that a framework will take control of the dreadful tasks by creating automation for it. That would be an issue I read and I read that a toolkit is a much simpler approach, with a much lower maintenance overhead that assumes the programmer is in control of getting it done, while the toolkit only provides functionality.

“Damn!” I thought while I was reading… our engine is a toolkit.

And what’s the purpose of this post? None! While semantics are being discussed, our engine is currently being used to create games. And we will call it engine because regardless of what we call it, it will do what it was designed to do and because we really love the notion of engine regardless of the actual name being right or wrong.

So, engine, framework or toolkit: Bold Pixel Engine is alive and well and it will be released freely as soon as it has some games out just to be sure that it is stable enough for game development.

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!

« Older Entries    Newer Entries »