Seems like on a thing versus some other thing rampage with Application Design vs Game Design shortly followed by this post. I guess that’s a good thing, it means there are challenges and doubts and that we need to research.

This post is also inspired by some books I’ve been reading lately and that I highly recommend: The Productive Programmer that was influenced by The Pragmatic Programmer.

Problem #1

We are writing code and there’s not such thing as writing code without bugs. Sometimes our oldest, most used code, that code that we trust each of our games with gets into a specific spot where a hidden bug appears and we spend hours and hours figuring out what’s happening.

Solution #1 is Problem #2

There are several solutions to this. Writing code that includes testing is in my opinion the best. The problem with this, game development wise and specifically in scripted languages such as AS3, is that this makes the code much slower. The solution was checking for inconsistencies and not performing operations instead of throwing errors and exceptions.

I ended up creating conditions for use. For instance our blit package uses three different types: the core, the object and the texture. The core keeps the state of the whole system, the object keeps the state of what and where to render and the texture keeps the state of BitmapData. If the object did not have a texture it would simply not render. Sounds pretty cool, right?

To be honest… wrong…

Problem #2.1

First problem was the times where the position had NaN value instead of a Number. This rarely happened but every time it did it was a huge headache to identify why and then track the source of the bug down. While this seems unrelated, the fact was the it looked like the texture did not exist. So I had to check if the texture was created, if it was passed, if it was there at all and the worst part was that if the texture was there as it should, where the hell was the problem?

Problem #2.2

Performance wise checking if there is a texture is absolutely dumb! 99% of the times there is a texture present. More, the object class has a visible variable. If the object does not have a texture why is it visible in the first place?

So while apparently I solved a problem by checking if the texture was present and not performing any blit operation if it wasn’t, the truth is that both performance wise (not that serious by the way, it’s just a if statement) and the unwanted problems it induced in the code backfired from time to time.

I spread this type of behavior through the code. While one if statement does not have a large impact in performance, a lot of checking piles up and I had a lot!

Solution #2

A short story and a riddle both taken from those books that explain my thoughts on the ‘final’ (we’ll see about that!) solution for these problems.

The first one was when one of the authors was hired as a consultant for a development project where the coders sent broken code to the version control system. What he did was to create a routine where the version control server would compile the code that was pushed. Every time the compilation didn’t work the server would send an email with the error. With the amount of mail with errors constantly piling up on mailboxes, one of the coders asked if there was a way of not getting that much email. The consultant replied: “Sure, don’t push code with errors!”

The riddle is… what code takes not time to be executed? The one that is not compiled.

So the solution is to write code that allows zero error tolerance while not compiling it. The way to achieve this is with conditional compilation which can be used in several way but these are the ones I believe the most useful is to use code blocks, like this:

private function someFunction():void {
	CONFIG::debug {
		// Development code
	}

	CONFIG::release {
		// Final code
	}

	// Both dev and final code
}

Inside the same function, different code is compiled depending on the current configuration. We can have several checks with exceptions and errors being thrown and then have a ‘don’t check at all’ version in the release configuration.

This is a two stage solution really. On one hand every time I do something stupid, I get errors so my code has to be perfectly implemented at least when it comes to our framework. On the other hand the same code that make me code as best as I can is also the code that does not run in the final version.

That happened with Bold Pixel. At some point in time Bold Pixel became a monster to please developers instead of a tool to be more productive in my purpose to my audience: create games for players! People play games, not code!

I stopped over-engineering sometime ago and started reading about how to become a better programmer not by writing better code, but by writing the exact code to solve the exact problem. This brought a new problem: what to do with Bold Pixel and how to maintain and evolve it? First thing was to start a new package and only bring in classes that I needed but wire the classes up to be as slim and straight to the point as possible. I do that all the time to build up my code base right now, but that’s not all. Here’s the whole process I’m using right now.

Start simple

class BlitObject {

	// Position
	public var x:Number = 0;
	public var y:Number = 0;

	// Rendering
	public var visible:Boolean = true;

	public function BlitObject():void {
		// Constructor
	}

	internal function render():void {
		// Render stuff here
	}
}

The class above can be a stub for a simple blit object. From a OOP perspective it breaks encapsulation completely since x, y and visible variables should be private but seriously, do I really need those to be private or protected and have getters and setters? No I don’t so no need to over-engineer it. The only thing I want to have contained is the render method that should only be called by the blit engine that lives in the same package.

The blit object only responsibility is to copyPixels or draw on a given world position translating camera position on the fly.

Writing a simple class like this is fast, performs fast, case closed.

Evaluate new needs

Now I need a tile map class. This class is also a blit object so following the “is a” versus “has a” rule tile map should inherit blit object. Considering the blit engine has a camera, the tile map won’t move. This brings two new problem.

1. If the tile map doesn’t move, why do I have x and y publicly accessible?
2. I want my camera to follow blit objects so blit objects must have x and y variables (or properties). How can I make tile map be recognized as a blit object, have x and y and have none of those altered?

Sounds messy…

I could write a Blittable interface that would define a render function and getter and setter methods for x and y. The problem is that if there’s something I want to keep in the package scope is the render function and interfaces define public interfaces.

The solution is to convert blit object in an abstract class and have its original functionality moved to a new graphic class.

class BlitObject {

	// Rendering
	public var visible:Boolean = true;

	internal function render():void {
		throw new Error("Abstract function called. Override render()!");
	}

	public function get x():Number {
		return NaN;
	}

	public function set x(v:Number):void {
		throw new Error("Abstract function called or property x not available.");
	}

	public function get y():Number {
		return NaN;
	}

	public function set y(v:Number):void {
		throw new Error("Abstract function called or property y not available.");
	}	
}

class Graphic extends BlitObject {

	// Position
	private var _x:Number = 0;
	private var _y:Number = 0;

	override internal function render():void {
		// Render stuff here
	}

	// Position
	override public function get x():Number { return _x }
	override public function set x(v:Number):void { _x = v }
	override public function get y():Number { return _y }
	override public function set y(v:Number):void { _y = v }
}

class TileMap extends BlitObject {

	override internal function render():void {
		// Render the tile map
	}
}

Problem solved. The class responsibilities are much better defined.

1. A blit object renders and has x and y coordinates. Since it is an abstract class everything we try to do with it directly will result in an error.
2. A graphic is a world movable blit object that renders by copyPixel or draw.
3. A tile map is a world static blit object that renders very large objects by copyPixel or draw  based on a predefined xml specification.

Conclusion

What’s the conclusion here? Well for starters by this time I’d have a couple of interfaces and probably a helpers. I’m not saying it is wrong to have interfaces and helpers, actually it is preferable, but it would be coding for the sake of coding instead of coding for the sake of making a game. It took me 10 minutes to do this and while I was at it the BlitObject class also extends a ListObject class that really speed up the iteration, addition and removal of objects from the blit engine.

Still… I did repeat my self and the code has suffered another refactoring since then. I’ll leave that for another post but I wonder if you know what’s repeated…

By the way… choose 720p and full-screen it.

Objective: Centralized management of pools

This one was easy. There is a PoolManager that has a static method to get a pool for a certain class. If the pool for that class does not exist, it is created, if it does, it is returned. Objective achieved.

Objective: Lightweight pools

I don’t need pools to be amazingly complex, I just need the pools to get the job done, which is: be faster at getting new objects at the expense of memory. That didn’t go very well. The pools were lightweight alright, but I was not able to make it any faster than creating a objective directly.

This lead to the three versions of the pool manager and still the best performance gain is below 5% for any Bold Pixel entity. I was so frustrated, but then I saw the light!

Not my fault really

After testing and more testing I had a epiphany! What if Bold Pixel’s entities are simply too light to make pooling worth. It would not be something I’d consider. It really never crossed my mind that a instancing a object could be faster than getting it from a linked list kind of pool, but it is and the classes I was dealing with are somewhat heavy considering the inheritance and and composition of several.

The highest gain I got was 8ms in 1000 object. Creating 1000 objects took 54ms and getting 1000 objects from the object pool took 46ms.

The unexpected success

So either my classes are very light or flash behaves rather poorly in managing this. So I tested against some movie clip I had around. Creating 1000 movie clips took 102ms, almost doubling the worst case scenario.

Not only I was happy to note that my classes are lightweight, both pool manager and entity type classes, but I also proved that getting movie clips would make a difference.

Conclusion

I’m not happy with the pool manager for now, but I’ll work on it some other day. It gets the job done, but the objects I really wanted to make a better use of pooling are the ones that problably will have less impact.

If I regret anything in this bits of code is that I over engineered it at first. Tomorrow blit engine!

Inheritance Spaghetti

The problem presented was somewhat simple. My early coding of the blit engine got tangled in the dreadful inheritance headaches. My solution to it was to create one class per major responsibility. It worked fine until the time I decided to expand one of the classes to do something it wasn’t designed to do. So on one hand I solved the inheritance problems but on the other I lost modularity. At this time I had a OOP doubt that I expressed in the FGL forums and the discussion that started there really helped me to move in a different direction, one that I had never considered.

More over I said that I would not support requests that didn’t deal with deal with real problems we had in our own development. And while I stick to that, I couldn’t help but to think: what if Bold Pixel could help someone but it missed one little tiny feature? While this was puzzling me, there was real problem, one with impact in our development that was taunting me…

The case of Blit vs Physics

So Bold Pixel has a blit engine and it will wrap a physics engine (more about the physics engine this later this month) so the question that was on top of the table was: considering there is a blit entity and a physics entity, which one should access the other? Whatever the answer was, modularity was lost in the sense I imagine it. I don’t want blit to know physics and I don’t want physics to know blit!

After a nice chat with Antriel at FGL (thanks mate!) I got to know the Strategy Pattern and all my problems were solved. In simple terms, I will be defining interfaces for all interchangeable objects but the implementations of the interfaces can exist anywhere. In the case presented, a blit entity will have its spatial properties (rotation, x, y and scale) defined by a spatial interface. By default it will be a simple class and it’s needed since the properties of the spatial interface are needed to render bitmapdata. A physics entity will be a implementation of  the spatial interface, so if I want to use physics on a blit entity, I simply write: myBlitEntity.position = myPhysicsEntity;

Visibility and Access Issues

This brought another problem. Bold Pixel has always kept its inner “stuff” hidden. The objective was this was to keep the auto-completion short and the use easy preventing mistakes. In order to implement interfaces I would have to make a lot of code public.

The answer to this would be abstract classes, but ActionScript3 does not support it. That will be addressed with simple naming and convention over configuration. Any class in any namespace in Bold Pixel that starts with Abstract will only have the simplest shortest implementation needed for something to work. For instance, if I want a blit entity that draws pixels I will have to extend a AbstractBlitEntity class (I guess that will be the name) but that brings another problem…

So ActionScript does not support abstract classes… convention will say that Abstract defines an abstract class.

Namespaces (to wrap this up!)

To have a better code organization I will need more packages and to have more packages I will need to provide access to classes in different packages. This will be done with namespaces. The only thing that annoys me is that Flash Develop in the current version (3.2.2) does not support code-completion with custom namespaces, but what matters is that using custom namespaces solves two problems. First I can have a bunch of private functionality like I like, but second, any coder can with a simple namespace use extend Bold Pixel to his own needs in a full modular way.

While I reckon that this is all just in my head and that a lot of work will have to be done and even considering that probably this will make Bold Pixel a little bit more complicated to the average coder, I feel it sorts a lot of questions, so: Namespaces and Interfaces FTW!

Behaviors

A long time goal: behaviors! What is it? How does it work? Well… imagine you write this line of code in a Bold Pixel Engine entity:

entity.behaviors.face.mouse();

And from that moment on, the entity will always rotate to the mouse position. That’s a behavior.

Imagine that you could say that instead of facing you’d want it to rotate to the mouse position at a given speed, or with a tween, or that you want it to evade another entity or to find the path to a certain point. Now imagine that behaviors could applied to time… that you could tell your engine time would slow down so you could see all in slow motion…

Well… I wrote two behaviors and it works like a charm!

Flash Player is somewhat smart

I’ve noticed that if you copyPixels() or draw() outside the target bitmapData area, it won’t render anything. Having thousands of objects outside the rectangle area is absolutely meaningless, even if you apply a transformation matrix and draw.

I thought about the possibility of creating a camera object… suddenly this possibility became obviously closer since there will be no need to verify if an object is supposed to be rendered, Flash Player does that for me, I just have to pass the right rectangle… awesome! or at least I’m thinking it will be!

Filters

I really needed a rest a couple of nights ago… so nothing better than writing some new functionalities! My goal was to write filters to apply in layers. After noticing that most flash filters need a BlurFilter applied on top of it, I decided to make it simple and just work with one BlurFilter and one ColorTransform in each layer.

BlurFilter is a huge performance killer, so I played around with only applying the filter to whatever the area the filter needed to be applied to and it works great! The bigger the area, the bigger the performance impact that’s for sure!

ColorTransform seems to have no impact. I’m betting that the pixel color is calculated directly when drawing… if this is true… it’s quite smart!

All in all and since I didn’t want to use any other filters for performance issues, I noticed that with just a little tiny bit of patience, blur and color transform can do most of the cute effects we might need, from shadows to glows to motion blur.

Brain melting the possibilities

A camera with behaviors, like moving to an area with tweening. Flames coming out of a structure and then exploding in thousands of particles flying around with fire trails. Zillions of projectiles flying around in a huge map… wow… this weekend really caused a brain melt.

Need to finish the tutorials to Bold Pixel Engine v1 because v2 is already shaping.

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!

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

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

It’s 10:52AM, 30 degrees Celsius if you stand in the shadow and just a couple of hours ago I hit an issue with our current project. Basically static data regarding gameplay was becoming completely unmanageable. Before moving forward I decided to rethink and drew how my classes were organized.

Let me tell you what this is… Data and Gameplay are folders, packages in AS3 terms. Tokentype1, Tokentype2 and Constants are classes that hold data in the form of static functions and constants. LevelController, LevelView, TokenController and TokenView are classes that are either controllers or views of my gameplay objects.

This is how I’ve organized most projects until now, so what’s the problem? For starters, all games until now have only one token type. This game has two but it will have more. I was about to actually copy/paste a method from TokenType1 class to the TokenType2 class… you know how bad this is right?

On top of that a new problem was present for a couple of days. Some variables names, class names and query methods conflicted, not logically but in terms of what I was reading while coding. Building, IsBuilding, buildings, building and so on… variables like type, code and state also weren’t 100% clear.

So I decided that it was time to redesign and refactor before it became too nasty. Here’s the result:

I simply took the MVC pattern seriously and created models for both level and tokens. On top of that I changed all ambiguous variables, states and methods to be named consistently throughout the project.

The LevelModel is nothing more than the old Constants class. There’s no big difference for now except that when gameplay is closed and we move to other stuff, I’ll have to create models for all the other stuff instead of having all constants inside one “global” constants class.

The TokenModel is the big change! It holds all the stuff from TokenType1 and TokenType2 classes, but now I can guarantee that there are no duplication of methods, arrays and so on. Big part of this arrangement was to deal with the inconsistent naming of variables and so on.

I’m very happy with the solution, now, if you excuse me, I’ll get back to coding game functionalities.