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…

With all physics and blit done, I went straight ahead into coding the level. First task was to look at what I had done previously and finding out… it would be easier to just start over, which I did! One very cool thing is that a Finite State Machine class I wrote earlier really proved its worth and is the base for all stuff in the level. I really have to go through how the level code is structured as soon as the dust settles down since right now a lot can change and it will probably make no sense.

One thing I had to change was the Manager class. Remember I mentioned a dependency to a specific class that put all in motion. That is easier to manage now.

But the really cool thing I did today was to quickly test a console class! I used Junkbyte’s Console 2.4 and I just love it! With it we will be able to change a lot of aspects in the game without recompiling.

What is happening right now? Visually? Not much, there’s a circle representing Bruce on screen. Code wise there’s a lot of stuff going on. For starters all the level classes (controller, factory, scene, blit, physics, etc) are created and doing their thing, so it’s just a matter of adding features to it. The state management system is just beautiful and it will save tons of work!

What is missing? Graphics and stuff getting kicked!

To celebrate the sensation of being (finally) at full speed, I’ll prepare a sweet thing tomorrow that I hope will be good for new developers and bring a lot of discussion for more experienced ones. Stay tuned!

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!

Nape wrapper is almost wrapped… pun intended, but first, apologies for the missed day 3. While Marco was working on the Hajime trailer I was surfing the waves of wrapping a physics engine. Before moving forward, a big thank you to deltaluca for helping out!

Although not necessarily final, the current wrapper consists of:

Core

This class basically controls the behavior of Nape’s space. Due to its nature, Nape wants simple things to be done quite often, for instance, if you want to change gravity, you need to wake all objects. Core does these small things for you.

Entities

Physics entities basically wrap Nape’s bodies. The abstract entity (if you don’t recall how we are using abstract classes in Bold Pixel, check this out) will offer most if not all of the functionality. Although this means that the class is not really abstract, it also means that classes that inherit from this can and should be used as presets. Currently we have a simple box, simple circle, core walls and a explosion.

As time goes by more and more presets will be built, that’s the whole beauty of it!

Debug View

This class allows for fine lines to appear on screen so we can degub objects positions and so on. Quite useful for blit, not that useful for display objects since it uses Nape’s assignGraphic method. The debug view observes if there is a display object assigned before drawing the debug sprites. This means that if a object is already skinned, it won’t have a debug sprite.

A simple test

The SWF below uses the wrapper exclusively. The walls are a non-skinned PhysicsCoreWalls object. The light wood boxes are also non-skinned so we can see the debug sprite, but the bitmap is handled manualy. The objective of this is to show how blit objects will look if debug sprite is present. The dark wood boxes and the rock circles are a normal body with a assigned graphic, so, no debug sprite is created.

Plans for tomorrow: have a bang with Nape… almost literally! Until then, click the SWF underneath to watch a simple simulation.

Click the SWF above to see the test…

We will be using Nape for physics. Nape is a physics engine developed by Luca Deltodesco (aka deltaluca on FGL and Nape’s forums) that focuses on performance. For more about Nape, visit also the Project Page on Google Code and the Documentation.

We’ve been authorized by Luca to make Nape a part of Bold Pixel. In order to do this work, Bold Pixel releases (starting at v2) will include the AS3 SWC and our own wrapper. The wrapper is being designed to provide presets, easy management and a debug view that can be integrated with both other pieces of Bold Pixel (namely and most evident good use is the blit engine) or a typical Flash/AS3 project. Obviously it will have a lot of conventions and to make full use of Nape you’ll need to know how to use it, but the worst case scenario is that any coder will much less code to write and maintain.

We wish the best of luck to Luca and wish we can pull a lot from Nape and Bold Pixel. As soon as we have a tech demo of what we are doing with it, I’ll post it.

See you all tomorrow!

Vlad out!

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!

A bit of historical perspective

Bold Pixel Engine started with our first flash game because of a simple music management class. Back then, both me and Diogo were coding and I remember (and I admit I deeply miss) our discussions about code standards and organization. I’m a bit of a dictator when it comes to have stuff organized, credits to Marco that has used the word “dictator” more than once and with a large amount of reason and giggles.

Soon our bunch of classes were our own internal library and I even posted some of my own experience while organizing that library. Some of the most important definitions of Bold Pixel where then starting to emerge. July 27th 2009 we announced Bold Pixel Engine was alive.

I was quite excited about it!

The turning page from internal library to public engine was the blit engine. We had so much help from many amazing developers that we would not keep it for ourselves. We wanted to share, we wanted to hear what others had to say and that’s what we did. After two games under his belt and a lot of opinions, the engine was publicly available and his version 1 life was pretty much that until the version 2 turning point a couple of months ago… but I’ll get to that eventually.

What went right!

The learning process was amazing code wise. After Diogo left I really had to raise my standards and get to work and the engine allowed that. Coding such a piece of technology made me contradict myself several times and pushed me forward. I’m absolutely convinced that I am a much better ActionScript programmer now than I was before and I feel I learnt little from the games but a lot from the engine because I forced myself to respect the principles I wanted to see applied to it.

And speaking of principles, these stay true from the first line of code until today and are something that really went right. And these are:

Convention over configuration: Bold Pixel Engine is written assuming some conventions. For example, if the programmer tells the Scene Manager to create a new scene, the previous one and all dialogs will be removed, which makes a lot of sense but maybe it makes less sense to say that all scenes have their pivot point at 0,0. This means that scenes and dialogs are simply added to the display list and that’s it, nothing to configure since there is a convention.

Ease of Use: This goes hand in hand with convention over configuration. If there’s something that really makes my head hurt is to look at the code needed to make something happen in libraries like Flixel and Box2D. I appreciate the effort put in these libraries and the flexibility and power provided but I believe that if we have to configure every single tiny detail the code becomes cryptic and extremely difficult to debug. I don’t mind loosing flexibility because I will create more mechanisms that will help me achieve my goals as time goes by.

Modularity: There is only one dependency in Bold Pixel Engine, which is the Manager class. If you want a single loop or to manage scenes and dialogs, you need to start it up. Apart from that Bold Pixel Engine started modular and will stay modular. The reasoning behind this were two questions I made once:

1. What if I don’t want to use the blit engine?
2. What if I want to add something that will wreck dependencies?

The answer to that was that I wanted it to be flexible, meaning, I can use whatever I want with only one dependency and that’s it. I don’t want the engine to behave like an engine. I want it to be a toolkit at my disposal. I even had a laugh about this.

What went wrong…

First and worst aspect of thing that went wrong was that I did too much stuff that we didn’t need that was requested and I didn’t do it with the same dedication I did the rest. That will never happen again. I’m convinced I got carried away by the kindness of a lot of devs, but we can’t have the engine restricted to the needs of others, which was something I said it wouldn’t happen from start. But what it really makes me feel bad about it was that other devs got involved in the project and this collided with either our work or their work making it a bad solution for everyone.

The second thing that went wrong was that I overcomplicated somethings because I felt it made sense. For instance there is a Scene Manager and a Input Manager and a Manager. All of these managers depend of a Display Object and/or its stage. While it sounds easier to manage code and it looks more tidy and clean, having a gazilion classes doesn’t make it easier to code with. I found myself looking through the classes to find what I wanted… that doesn’t sound like a good thing, right? I mean, I coded it!

And last but not least, I think I really rushed things. The idea behind the public releases of the engine were that we would make two games between each release, which we actually did with v1, but as soon as I had the mechanics ready and all the engine’s juicy code was on a actual project, I went head over heels with it. It lacked documentation, it lacked cross-testing (so, just because I did two games, I should have tried against the two games again) and most important it lacked a critical look and a some honest and critical analysis.

Conclusions

Great experience and I really appreciate all the kind words that I got from developers. I think the really cool thing that most developers got from it was the ease of use, probably the YouTube channel with some nice overview on it. I could’ve written a post trying to sell the idea that we are overwhelmed with joy and l33tness, but I would be failing to be honest. I truly believe that BPE v1 is a great piece of software, but I was naive in the approach and maybe over-friendly in the “pleasing my fellow devs” department.

We have a game going with v2 and I think I sorted my doubts about what is going to happen with the engine. Many things that were wrong with v1 are already gone and there is a lot of stuff that isn’t even started, like moving the Music class which started all this into the current version.

There’s a lot to be said about v2, but this is a hell of a long post mortem and I’ll write about that soon.

So life is treating us so-so. A couple of contracts are approaching the end and after speaking with Marco we concluded that we won’t be doing contract work for a good while. We have too many good stuff right now to work on that has caught way too much dust.

Looking back over the past few months, a lot of what we did was neglected because of contracts. They were alright in a way, some for the money, some for the knowledge, some for something else. But unlike our own games, there’s always a part that is missing, regardless of how good the project is. We feel that has to stop and that what moves us forward is our ability to pursue what we want: pride and happyness.

I also feel that both can go hand in hand with stability and stability is what we found in the past months. We need to step up and do our thing. We need to improve what we did for us.

Project wise, that means that we have to put Hajime on FGL, we have to decided what we want for M:A:D and we have to have time for our most promising game. Code wise this means that I have to reflect if we want to keep Bold Pixel public considering that the current version suits our needs more than it suits the initial user friendliness. I strive to keep things simple, to impose convention over configuration as a standard. Right now I’m not that sure that this will fit developers needs to the point that BPE is helpful.

We’ll see about that in the next couple of weeks. Thanks for reading and the therapy session.

Vlad out!