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!

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!

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!

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.

I’m saying object, not as an instance of a class, but rather as an abstract game object from a design point of view.

Let’s break the pattern down into manageable parts… after all, that’s exactly what the pattern does.

Model

The model is the data representation of your object. Outside game development, model refers to the data model, usually supported by a database engine. From a game development perspective, model is what your object is, like a level, a platform, the player character, an enemy and so on. If you coded a class that represents something, you have already created a model already.

The main difference with application development is that the data models you use are not persistent and are discarded when they’re not needed.

The idea you should retain game development wise is that your “typical” class design, considering variables, constants and so on is your model, even if this is not 100% accurate from the pattern point of view.

View

The view is the visual representation of your object, which would be any display object, from a movie clip to a bitmap. It is nothing more than this.

Controller

The controller glues everything together! It is the logic behind the actions of your object. Imagine a player character that moves with WASD for the actions Jump, Crouch, Move Left and Move Right. If the player presses W the controller will receive the event and order the view to run the jump animation. Now imagine that some enemy shoots the player character while it is jumping. The controller receives the information that the player was shot, informs the model to subtract damage to player’s life and orders the view to run the hurt animation.

Encapsulating all together

The easiest way to implement OOP on your AS3 game is to simply extend some movie clip to a class and write all code there. With MVC, you need to encapsulate a bit. There are many ways to do this, but this is how I do it.

My controller and view are only one class: the main object class. The view is separated which allows me to have a cleaner interface when I’m working and the possibility of extending or not the view class. This offers a wide range of possibilities since the view class can hold a large ammount of functionality, such as movement patterns, pathfinding and so on or it can simply be the display object.

Controller and view work together regarding data and logic. As I see it they’re not even separarated as a proper implementation of MVC. This often means that a simple state machine is at work, like in the example below.

package
{
   // This is my controller/model class
   public class PlayerController
   {
      public function PlayerController()
      {
         // Creates the view
         playerView = new PlayerView();

         // Code to add it to the level movie clip goes here
      }

      public function Update()
      {
         // This method is called from the gameloop

         // Depending on the state, chooses actions
         switch(state)
         {
            case IDLE:
               playerView.UpdateAnimation(IDLE);
               break;
            case WALK:
               playerView.UpdateAnimation(WALK);
               break;
            case HURT:
               playerView.UpdateAnimation(HURT);
               break;
            case NONE:
               SetState(IDLE);
               break;
         }
      }

      public function SetState(newState:int)
      {
         // No point in doing something that
         if (newState == state) return;

         // Only does something different if the player is hurt
         if (newState == HURT) life--;

         // And assigns the new state
         state = newState;
      }

      // Vars ---------------------------------------------------------------

      private var life:int = 100;      // Hit points
      private var state:int = NONE;   // Current state

      private const NONE:int = 0;
      private const IDLE:int = 1;
      private const WALK:int = 2;
      private const HURT:int = 3;

      private var playerView:PlayerView;   // The view (displayObject)
   }
}

A word of caution

MVC is very powerful, easy and intuitive, but use it when your game asks for it. If you have an object that only needs a couple of methods, by all means, simply extend the movie class or whatever you are extending. Use it to break the complex objects into manageable parts.

Factory

I try to use design patterns to the best possible extent of my ignorance about them. I want to set this straight because like anything found on the Internet, everything here is potentially wrong or a lie.

My view on design patterns and so many other things code wise is much more from my own personal perspective and experience, if you want to know more, there’s much more to learn about it, this is just how I see it. 

What is a Factory?

Factory was probably the first I was taught (thanks Diogo!) and one that I used in every single game. From ballons to bullets, every time the need to create objects arises, factory was my choice.

The only purpose of a factory is to create and return objects. From a game development point of view this is useful since the factory is by default reusable code within the game.

If you code a factory class you can use it as a priceless source of objects, from projectiles – as in this example – to enemies or whatever you want really, it’s up to you.

Example

Imagine you are coding a shooter where the player has four possible weapons: machine gun, rocket, missile and mines. Every time the player shoots, the player object would have to decide what to build based on the current weapon. It would be something like this:

package FactoryExample
{
	import flash.display.MovieClip;

	public class NoFactoryPlayerClass
	{
		public function FireWeapon() extends MovieClip
		{
			switch(currentWeapon)
			{
				case BULLET: CreateBullet(); break;
				case ROCKET: CreateRocket(); break;

				// And so on and so forth...
			}
		}

		private function CreateBullet()
		{
			var bullet:Bullet = new Bullet(rotation);

			// Plus, add bullet to level bla bla bla
		}

		private function CreateRocket()
		{
			var rocket:Rocket = new Rocket(rotation);

			// Plus, add rocket to level bla bla bla
		}

		private var currentWeapon:int = BULLET;

		private const BULLET:int = 1;
		private const ROCKET:int = 2;
		private const MISSILE:int = 3;
		private const MINE:int = 4;
	}
}

By the way, the code here is for clarity, I didn’t even run it to check for errors.

What we have here is bad enough by the way. CreateBullet() and CreateRocket() would roughly have the same construction for instance, but it can get much worse. What if you want to use one, some or all the weapons in different enemies or you want to have more weapons?

I’m guessing… copy/paste?

That’s why you should use a factory from start: because you can manage all your projectiles from a single point and you can extend it to have more weapons without duplicated code which you’d probably maintain with a higly dangerous dosage of copy and paste.

This would be our factory class:

package FactoryExample
{
	public class Factory
	{
		public static function CreateProjectile(type:int, data:* = null)
		{
			/* Bullets and Rockets only receive an angle from which they'll
			 * calculate the vector.
			 * Missiles - see FireMissile method.
			 * Mines just stand still. */

			switch(type)
			{
				case BULLET: 	return new Bullet(data);	break;
				case ROCKET:	return new Rocket(data);	break;
				case MISSILE:	return FireMissile(data);	break;
				case MINE:	return new Mine();		break;
			}
		}

		private static function FireMissile(enemy:*)
		{
			// Gets the angle from the level object to create the missile.
			var enemyAngle:Number = LevelObject.GetAngle(enemy);

			// Creates the missile with the target enemy and the angle.
			return new Missile(enemy, enemyAngle);
		}

		// Projectile types ---------------------------------------------------

		public static const BULLET:int	= 1;
		public static const ROCKET:int 	= 2;
		public static const MISSILE:int	= 3;
		public static const MINE:int	= 4;
	}
}

In this case, the factory is a class that offers static functions, so you don’t have to instantiate an object from the Factory class. Note that the CreateProjectile receives the type (duh!) and some other data that can be anything or nothing at all.

The purpose of this is to pass angle to bullets and rockets, the target enemy to missiles and nothing to mines.

So now, any class that would need to fire a projectile would need a method like this:

package FactoryExample
{
	import flash.display.MovieClip;

	public class WithFactoryPlayerClass extends MovieClip
	{
		private function Fire()
		{
			var data:* = null;

			switch(currentWeapon)
			{
				case Factory.BULLET: data = rotation; break;
				case Factory.ROCKET: data = rotation; break;
				case Factory.MISSILE: data = targetEnemy; break;
			}

			var projectile:* = Factory.CreateProjectile(currentWeapon, data);
			// Do more stuff with projectile
		}

		private var currentWeapon:int;
		private var targetEnemy:*;
	}
}

And to end…

Imagine that the enemies in your game have a predifined weapon… instead of a bunch of code you will only need one line in you enemies classes:

var projectile:* = Factory.CreateProjectile(myWeapon, otherData);

It can’t get any easier than this!

I hope this helped you sort how factories can help you. Take into consideration that you can use a factory with pools of objects, this is an example that creates all objects on demand. There’s a lot more that can be done, but the rule of thumb is: a factory can be the answer to many object creation needs a bit everywhere, but in game development it really shows what this design pattern is capable of.