Archive for the ‘Software Engineering’ tag

Brain Melt

I’ve been writing and re-writing a lot of code lately. Somewhere between the work to be done and the work I want to see done, there are dozens of thoughts and discoveries that are worth sharing. Some are puzzling, others are simply brain melting.

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:

1

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.

Engine misconceptions

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

Each game is an engine

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

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

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

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

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

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

Extending the core classes of Actionscript is enough for me

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

Final thoughts…

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

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

Vlad out!

More testing on Actionscript’s Math class

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

Flooring a number

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

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

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

Rounding a number

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

One million iterations after the results are as follow:

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

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

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

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

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

See you soon,
Vlad

The art of game development refactoring

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

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

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

How I handled my code before…

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

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

After that sentence, all was different…

Make it work

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

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

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

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

If yes, refactoring is in order…

Make it nice

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

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

Make it fast

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

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

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

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

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

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

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

See you all soon,
Vlad

Model… revisited…

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.

« Older Entries