I should update more often.

Well, Phantom Slayer is pretty much done and dusted. I'm actually really pleased with it, and there's an awful lot of reusable code in there.

It all seems to work really nicely ; it's dead easy to build Composer Scenes, and change them, there's a library which does tutorials for games, where it sort of plonks comments on top of the game, again, pretty much automatically.

It's open source ; it's another demo for Executive really, but I'll probably build it and upload it.

https://github.com/autismuk/Phantom-Slayer

9 1/2 days

Well a fair bit has been going on ; I finished the Executive and got the state transition working, and
that now works like a simple, but proper game.

I'm working on a remake of a game called Phantom Slayer, which was originally for the Dragon / TRS80 Co-Co computer (a 6809/6847 based home computer from the 1980s).

It originally looked like the one below (and with a switch, it still does look like that), pretty much - it's a fairly simple explore a 3D Maze sort of game.

It's a useful test more than anything else (though the original game is really creepy) writing to something of a specification rather than something just knocked together to test the Executive system.

It can be sort-of played (at the moment you can walk about and teleport but not do anything else) and it is at https://github.com/autismuk/Phantom-Slayer if anyone wants to tinker with it. I will probably put it in the App stores when I've finished just for the sheer heck of it.

As it is under development, obviously, both it and the Executive are prone to change. I did make one change ; the ability to pass parameters into FSM events and through into the preOpen (think 'Create') phase of the scene manager. Though this is a backwards compatible extension ; I'm hoping that there won't be any major changes.

Dumb Design Decisions 101

Feeling dim this morning.

I realised I'd done something really stupid. OOP is supposed to be about Classes and Object Instances, right ? In a 'hack' designed to get round the problem of attaching game objects to instances of executives, I'd designed it so that when you created a new GameObject Class to subclass (the Executive:createClass() method) you provided an instance of a parameter.

So .... all instances of that class now belonged to one, and only one, instance of the executive.

Fortunately this dumb mistake has been fixed and the executive is where it belongs in the object constructor. When you create an object of some sort, you tell it which executive it is to be added to.

This is a hangover from SOE, which is the same basic idea, except there is one, only one, executive, it's a singleton.

I'm writing a scene sort of thing. The idea is that there is a Factory Class for executives, this is the equivalent of a Corona Scene. This factory class has a constructor/destructor (for resources), and methods to create a new 'scene' (e.g. create an executive and populate it with objects', start it, and methods to stop it, and tidy up (delete the executive). The last two don't do much, as the executives objects are responsible for actually stopping it (as in, say, Flappy Sphere, the game stops when there are no bird objects left).

These belong to a global class, probably called 'Game' which is a collection of such, and it just transitions between them using an FSM and the TransitionManager library.

To this end, I've added a couple of things ; there is a very simple finite state manager, which just maintains a list of states and states events , and broadcasts messages as you switch between them. Additionally, every executive now has, on demand an owning displayGroup object - I need this because there needs to be some way of having all the graphics in a particular setting together so  you can transition them in or out.

With a bit of luck it will be dead simple. I will end up with a FSM for the game outline, which has attached Executive Factory objects, and the FSM just switches from scene to scene automatically.

You can see the outline of this at the end of Flappy Sphere (at the time of writing)

Flappy ... Sphere ?

I have written a separate simple game, this one called 'Flappy Sphere' (guess what it is based on ....) which includes particle effects and bitmap fonts.

This is complete and working, but I want to add an FSM library and associated Scene manager, and Flappy will become a host of that (at the moment it is a 'one scene' game, so to speak.

Flappy Sphere is about 250 lines of code (including comments), but that's with external libraries for the particle system and bitmap font.

There's not much to it really - pipes, 'bird', score, 'get ready' text and a background that pass a few messages about - so for example, the background sends a message to the bird when it is tapped.

The neat thing about this is it is trivially easy to add more birds (spheres ?) just at will, just by creating them, bit like in the 'Pong' demo. Or pipes, want 25 pipes on the screen, dead easy. You can even have more than one score and it will work (because the score is implemented by messaging)

The only code that is actually specific to multiple 'birds' is when a collision is detected and a bird blown up, it checks to see if there any bird objects in the game before ending it.

So you could add another bird just with:

Bird:new({ gravity = 100, x = 100 })

and it will just work.  Flappy Bird with several birds is really hard :) Changing the gravity for different birds is even harder.

Some things are more optical. When you move a sphere it doesn't use messaging to query for collisions, it gets a list of 'obstacle' tagged objects and asks each of them if it's hit them by calling it's 'has collided' method. It's a trade off between decoupling and efficiency. Isn' t everything ? :)

Executive is up and running.

The executive engine/framework is up and running, this is an example of it running.

There are four classes here - the bat, the score, the ball and the controller, everything is controlled by the executive.

The controller is a self contained object, so it just can be loaded and used - you require it in and attach it, and you can then access it via executive.e.controller - I decided not to use a messaging system.

Messages are used for the ball delay at the start, to update the score, and the balls each broadcast a message to 'obstacles' to check for collisions.

It allows you to switch pretty much as you want between asynchronous messages and direct messages - so for example to increment the score you can either use

self:sendMessage("score",{points = 10})

or you could with an extra line or two do it something like

exec.e.score:addScore(10)

I quite like this design. This code is almost completely unchanged from the SOE demo, except for the basic API stuff which has changed slightly.

Because objects are automatically attached (normally, the controller isn't yet) then you can simply add bats and balls as often as you want and it just works.  The main code looks like this:

Bat:new({ x = 32 }) Bat:new({ x = display.contentWidth/3 })
for i = 1,33 do Ball:new({}) end Ball:sendMessage("ball",{},1000)

Two bats, 33 balls, and a delay of 1000ms before balls receive an empty message which tells them to start moving.

One problem, which is a lua issue, is with executive objects now being non-singletons, when you require an object it doesn't know which instance of the executive to attach itself to. So at the moment it is added as a mixin (this is used for objects with non-nil metatables, like Corona display objects, see the score in the pong Demo as an example).

executive:addMixinObject(require("controller"):new({}))

i.e. require the controller class, create a new instance, and add it as a mixin object. May be a case for having an addRequireObject("controller",{}) method. I will give it some thought.

More experimental engines

I got Comet to where I want it, but then decided it was too theoretical. Coding is a mixture of structure and pragmatism, and both a classical OOP design and a pure component design are too much of one.

So I'm working on "executive" which is a combination of the two. It is an object aggregator and controller, with built in functionality - currently updating, inter object messaging and timers, which allows a semi-component approach via mixins.  Objects are tagged (the tags are recorded in the executive) and it can be queried for all objects with 'ammo' tags, or whatever.

For its frame system, tagging an object with 'update' causes it to have its onUpdate() method called on a regular basis.

It's on its second design, the first one , called SOE (Simple Object Engine) is okay, but I improved the design and cleaned it up.

None of these various engine ideas are particularly long, maybe a few hundred lines of code each.

Because the executive itself is an object, I'm going to try and build a FSM/Composer system where each scene is an Executive object, thus making the scene transitions semi automatic.

So version 4 of Comet is now the master branch

and can be downloaded from https://github.com/autismuk/Comet - there's a very simple demo there with rotating crabs which is just really a placeholder.

Later on I should bring the controller thing back and a better commented demo.