Friday 27 June 2014

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.




Wednesday 18 June 2014

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)

Sunday 15 June 2014

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 ? :)

Friday 13 June 2014

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.

Thursday 5 June 2014

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.

Wednesday 4 June 2014

I'm still not happy with it ......

So it is going into version 4.......... proper design document this time, and I know what I want to do. I'm hoping this will be the last one.

Monday 2 June 2014

A working demo of C/E Systems

Squares and Crabs
There's now a useable demo of this system on https://github.com/autismuk/Comet.

You can see a piccy of it here. It has several components, mostly very basic - position, size, colour, coronaObject, velocity,power and so on.

Then there are two slightly more complex ones that create a sprite and a square respectively.

Because it is a hybrid, the controller isn't a component though. Partly because if it was, you'd have one every time you created an entity. What it is is a link to an instance of the controller.

So what it does is move the crabs and squares round in response to the controller, at varying speeds.

The systems are as follows :

There are position/CO and size/CO and colour/CO that update the corona object from the position, colour and size components.

There's a controller/velocity/power component that updates the velocity from the single controller instance. Power is how fast it goes, the scalar value of the velocity as opposed to the direction which comes from the controller.

Lastly there is a position/velocity component that updates the position from the velocity. This last one uses a thing called deltaTime (okay, I pinched the name from Unity ....) which scales movements to consistent units.

It did strike me that people might know what C/E systems are.

You can read about it here http://en.wikipedia.org/wiki/Entity_component_system

Basically, think of the things on the screen as entities (e.g. each crab is built out of an entity) that are built out of components, which are things like speed, position, alpha, a sprite and so on.

The nifty thing is the automation. If you add a velocity component it automatically moves the position component. If you add a controller component it starts being controlled by it. If you remove it, it takes it away again.

It sounds a bit mad, really. But one of Corona's biggest rivals, Unity3D, works pretty much like this.

Sunday 1 June 2014

And more stuff about Entity/Components/Systems

So Comet is now in its third version.

Like many systems, ECS work okay in theory but there are often problems in practice.  One of the problems is the conceptual idea that components should be very basic, data only.

The problem with this sort of concept is it works okay up to a point, but if you want something as a dedicated component which does a lot you end up with umpteen systems to handle it.

I experimented with this in v2, which had a joystick control component (touch one), that you could just plug in and it worked as if it was (say) a square in Corona. All you had to do was something like:

spriteEntity:addC("joypad")

But what it did do was operate on the components that do work as very simple ones - coordinate pairs, velocities and so on. I had this very simple demo which was a couple of sprites with coordinate positions, velocities and sizes. You could then add the joystick component and it would update the velocities and so on automatically, which propagated into the positions, which meant in practice that you controlled the sprite with the joystick automatically.

This is, I think, the way forward, having code not so much in the components as associated with it. So your component members might be a joystickReference only, but the component has an associated constructor and destructor that create and delete it as you add or remove the component.

It seems to work quite well, though v3 (again, learning from mistakes and better engineered - I've never written an ECS framework before) doesn't do this yet it probably will soon.

In many ways, what I'm creating is a 2D Lua based version of Unity3D without the GUI interface (and without the enormous price tag)

This is what Unity does pretty much, taking components that do stuff and sticking them together. But it does it at a higher level than classic ECS systems do. All Unity really does is operate on the properties directly via the GUI, which looks very clever but actually isn't that difficult to do, it is like Visual Studio, you just expose properties of objects that you can then manipulate via a slider or checkbox or whatever. There are javascript and QT systems that do the same sort of thing.

It is a pragmatic ECS (sometimes known as a hybrid). You say, well, there are some things the model just doesn't fit, so try to use the best of both worlds. But you try to keep, as far as possible, the data driven idea - v3 does this, when you create an entity you give it a pile of data for its components (and this could be extended to tell it what components as well) but you allow simplifications like having a singleton map which you can access directly.

If you think in terms of say, Pacman, you can see how the various items in the game might be entities - ghosts, pacman, fruit, score, power pills and so on. The collisions you can do. You can control them , none of this is difficult.

The odd thing is the map. Is it one entity; or lots of entities (are all the dots entities, if so is this workable ?). All the other entities access it all the time, do you really want to put all that through a message system ?

The answer - pragmatically - is like the joystick. The map is a single entity which you can put things on, and interrogate to find out which way you can go (say). The individual dots in the maze are managed by the one entity.

If you didn't do that, and had 200 of the dots or something as individual entities, you'd have to render them all individually, you'd process them in your systems, and you'd have to check collision for all of them (or write special collision systems).

In other news (?) the font library does seem to be fairly stable, but we do seem to be having problems with BmGlyph.