Nineteen days have gone… WOW! After getting full speed ahead for a number of days, I had a stop for a day… domestic stuff kicked in. A lot of work was finished in those quick days though.
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!
So I coded and recoded, tested and retested a Object Pool class with a high degree of success and frustration. I wrote and tested three different pool managers, here’s the story…
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.
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!
After much thought and discussion by myself or at the FGL chat I made some decisions about how to make Bold Pixel more modular in order to simplify my own work. Since we are still on top of contracts, I couldn’t give enough attention to this but my brain was dealing with it in the background.
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!
Or how to refactor the code from your last game to build up your reusable libs.
First and foremost, thanks to the people at FGL chat that brainstormed a jolly good topic to write about. This post also helps me to rethink my strategy about an issue I have with our core libs that I’ll hopfully address in the future as soon as I make sense.
Basic question is how do I handle the code I used in the previous game to reuse it… I’ll give several examples of how our core classes appeared or changed hoping that you find something useful for your own code and games.
In the beggining there was music
When we wrote Tech Wars, I had to write a music manager that would know when to change tracks. There are three tracks in Tech Wars, all with the same beats per minute, two share the melody but with different instruments and one has a slight variation of the melody. Each track served a part of the game, such has menus, level, and post-level.
Our current music manager has code from Tech Wars. That code evolved from a game specific class to a generic sound manager class and then to two separate classes: sound manager and music manager. These shifts occured as the next games needed or between projects.
What started with Tech Wars is now what we call the core, which is simply a bunch of abstract, cross-project oriented organization of directories and classes that goes from one project to another. It is not something you do, it is something you keep doing, building and evolving. That sound manager class was a bad case of refactoring, but a good start since we had no reusable AS code.
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 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!
Hi everyone, it’s Vlad again.
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.