Writing less and keeping a good performance, is it possible? - performance

Question

These past few days I've been thinking of a way to avoid needing to write a lot of code and still keeping a good performance for a Air desktop game I'm developing, as a hobby.
The game is a sort of vertical shooter, that consist of several entities moving and checking collision. There are plenty of different kind of units. Each frame I have something like:
entity.execute();
The simpler approach is to have all different entities to inherit the Entity class, and manually customize them all. This is slow and cumbersome, and hard to maintain. But it's fast, performance wise.
The other approach is to have only one Entity class, and just using some sort of composition to simply add "behaviors". So for example I have a master class with things like types of movements, attacks, etc, and the different entities use them.
The problem with that approach is, calling a function is slow, according to my tests, it is ~3 times slower than just having the code right there (inside execute()).
I'm in a dilemma, I can't find a way to reuse chunks of code to decorate generic Entity instances, and keep a good performance. Seems like I have to use one or the other.
I tried using [Inline], but I've read it's not a stable feature, and I didn't see any noticeable performance improvement, I didn't test it much though.
Any insight is appreciated.

Answer 1

Abstraction through inheritance is a good object oriented pattern, I'd argue that it is not slow or cumbersome to maintain. Separation of concerns would add clarity to classes that inherit your base Entity class; as well, reduce copied code. Interfaces would further abstract concrete types.
ActionScript does not support powerful object oriented language features that you might find in a language like C# - no abstract base class, no partial classes, limited template / generics, limited polymorphism. Composition and decorator patterns would likely force using dynamic classes, which would also slow down the runtime due to type checking.
Perhaps the greater issue is too much business logic in the Entity class. I would think some world container or controller would be responsible for collision detection.
Something you could consider is a physics engine like Box 2D.
There are ports of Box2D built with CrossBridge (formerly Alchemy, FlasCC), which is a C++ compiler for the AVM2, able to run Flash up to 10x faster through lean optimized bytecode that features high performance memory-access opcodes for Flash (known as Domain Memory).
This is how games like Angry Bots or Neverball are made.
Check out Jesse Sternberg's Box2d Flash Alchemy Port + World Construction Kit if using a AS3 physics engine sounds interesting.

Answer 2

There are some common approaches to speeding up the flash in game development. One of them is to avoid using display objects, in favour of simple bitmaps. In this case you have a stage as a bitmap, and keep all your game state in lightweight objects, and then just make a game state snapshot drawn into that stage bitmap data (with copyPixels) periodically (on enter frame, or on timer)
schematically: say you have a game with units
class PseudoSprite {
public var x:uint;
public var y:uint;
public var currentAnimFrame:uint;
protected var snapshotCreator:AbstractSnapshotCreator;
public function makeSnapshot():BitmapData {
return snapshotCreator.createSnapshot(currentAnimFrame);
}
....
}
class Unit extends PseudoSprite {
public var directionAngle:Number = 0;
public var speed:uint = 0;
function Unit() {
snapshotCreator = UnitSnapshotCreator.instance;
}
public function doStep():void {
x = //count x by speed and direction
y = //count y by speed and direction
animationFrame++;
}
}
class Game {
public var stage:Bitmap;
private var objects:Vector.<PseudoSprite> = new <PseudoSprite>[
new Unit(), new Unit()];
public function step() {
for each (var unit:PseudoSprite in objects) {
unit.doStep();
//draw unit.snapshot() to the stage bitmap data
}
}
}
so, you can see: you can build whole units (or all game objects) hierarchy using normal OOP, and get some suitable performance..

Answer 3

After some tests, I've found out that I can just do something like:
public var foo:Function;
and then when I create the entity I can:
entity.foo = myCustomFoo;
And then in the main loop I can:
entity.foo();
This is as performant as calling a native member function inside the Entity instance. Warning, don't create a getter to access your function, it becomes a lot slower.