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.

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.

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.

More stuff ....

Not posted much for a few days - this is what I've been up to.

1. Bug fixing / improving / tweaking the Bitmap Font system, known as "Font Manager". Even though it doesn't. This is now perfectly useable (padding is not supported but will be added soon) and pretty stable and appears to work.
2. There's a new repository called 'Particle Classes' which are some simple classes which wrap the Particle System in Corona.
3. I've written a Component/Entity/System library (called 'Comet') which is an alternative game framework. This is still really in beta, but there is a demo of it in the github repository.

https://github.com/autismuk

Animation Manager renamed

To Coccyx. Well I got fed up with dull names. It's a little bit of the spine .....

I hope to start some more experimenting with this now I'm happy the Font tool is in a stablish state.

https://github.com/autismuk/coccyx

Re-engineered Font Manager

The font manager has been replaced by something which does the same thing, but it has been rebuilt largely from scratch.

It offers most of the same functionality, actually slightly more. The main change is that it is now a display object in its own right rather than pretending to be one. So you can use it much as if it was a display.newText() object.

The one downer is that if you turn animation on, and you rely on the system to remove it, (e.g. garbage collection in Composer) it will keep the reference to the bitmap string - it needs it to generate the animations.

So in your exit events, turn animations off on any bitmap strings you use (or remove them). If it's not animated, there's no reference.

https://github.com/autismuk/Font-Manager

List of changes

a) setScale() no longer functions. Adjust font size to suit, or scale overall.

b) there is no FontManager object, really, though setEncoding(),setTintBrackets() and setAnimationRate() still work as there is a 'pretend' FontManager. These are now all methods of BitmapString, though all affect the global state of the fonts, so setAnimationRate() sets the rate for all the bitmap strings, not just one.

c) curve and scale have been switched so they are the right way round. Previously they were 'visual' opposites.

d) FontManager:Clear() does not exist. The primary reason for this is that it maintained a reference to the object. If there is sufficient demand I will add a tracking of creation on demand approach which will do the same thing.

e) You cannot directly subclass BitMapString, because it is now a mixin.

Your new method for a subclass should look something like

local function SubclassBitmapString:new(font,fontSize)
local newInstance = BitmapString:new(font,fontSize)
.. do class specific initialisation.

.. create mixin - you can do this with a for loop as well.
newInstance.someFunction = SubclassBitmapString.someFunction

return newInstance
end

f) Curve is now a static class in its own right rather than being a method of FontManager.

Support for tinting added.

FontManager can now tint characters - change their colours, effectively. If you have a white font, this gives you a multicolour font.

Multiline, tinting and UTF-8
support added.

There are three ways to do it - you can set the tint for the whole string using a method, you can use modifiers to change it (e.g. the e in pulse) and you can put inline colour definitions.

e.g. Hello{blue}World ! This {1,0,0.5}is {} text"

The {} can be set to any pair of bracketing characters that are not alphanumeric or a decimal point.

Both the library and demo have been updated for the new improved library - though the demo is still unchanged.