I’ve been working on re-implementing a simple Java game in OpenFL. Because I’ve been basing my Haxe/OpenFL code on (very old) Java sources, I’m concerned that I’m not grasping the best practices regarding OpenFL’s event-driven architecture.
At this point, many of my game objects follow this pattern:
class Game extends Sprite {
var entity:Tile;
var entities:Tilemap;
public function new() {
init();
}
function init() {
entities = new Tilemap(...);
addChild(entities);
entity = new Tile(...);
entities.addChild(image); // Do this many times
}
function update() {
// Game logic at a fixed interval
}
// A few examples of common code in these functions
function render() {
// The alpha technique
if (state1) {
entity.alpha = 0;
} else {
entity.alpha = 1;
entity.x = xMouse;
entity.y = yMouse;
}
// The add/remove technique
if (state2 && !state3) {
entities.removeChild(anotherEntity);
} else {
entities.addChild(anotherEntity);
}
// I want my tiles to render in a certain overlapping order that changes
// every frame
entities.sortTiles(comparisonFunction);
// But I always want my cursor tile in the front
entities.addChild(cursorEntity);
}
}
In the main class of the program, the game loop is handled as follows:
class Main {
public function new() {
addEventListener(Event.ENTER_FRAME, onEnterFrame);
}
// update() and render() trickle down all game objects
function onEnterFrame(event) {
var elapsedTime = Timer.stamp();
if (lastTime < 0) {
lastTime = elapsedTime;
update();
} else if (elapsedTime - lastTime > SECONDS_PER_TICK) {
var count = 0;
while (elapsedTime - lastTime > SECONDS_PER_TICK) {
if (count > MAX_TICKS_PER_FRAME) {
lastTime = elapsedTime;
break;
}
update();
lastTime += SECONDS_PER_TICK;
++count;
}
}
render((elapsedTime - lastTime) / SECONDS_PER_TICK);
}
}
As a result of this architecture, I find myself (a) passing Tilemaps and other “rendering management” objects all over the place, and (b) fooling around with render() functions that are either trivially simple or (seemingly) heavy-handed (removing a child every frame, rather than just getting rid of it once). Interestingly, this architecture was actually recommended in a thread in this forum community a few years ago.
I found this thread on another forum with someone asking similar architectural questions, and the answers seem very useful conceptually. However, the pseudocode is written with C-style languages (and events) in mind, which obviously differs greatly from a framework like OpenFL with pre-existing event systems in place.
I’ve subsequently searched for tutorials or documented examples of similar game architectures in OpenFL, but to no avail so far. Could someone more knowledgeable than myself point me in the right direction for further learning/research, or be so kind as to present their own understanding of game loop best practices in Haxe/OpenFL?
I feel that questions like this are asked far too often by unfamiliar developers like myself, so I apologize for any noise I am adding to the forum.
