Archive for the ‘The code of VGS’ Category

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.

Engine misconceptions

Maybe I’m a bit overwhelmed with what happened this last week, but the topic that doesn’t seem to leave my head is our engine. While I was discussing the topic in FGL chat I noted again two distinct definitions of engine. What I’m aiming for with this post is to address the common misconceptions that, in my humble opinion, exist to many flash developers.

Each game is an engine

This is the start of the difference of opinions. For many developers reusing a game engine equals to creating a sequel to a game with small tweaks and new graphics. To me, reusing a game engine is reusing multiple classes across games, but not game logic.

Coding your engine is nothing more than to write separate classes for the code you often use. Great simple examples are keyboard input, sound and music handling. On the more complex side we have collisions, AI and bliting. All of these can be coded separately to create a library of code that we can reuse with ease across games. That is the game engine.

It’s impossible to code a cross-genre game engine

Again, this misconception comes from not separating engine from logic. If we detect keyboard input the same way across games, if we preload the same way across games, if we blit the same way across games, regardless of genre, why can’t we write code that fits all genres? It is better to manage some exceptions to your code than to rewrite it over and over again.

If you think about it, that’s how cost is cut in other game development markets, like consoles and PC development. The use of engines is more than common. Huge corporations like EA have their own technology to serve their cross-platform needs, others use commercial engines, like Cry Engine for their target specific development.

So, if a high-end, complex environment like console development can pick up a game engine and write different genres, where lies the difference for a much low-end environment like Actionscript based development?

Extending the core classes of Actionscript is enough for me

This is not a misconception, it is more of a easy way out kind of thing. When I started coding in AS3 I had this exact opinion. To be honest, extending MovieClips was pretty much all I was doing. I can assure you that it is easier but it made my life harder in the long run, as soon as we needed to move forward it became obvious that this presented some performance issues, not to mention that extending classes is probably the least reusable way of coding in AS3.

Final thoughts…

I believe that this generic opinion towards flash game development and engine technology happens because many developers don’t separate engine from logic, for example, a game that needs collision detection has the collision detection code written within the class that controls the level, assuming there is a class in the first place.

Yet, and with our own engine slowly but steadily maturing, I feel that it makes all sense to take the first step which is to create our own reusable classes and then take the second step and code an engine that makes our life as easy as it can possibly be in the long run. We wrote the first class because it would save work, considered a “full” engine because extending MovieClips was clearly damaging our work and right now, I can’t imagine the amount of code I would need to write to sort some design issues that appear almost weekly.

Vlad out!

More testing on Actionscript’s Math class

As you may have noticed I’m somewhat critical regarding the AS3 Math class. I’m a bit sick to be honest and work was flowing as I wanted to so I took 30 minutes off to test some stuff.

Flooring a number

Getting the nearest low integer of a number is usually achieved with Math.floor(number). If we didn’t have it, we would probably typecast the number to an integer and get the same result. So I looped both methods one million times and measured the results.

Math.floor(number) performed around 150 milliseconds
int(number) performed around 5 miliseconds

Now the bad news is that this works for positive numbers, using int(number) for negative signed numbers doesn’t produce a floored integer. For example int(-2.4) returns -2 where it should return -3.

Rounding a number

Rounding a number will return the closest integer of that number. Again this is usually achieved with Math.round(number) but we can also do this:

One million iterations after the results are as follow:

Math.round(number) took around 165 milliseconds
int(number + 0.5) took around 5 miliseconds

Same issue applies regarding negative signed numbers though, so keep that in mind, but the question is…

Are you feeling the urge of writing a new Math class?

This way we could deal with both performance and doing some arrangements to make negatives work correctly. Problem with this is that we will be calling a static method from an external class. A full working rounding method called one million times took 180 milliseconds against the 165 milliseconds from Math.round(number) method, so there’s loss instead of gain.

Bottom line is that this kind of stuff is a bit like using multiplications over divisions. Depends on a lot of stuff. If your display objects move on a positive x and y axis, you can do it like there’s not tomorrow, just typecast to integer whatever you need to round, but all in all, unless you have millions of Math class operations to do, you won’t even notice the difference.

See you soon,
Vlad

The “make it fast” demo

Yesterday I wrote about making code work then nice then fast. I believe that the fast part was not that obvious on how it can impact your overall game performance. So I decided to put up a simple test that is a demonstration of a real world example.

We will be dealing with two of the finest cpu-cycle hogs in the Actionscript world and you can pretty much apply it to every thing game development related.

The main code

I defined this as the document class of some flash file and then started to add methods to test. Each method was a variation of the previous. At each test I simply added the function call to the constructor. Simple and fast, here’s the first method…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package
{
    import flash.display.MovieClip;
    import flash.geom.Point;
    import flash.utils.getTimer;
 
    public class PerfTest extends MovieClip
    {
        public function PerfTest()
        {
            // The start time
            var startTime:int = getTimer();
 
            // Test method call goes here
 
            // Traces the test results
            trace("Test concluded in " + String(getTimer() - startTime) + " miliseconds");
        }
    }
}

Calculating a distance: 1750ms

The basic test is to calculate the distance between two points. I simply wrote every single detail of code I needed inside a 1 million iteration ‘for’ loop. I created new points, calculated the right triangle legs and then the hypotenuse. Every thing should be crystal clear. One million distances calculated got an average time of around 1750 miliseconds.

1
2
3
4
5
6
7
8
9
10
11
12
13

private function DistanceTest1()
{
    for (var test:int = 1; test <= 1000000; test++)
    {
        var point1:Point = new Point(100, 100);
        var point2:Point = new Point(200, 200);
 
        var leg1Length:Number = Math.pow(point1.x - point2.x, 2);
        var leg2Length:Number = Math.pow(point1.y - point2.y, 2);
 
        var distance:Number = Math.sqrt(leg1Length + leg2Length);
    }
}

Skipping object creation: 505ms

This is one of the biggest issues, one that is often a problem. I’ve read about it, I’ve even defended that object pooling is not that important in many games and then once my code created around 200 objects in less than a second I had to rethink it. Add to that that the objects created had things to do on their own, like moving, colliding and sorts and I got myself a bit of a performance issue.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

private function DistanceTest2()
{
    var point1:Point = new Point(); // Created outside the loop
    var point2:Point = new Point(); // Created outside the loop
 
    for (var test:int = 1; test <= 1000000; test++)
    {
        point1.x = point1.y = 100; // Reused object
        point2.x = point2.y = 200; // Reused object
 
        var leg1Length:Number = Math.pow(point1.x - point2.x, 2);
        var leg2Length:Number = Math.pow(point1.y - point2.y, 2);
 
        var distance:Number = Math.sqrt(leg1Length + leg2Length);
    }
}

The only thing done is here to take the creation of new objects from the loop. Note that I’m not reusing Numbers because the impact is on the creation of an object with the ‘new’ operator.

Other ways to do math: 180ms

The result is the same but the time taken to do it isn’t. Math.pow(x,y) and other methods from the Math static class are very heavy. There are times where it is too troublesome not to use it, but if you can avoid it, do so.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

private function DistanceTest3()
{
    var point1:Point = new Point();
    var point2:Point = new Point();
 
    for (var test:int = 1; test <= 1000000; test++)
    {
        point1.x = point1.y = 100;
        point2.x = point2.y = 200;
 
        // Math.pow(x,y) substituted with a simple multiplication
        var leg1Length:Number = (point1.x - point2.x) * (point1.x - point2.x);
        var leg2Length:Number = (point1.y - point2.y) * (point1.y - point2.y);
 
        var distance:Number = Math.sqrt(leg1Length + leg2Length);
    }
}

One last math optimiztion: 20ms

Calculating square roots is heavy stuff, really heavy stuff. This is not the exact same case as the one pointed previously, but it is very similar. The main difference here is that if you are returning the distance, that is not the correct distance at all. It is the distance powered by two. If you want to use this distance to check against something, you’ll need to power that something also to keep it fast.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

private function DistanceTest4()
{
    var point1:Point = new Point();
    var point2:Point = new Point();
 
    for (var test:int = 1; test <= 1000000; test++)
    {
        point1.x = point1.y = 100;
        point2.x = point2.y = 200;
 
        var leg1Length:Number = (point1.x - point2.x) * (point1.x - point2.x);
        var leg2Length:Number = (point1.y - point2.y) * (point1.y - point2.y);
 
        // No square root is calculated, you need to take this into consideration
        var distance:Number = leg1Length + leg2Length;
    }
}

Conclusions

I tried to address some common performance downfalls that happen very easily but that can be dealt with very easily also. We can argue that this is over one million iterations, but if you are using this kind of code for collision detection, that amount of iterations can happen sooner than you’d expect.

The real problem with performance in game development is not at all a matter of having millions of operations in one spot of your game loop like it is demonstrated here, but having several minor performance issues all around your code that is called from the game loop.

This is just a demo of the kind of things you should look for and solve. There are many others, some of it very game specific. When your game is working as intended, when the design is implemented, it’s time to make it fast because the game should be as smooth as possible and because you’ll probably and hopefully polish the game. That polishing often adds something to the game and that something needs breathing room to work out well.

Hope this helps,
Vlad

The art of game development refactoring

Every thing that starts with “The art of…” sounds so cool doesn’t it? Can’t say I’m a real master at what I’m about to write. This “vision” appeared before my eyes when I made a question about game loop performance techniques in the Portuguese game development community. Out of many answers, one had this pearl of wisdom:

Make it work, make it nice, make it fast!

And I’ll be damned if this simple sentence didn’t influence me since that day… not so long ago.

How I handled my code before…

To put it in simple terms: my code was written to be as close to the end form from start. I coded all the possible performance tricks immediately, wrote reusable code asap and my refactoring was usually very short. This made all well planned projects to be coded in very short terms.

I always had one major problem though: every time the project needed one or more deeper changes I had to recode a lot and, naturally with the same degree of “end code” vision. This means that I used to pre-plan too much and that my code changes were not that agile. More than often this meant that the game was slave to the code and not to the design and this is usually a game killer.

After that sentence, all was different…

Make it work

First objective of every line of code: making it work, no matter what. Is it slow? Is it ugly? Often yes! Does it work? YES! And this is a good thing. Code that works as soon as possible offers you the possibility of being able to access if you need changes or not sooner. This is very important in game development, especially short development like with flash based games.

You will go through all the same design issues, but you’ll do it sooner, you can adapt sooner. That’s the whole point of agile development: you can make changes without compromising features changes or feature additions.

It is very important that you don’t do anything stupid, like having duplicated code. Be fast, don’t be sloppy. It’s OK if you are not paying attention to a lot of details and you are writing in the easiest possible form, but it is not OK if you are copy/pasting code and this is just an example.

Is it has intended? Is everyone happy with the current form?

If yes, refactoring is in order…

Make it nice

If everything is according to plan, you can, you should and you will (I command thee) refactor your code to make it nice. I’m very fashion victim code wise. I like my variables of the same context to have the same length for instance, but it is more than enough if you comment your code, cut the loose ends and have your code ready for you to forget about it. That’s right, move it away from your brain, you’ll need the room for the next iteration. If it is well documented and easy to read, you can return to it anytime.

Here’s a good cliche: Hold in your brain only the things you can’t have written down.

Make it fast

Well… now it’s the tricky part. Your code is probably not the fastest thing in the world, why? Well, you made what you were supposed make, you probably added changes to it, you commented it and made it nice and tidy, but maybe you have some stuff there that could use a little help. Actually I’m pretty sure you do. This is due mostly to the fact that making it work as fast as you can usually doesn’t mean you made it as fast as it can work. Wow… am I on a cliche thing or what?

Every piece of software needs its own set of performance tweaking. It can be anything really.

A world of performance tweaking stuff has been written, maybe I should add mine also one of these days, but there are things that are pretty common.

Heavy calculations come to mind… it’s quite common to use really heavy math operations on a per frame basis instead of pre-calculating this kind of stuff. If you have dozens of objects calculating sines and cosines, making divisions, calculating distances and so on, you will have a lot of performance tweaking ready to be made.

Object creation is a major issue with Actionscript also. A lot of the code snippets I find have new objects created inside some methods that are supposed to be called most if not all frames.

Another common issue is that a part of your code is bottle necking the rest, often causing frame drops. Identify what causes the bottleneck, then either run it from time to time, use a maximum iterations value or segment it in your game loop.

I guess I should just write some optimization articles soon or I can be here forever…

See you all soon,
Vlad

« Older Entries    Newer Entries »