Dependency Injection Component Based Game Framework.. Part 1

[Michael Cann]

Ello List,

Finally found a few hours to spare to knock out a first draft of the very basics of a DI based Game Component Framework.

So far I have developed the core classes:  Entity, EntityComponent, EntityMap and GameContext.

Starting with the GameContext. I have had to make a detor from RL here as, on suggestion from Shaun, I likely shouldnt include ViewMap nor MediatorMap for performance reasons.  I also require child injectors found in SwiftSuspenders 1.5+ (more on that below) and as the RL ContextBase is built for pre-child injectors I decided not to extend it for now, so I can get something working. So for now my GameContext is a simple class containing an EntityMap reference and a SignalMap reference, and uses the Injector class of SwiftSuspenders directly rather than IInjector of RL.

The method of using the context should be familiar however as it any entities or signals requiring mapping are decared in the startup call. Taken from my very simple example game (find attached):

 

public class MyGameContext extends GameContext

{                             

                // protecteds

                protected var _blueCircle : BlueCircle;

                protected var _scene : Scene;

               

                public function MyGameContext(sceneLayer:Sprite)

                {                                             

                                // Making the scene

                                _scene = new Scene();

                                sceneLayer.addChild(_scene);

                               

                                // Init the context

                                super();

                }

               

                override public function startup():void

                {                                                                                                             

                                // Map the scene for use by the entities and components

                                injector.mapValue(Scene, _scene);                       

                               

                                // Map some commands

                                signalCommandMap.mapSignalClass(SpawnRedCircleSignal, SpawnRedCircleCommand);

                               

                                // Now make a blue circle that follows the mouse about

                                _blueCircle = entityMap.instansiateEntity(BlueCircle) as BlueCircle;

                }

}

 

The EntityMap is very simple for now, and contains a single method:

 

public function instansiateEntity(entityClass:Class) : Entity

{

                var entity : Entity = new entityClass();

                entity.injector = _injector.createChildInjector();

                return entity;

}

 

The entity is to serve as the base of all entities in a game. Its primary function is to manage the components that the user adds via the "mapComponent" function. The entity also manages the injection into the components.

 

As an example, a typical entity could look like this:

 

package co.uk.mikecann.app.entities

{

                import co.uk.mikecann.app.components.CircleRendererComponent;

                import co.uk.mikecann.app.components.SpatialComponent;

                import co.uk.swft.base.Entity;

               

                public class RedCircle extends Entity

                {

                                // Components

                                public var spatial : SpatialComponent;

                                public var renderer : CircleRendererComponent;

                               

                                override protected function onMapComponents() : void

                                {

                                                // Map some components

                                                spatial = mapComponent(SpatialComponent) as SpatialComponent;

                                                renderer = mapComponent(CircleRendererComponent) as CircleRendererComponent;

                                               

                                                // Setup some params on the components

                                                renderer.colour = 0xff0000;

                                }

                }

}

 

Here the RedCircle Entity is made up of two components, a spatial and a renderer. On instantiation the Entity base calls the onMapComponents which adds it to the list of components. Once all components have been added, it then injects into them and calls "onInit" on the components:

 

public function set injector(value:Injector) : void

{

                // Set the injector and inject ourselfs first

                _injector =  value;

                _injector.injectInto(this);

               

                // Now tell sub-classes to map any components they are going to use

                _components = new Vector.<EntityComponent>();                                       

                onMapComponents(); 

               

                // Finally inject into those components and tell them to init

                injectIntoComponents();

                initComponents();          

}

 

When called it makes a child injector (thankyou Shaun for suggesting this) for use by the entity so that the GameComponent injections dont conflict. This way we have have components that are mapped by an entity child injector and so are only available for injection within the context of that entity:

 

public class CircleRendererComponent extends EntityComponent implements IUpdateable

{

                // Injecteds

                [Inject] public var scene : Scene;

                [Inject] public var spatial : SpatialComponent;

               

                ..

}

 

and

 

public class MouseFollowController extends EntityComponent implements IUpdateable

{

                // Injecteds

                [Inject] public var scene : Scene;

                [Inject] public var spatial : SpatialComponent;

               

                override public function onInit() : void

                {

                                // register us for updates

                                scene.registerForUpdates(this);

                }             

               

                public function update() : void

                {

                                // Follow the mouse scene position

                                spatial.position.x += (scene.mouseX-spatial.position.x)/6;

                                spatial.position.y += (scene.mouseY-spatial.position.y)/6;

                }

}

So there that is my start to this project. I realise its very basic at the moment and lacks many of the important parts of a framework and indeed good programming style such as Interfaces and Tests, but for now I wanted to bash this out, get a feel for it and see what you think!

I decided to email the list rather than blogging about it as it's still very early days (one evenings work) and im extremely keen to hear any ideas you guys have for changes and improvements!

Cheers,
Mike

P.S. Oh BTW I have called the project “Swft” for now, just because I had to give the project some name, and I had bought the www.swft.co.uk domain name some time ago and not done anything with it. I asked Till of Swift-Suspenders if he minds the similar name and he said he is cool with it.

--
Mike Cann
http://www.mikecann.co.uk/
http://www.artificialgames.co.uk/

[Shaun Smith]

Cool stuff. I'm away from my machine for a couple of days, but will dig in when I return.

Shaun Smith

http://twitter.com/darscan

http://shaun.boyblack.co.za

--
You received this message because you are subscribed to the Google
Groups "Robotlegs" group.
To post to this group, send email to robo...@googlegroups.com
To unsubscribe from this group, send email to
robotlegs+...@googlegroups.com
for support visit http://knowledge.robotlegs.org

<SwftExample1.zip>

<Swft-Lib.zip>

[Michael Cann]

Okay, I have had a little more time this evening so I thought I would take a look at Swft again.

As Shaun has just uploaded version 1.1 Beta of RL I thought I would take this opportunity to change my code so that my GameContext now extends Context as I now can use child injectors :) Im also using Darscan's LazyMediator to get around the potential performance issues in this game framework.

I have also started to play with Git a little more, coming from SVN its a little strange but TortoiseGit eased me in nice :) 

Swft Project: http://github.com/mikecann/Swft

Swft Examples: http://github.com/mikecann/Swft-Examples

As for actual work on it, I hope to do some now. 

I want to make the project as concise as possible, it would be a shame not to after the example RL has set ;)

In that vain im going to take a look at a part im unhappy, the component mapping in the entity: http://github.com/mikecann/Swft-Examples/blob/master/Red-Blue-Circles/src/co/uk/mikecann/app/entities/BlueCircle.as#L22-24

Im wondering, how hard would it be to add another meta-data tag as to remove that potentially unnecessary step:

public class BlueCircle extends Entity

{

	...



	// Components

	[Component] public var spatial : SpatialComponent;

	[Component] public var renderer : CircleRendererComponent;

	[Component] public var controller : MouseFollowController;




        ...

Im guessing it would be difficult and would probably require me to write a modified version of Swift-Suspenders?

Cheers,

Mike

[Jos Yule]

Without spending too much time looking into this, why can't you just use injection for these components?

someplace do a

injector.mapClass(SpatialComponent);

Then where-ever you have a

[Inject]
public var spatial : SpatialComponent

You will get it all done up nice.

Or am i missing something fundamental? Which is quite possible!

jos

[Michael Cann]

Remind me again, exactly what does mapClass do? Im struggling to find documentation on it.. 

[Jos Yule]

Anyplace an injection for that class is found, it creates (instantiates) a new instance for that injection point.

So, in my brief example below, you'd get a new instance of the SpatialComponent injected into your class/instance.

j

[Michael Cann]

Ahh I see. Well that would work but it would just be replacing what im currently using (mapValue) in my mapComponent function in Entity with mapClass instead:

http://github.com/mikecann/Swft/blob/master/src/co/uk/swft/base/Entity.as#L11-24

What im considering is, I suppose, mostly a convenience method by using [Component] meta the Entity automatically maps its components.

What im also concerned about is the performance.. 

Each one of my entities requires a child injector, this is so that the components can have other components automatically injected within the scope of the entity and not outside. However, does this mean that each time I make an instance of BlueCircle entity that SwiftSuspenders must call another describeType as, as far as that child injector is concerned there is no cached injection point description for that class type?

I guess this is one for Till then: Does the parent of a child injector cache the injection points of its child so that subsequent children can use the cache rather than describeType again?

If he's not about ill take a peek in the source tonight or tomorrow.

Mike

[Jos Yule]

Well, i don't want to speak for Till, but i'm pretty sure the Parent Injector _is not_ cacheing anything from the child. In fact, i don't think the Parent knows about the child at all - the relationship is in the other direction - the Child "knows" about the Parent, or, at least, inherits the parents cached injection points.

While, obviously, performance is a concern, especially with games, i'd hold off getting too caught up in that till you have something working, where you can point to the issue directly. Premature optimization, root of all evil, etc etc.

I need to spend some more time with your example and classes, but i'm swamped with work right now, so all i can do is spend a couple of minutes chatting via email! But i'm very interested in this project - i really like the idea of PBE (pushButtonEngine) but would like a lighter approach, which is what your lib seems to be working towards.

A non-mxml example would be great, as would one that isn't using Signals. Each of these items presents a barrier to potential users of the lib. If you don't mind, when i get a second (ahahahaha), i thought i'd convert the example over to something that can be compiled by the Flash IDE, using plain Events.

Keep on workin' it, interesting stuff!

jos

[Michael Cann]

Hi Jos,

Hahaha, ye I can totally relate, I probably shouldn't be writing this email right now, but I saw your mail and I couldnt resist ;) 

Yes I currently use PBE at work and find it lacking on many points, which is one of my main reasons for starting this project. 

Cheers for the hints on the examples in the IDE and using events, Ill be sure to do that. I will probably also drop the Vector.<> in Entity, which will remove the dependence on Flash 10 which should remove another barrier.

Hmmm thinking about it, is meta-data allowed in the IDE? Last time I checked it wasnt. Ill check this this weekend too.

Ill be sure to keep working on it.

Should I continue to update this thread? Do the RL guys mind me hijacking?

[Jos Yule]

(i'm going to assume its ok to keep going with the thread)

You are correct, the Flash IDE compiler strips the meta-data out of the code. However, you can use an XML file to init the injector. I've got an AIR application which reads the .as files, and generates the XML for you, so you don't have to do it by hand.

I'm happy to do the Flash IDE version, especially if you remove the Signals and Vector dependancies. I think i can swing enough time to do that. Next week, anyway!

Let me know.

jos

[Michael Cann]

Ooo that tool sounds pretty handy!

Righto, Ill make some changes this weekend and let you know how I get on!

Cheers,

Mike

[Shaun Smith]

(ps. no probs with keeping this thread rolling)

I think Till is currently away on business. But, as far as I know, child injectors are really cheap, so I would assume that the cache is shared (at least as far as describeType is concerned) and that there is minimal performance overhead.

I'm having a little trouble figuring out exactly how you want the engine to work - I've been through the source and example, and the diagrams, and, for a brief moment, it all made sense; And then it didn't. Can it be represented in ascii? :)

GameContext

GameContext::SpawnRedCircleSignal

GameContext::Scene

GameContext::BlueCircle (entity)

GameContext::SpawnRedCircleSignal

BlueCircle::SpatialComponent

BlueCircle::CircleRendererComponent

GameContext::Scene

BlueCircle::SpatialComponent

BlueCircle::MouseFollowController

GameContext::Scene

BlueCircle::SpatialComponent

GameContext::RedCircle (entity)

RedCircle::SpatialComponent

RedCircle::CircleRendererComponent

GameContext::Scene

RedCircle::SpatialComponent

Ok, I think it's starting to make sense again..

Question: Would an Entity ever need to be injected into an object in the GameContext scope, or into another Entity?

[Michael Cann]

Hi Shaun,

Cheers for putting the time in to try to wrap your head around this, very much appreciated :)

I can imagine situations where it would be advantageous to have entities injected into other places yes. One example is having a singleton "Player" entity that gets created then used elsewhere.

Why, can you see a problem?

 Mike

[Shaun Smith]

I think the component mapping/injection stuff can be much simpler:

public class BlueCircle extends Entity
{

// From GameContext
[Inject] public var spawnRedCircle : SpawnRedCircleSignal;

// Components
[Inject] public var spatial : SpatialComponent;
[Inject] public var renderer : IShapeRenderer;
[Inject] public var controller : MouseFollowController;

override public function mapComponents() : void
{
injector.mapSingleton(SpatialComponent);
injector.mapSingletonOf(IShapeRenderer, CircleRendererComponent);
injector.mapSingleton(MouseFollowController);
}

[PostConstruct]
public function init() : void
{
renderer.colour = 0x0000ff;
renderer.clicked.add( onClicked );
}

protected function onClicked() : void
{
spawnRedCircle.dispatch();
}
}


Notice that we now have more control over how the components are
mapped (see IShapeRenderer). Also, components themselves can declare
[PostConstruct] methods if they need to do any setup (instead of
calling onInit or similar).

The base Entity would also be much simpler (and should be defined as
an Interface):

public class Entity
{
protected var _injector : IInjector;

public function set injector(value:IInjector) : void
{
// don't do crazy work in your setters!
_injector = value;
}

public function get injector() : IInjector
{
return _injector;
}

public function mapComponents() : void
{
// Injector is ready, map injections here
}
}

Which would then make it the EntityMap's responsibility to properly
construct an Entity:

public class EntityMap
{
protected var _injector : IInjector;

public function EntityMap(injector:IInjector)
{
_injector = injector;
}

public function instantiateEntity(entityClass:Class) : IEntity
{
var entity : IEntity = new entityClass();
entity.injector = _injector.createChild();
entity.mapComponents();
entity.injector.injectInto(entity);
return entity;
}
}

Also, you could drop EntityComponent: [PostConstuct] is more inline
with DI, and there's no need to force any contract onto these
dependencies.

[Jos Yule]

Wow. That looks really simple. Which is no mean feat. Awesome.

Nice work Michael and Shaun!

It does mean that i'm going to have to update my RobotXML AIR app to support [postConstruct] meta-data. I've been putting that (and so much else) off. Next week!

jos

[Michael Cann]

Oh that looks alot better than my first attempt for sure Shaun! 

Im not sure if I mentioned it before but I was keen to use interfaces in the components so that any dependencies aren't locked down to a particular implementation. This would be particularly beneficial if you were to supply a "component pack".

This is an idea I have had brewing for a little while. I was thinking that this game framework should be as simple as possible and just provide the underlying structure, very much like what RL does. Then separately "component packs" could be supplied that provide the bulk of the code needed to make an actual game. So for example you could have an "Isometric Game Pack" that would include things like an IsometricSpatialComponent, IsometricTilemapRenderer, IsometricDepthSortingScene and so on. These packs are in effect mini-game engines in themselves but unlike the PBE engine it would be tailored to creating specific types of games. People could then be encouraged to share thier packs assisting others with game creation.

Well thats my little utopian dream anyways :) First tho ill take a good look at that code Shaun and have a go at implementing it and writing examples!

Cheers,

--
Mike Cann
http://www.mikecann.co.uk/
http://www.artificialgames.co.uk/

[Michael Cann]

Okay I have just spent an hour or so modifying the core to be in line with Shaun's suggestions:

http://github.com/mikecann/Swft-Examples/blob/master/Red-Blue-Circles/src/co/uk/mikecann/app/entities/BlueCircle.as#L22-24

One interesting thing to come out of this is that the "EntityComponent" class is no longer needed as the entities are initiated using meta-data:

http://github.com/mikecann/Swft-Examples/blob/master/Red-Blue-Circles/src/co/uk/mikecann/app/components/CircleRendererComponent.as#L24-36

I have made an interface for "IEntityComponent" but that currently has no methods or properties:

http://github.com/mikecann/Swft/blob/master/src/co/uk/swft/core/IEntityComponent.as

So I guess in theory its not really needed, and components dont need to implement IEntityComponent. 

There are a couple of consequences of this that need to be considered however.

One of the fundamentals of many component based game engines is the fact that components can dynamically be added / removed from entities at runtime. Now I have had this conversation before with Troy Gilbert (http://groups.google.com/group/robotlegs/browse_thread/thread/f7e325c5caf14d93/4800420c40bdc702?lnk=gst&q=idea#4800420c40bdc702) and he considers them very powerful for certain types of games.

He uses an example where an "Invincible" behaviour is attached to an entity dynamically at runtime to make it invincible. I agree this is a nice and powerful concept, reminds me abit of the new Reflex components. I think however that this functionality could quite easily be accommodated in a myriad of other ways and need not be implemented into the Entity as a core concept. Im keen on keeping entities and thier components strongly typed and hence want to keep away at all costs from the PBE-esq _blueCircle.lookupComponent("SpatialComponent").x = 20;

Another thing lost by dynamic composition is the ability to define entities purely in XML. PBE has a powerful deserialisation from XML method that encourages you to define all your entities and levels in XML thus making the game "Data Driven". So for example an entity may look like:

<template name="CafeFloor" template="SpatialEntity">

<component type="com.playdemic.gnb.components.commodity.CommodityComponent" name="Commodity" />

<component type="com.playdemic.gnb.components.commodity.StockItemComponent" name="StockItem" />

<component type="com.playdemic.gnb.components.controllers.cafe.CafeFloorController" name="EntityContainer">

<spatial componentName="Spatial" />

<renderer componentName="Renderer" />

<scene entityName="Scene"/>

<sellable>false</sellable>

<moveable>false</moveable>

<fertiliserSpriteSheet entityName="Cursors_Fertiliser_SpriteSheet" />

<handCursorSpriteSheet entityName="Cursors_Hand_SpriteSheet" />

</component>

<component name="Renderer">

<layerIndex>91</layerIndex>

</component>

</template>

This is taken from a game im currently working on at work. Although the concept of Data Driven games is powerful and the de serialisation itself is powerful it has many drawbacks that tend to make it unwieldy in practice. For one, any component used in the XML has to be compiled into the code so you end up with ridiculous long lists of TypeReferences:

Any refactoring becomes a nightmare as the XML isnt included in the IDE refactor.

I think that the data driven aspect can be kept and implemented as a separate "plugin" to the framework, but I dont think entities and their components should be defined in XML, just the properties used to initialize them. For example:

<Player>

<spatial>

<x>200</x>

<y>300</y>

</spatial>

<renderer>

<sprite swf="assets/player.swf" clip="player_idle" />

</renderer>

</Player>

So in that example no components are actually added to the "Player" entity rather just the properties are defined. So this could be serialized such as:

var deserializer : EntityDeserializer = new EntityDeserializer();

deserializer.mapEntity("Player",MyPlayerClass);

deserializer.deserialize("assets/definitions.xml");

If anyone else has any thoughts on dynamic component composition, whether its needed or not would love to hear.

Cheers,

Mike

[Michael Cann]

Okay I have just spent a few more hours writing a very basic example game called "Shooter":

http://github.com/mikecann/Swft-Examples/tree/master/Shooter/

For convenience I have uploaded the game to play here: http://www.swft.co.uk/examples/shooter/Shooter.html

Its very simple and doesnt include any scoring or collision detection but the purpose of writing it was to see how the framework would hold up under a slightly more complicated game scenario. Im glad I did it as several things arose out of it that need thought / tackling / discussion.

Display List

Most non-flash game engines render to a frame buffer each frame, redrawing everything in the desired order. Although this method of rendering is possible in Flash using the "Bitmapdata Blitting" approach many of the benefits of the display list in AS3 are lost such as having transformations (colour, alpha, scale etc) handled for you and mouse events automatically dispatched. Its quite alot of work to rewrite all that functionality and so for many simpler games just using the display list may be preferable.

The method I have used so far has been the one set by PBE. In that engine entities are composed of renderer components which extend "DisplayObjectRenderer" which contains a display object. That display object can be the sprite for the game character or a simple shape or whatever needs to be rendered. The component itself is responsible for adding its display object to the display list. Now this presents several problems that I have encountered having used PBE for a while. 

One problem is that its not clear how one handles children in such a structure. So for example suppose that in "Shooter" I wanted to have a "Shield" entity that is displayed above the player and protects them from damage. I suppose you could say that the shield could have a "Spatial" component which is locked to the same spatial position of the player so that when the player moves about the shield is always in the same place. However what happens if you want to scale the player, or rotate or apply filters etc? Now you have to not only copy the position of the player in the shield you have a whole load more properties to deal with.

This is definitely an issue and need some careful thought.

Entity Destruction

This issue came about when I realised that once bullets or enemies reach the edge of the screen they are going to need to be destroyed and there was no clear way of how to neatly do so. Some components perform actions in their init that needs to be torn down on entity destruction such as registering for updates on the scene or adding itself to the display list. In PBE this is accomplished by calling destroy() on the Entity which in turn loops through all its components and calls the "onRemoved" method on them. That way any references are removed and it is then free for garbage collection.

So far however the Entity class doesnt store a list of components, infact it isnt aware of the fact that its going to contain components atall. This means that it cant loop through its components on destruction and perform the necessary cleanup. For now I have manually called destroy on each component, for example: http://github.com/mikecann/Swft-Examples/blob/master/Shooter/src/co/uk/swft/shooter/entities/Bullet.as#L36-41

I think automatic component management is definitely a desirable thing, making the game engine easier to use and producing potentially less buggy games.

So there are a few solutions that come off the top of my head:

1. In mapComponents() of the entity have the developer call functions on the entity rather than the injector itself so rather than "injector.mapSingleton(SingleSpriteRenderer)" we have a method "mapComponentSingleton(SingleSpriteRenderer)" then in Entity we have:

protected function mapComponentSingleton(componentClass:Class) : void

{

var component : IEntityComponent = new componentClass();

injector.mapValue(componentClass, component);

_components.push(component);

}

That way the Entity then would contain a list of components it could iterate over on destruction.

2. Use meta-data to markup methods to call on entity destruction. So similar to [PostConstruct] indicates a method to call once injection has been performed [OnDestroy] could be used to highlight a method for destruction. I imagine this would require writing a modified version of Swift Suspenders that means the injector had another method something like "injector.destroy(instance:*)".

3. Use meta-data to markup components within an entity:

public class BlueCircle extends Entity

{

...

// Components

[Component] public var spatial : SpatialComponent;

[Component] public var renderer : CircleRendererComponent;

[Component] public var controller : MouseFollowController;

...

}

I have mentioned this before and it has the same problems that Shaun pointed out before, which is you cant do neat things like matching an interface to its implementation: "injector.mapSingletonOf(ISpatial2DComponent, Spatial2DComponent)". It also would require a modified version of Swift Suspenders I suspect.

MVCS & Games

I love RL and MVCS for building RIA, but im wondering how appropriate the concepts are to building a game? In MVC you are trying to keep a separation between your view and your data as to allow for cleaner, more modular, less dependant code. This is achieved by having sub-systems and intermediate objects and classes that pass the data around. In games however often on screen elements change on a per-frame basis and require a tight coupling between your view and your data. 

While building this simple game I found that I was asking myself things like "Who should be performing this bit of logic?". So for example, when the player presses the mouse button the bullets should fire. Now the question is how should this be implemented? 

1. Have a controller component in the Player Entity listen for mouse press then create a Bullet Entity via the injected EntityMap.

2. Have the controller dispatch a signal on mouse click that the Player entity listens for creates the Bullet via the injected EntityMap.

3. Have the controller dispatch an injected signal that invokes a command which creates the Bullet?

The method I have currently opted for is 2. My reasoning is that I think that the components should probably be kept as generic as possible and the business logic of what to do on a mouse press should be the responsibility of the Entity and not the component. A purist MVC approach may be to use number 3 so that the player is never aware of the Bullet class and instead just tells a command that it needs to fire a bullet. Now im not sure what the performance implications are of firing potentially tens of bullets and hence commands a second are so I suspect a compromise need be made.

MVCS would still be immensely helpful in other games however such as the one I am developing at work. Its a Farmville / Cafeworld like game and as such like many of those games its mostly an event-driven type game. So click here, this happens, then click here and that happens. There are a lot of GUI elements, HUD and menu systems and other things that are perfect for the View / Mediator / Command / Proxy methodology. So im certainly keen to keep the ability to use RL in the game, just you have to be careful when writing a game that you understand which elements are wise to use in certain situations.

Meta-Data & Inheritance

Inheritance is abit of a wierd concept in a component based game as the reason why you go to such lengths to abstract out your functionality into components is to get away from the problems associated with inheritance. But there are definite reasons why you still want to beable to have inheritance. In the case of the "Shooter" game for example I have two types of Enemy, a FastEnemy and a SlowEnemy now suppose that both of them needed to have a renderer and a spatial but they needed different controllers as they have different AI. 

In this case it may be nice to have an EnemyBase that contains spatial and renderer components. That way FastEnemy and SlowEnemy can extend it and get access to the common components. By having an init in the EnemyBase and decorating with [PostConstruct]:

[PostConstruct]

public function init() : void

{

}

I had expected that in my FastEnemy all I would have to do was override the init and do some cusom init like so:

override public function init() : void

{

super.init()

spatial.velocity.y = 0.3;

}

Unfortunately however it appears that by overriding a method you hide the meta-data below and so the function wouldnt be called unless I added another [PostConstruct].

Its not a big issue but its abit of a gotcha and could impede the learning process of someone new to the framework.

---

Right well this I think is the longest email I have ever written and im gonna wrap it up before it turns into a book. I dont expect any feedback I just find it useful to get my thoughts down on paper, by writing out a problem then the potential solutions tend to make themselves evident. If you guys do have any thoughts / suggestions I would ofcourse be more than happy to hear them!

Cheers,

Mike

[Jos Yule]

Just a quick note to say that i haven't had a chance to look at this yet, but i'm _going_ to look and respond when i get some time.

You bring up some good points, and i want to take some time to look at the code to get a better feel for what is going on.

j

[Shaun Smith]

Groovy. I agree that a method for cleanup is necessary, which means:

1. The EntityMap needs to keep a list of Entities

2. Each Entity needs to keep a list of EntityComponents

3. When an Entity is removed, that Entity's components should also be removed.

One problem with eagerly creating the EntityComponents is that you can't have EntityComponents that depend on each other (unless you map them in the correct order - which won't always be possible).

I've taken a quick stab at another approach for keeping track of components:

public class EntityComponent implements IEntityComponent

{

[Inject]

public var entity:IEntity;

[PostConstruct]

public function init():void

{

entity.registerComponent(this);

}

public function onRegister():void

{

// HOOK: override

}

public function onRemove():void

{

// HOOK: override

}

}

Each EntityComponent is injected with it's parent Entity. After injection, by way of PostConstruct, it registers itself with the Entity. When the Entity is removed it removes all registered EntityComponents.

I've updated the library (which includes quite a lot of changes):

http://github.com/darscan/Swft

http://github.com/darscan/Swft/commit/cb31027abe0a88b344a944299771df35487a434d

And the Shooter demo (didn't get round to updating the other demo):

http://github.com/darscan/Swft-Examples

Things to note:

I've added an IEntityMap interface, and updated all refs (dependencies) to point to it.

No more [PostConstruct] in derived Entity and EntityComponent classes - I agree that needing to add the metadata when overriding is un-intuitive and error-prone.

Entities are created and registered by the EntityMap directly, whereas EntityComponents register themselves with their parent Entity after injection. It's a bit quirky, but allows EntityComponents to have dependencies on other EntityComponents inside the same Entity.

Entities that override onRemove() need to call super.onRemove() to automatically remove all EntityComponents.

It ended up much more verbose than I'd hoped, but it was really just a test.

On 25 Apr 2010, at 4:54 PM, Michael Cann wrote:

Okay I have just spent a few more hours writing a very basic example game called "Shooter":

http://github.com/mikecann/Swft-Examples/tree/master/Shooter/
<ScreenHunter_01 Apr. 25 13.43.gif>

[Michael Cann]

Shaun thats excellent! Thanks for taking the time and effort to give this some more thought. The solution looks great and doesn't involve any messy Swift Suspenders jiggery pokery. I cant delve too deep into it atm, still at work, but ill take a better look at it in the next couple of days.

On another point Rick R asked me off-list if I was blogging about all this stuff or not, my reply was:

I should hope that the project never gets too complicated that I cant accept aid from anyone at any stage. One of the main reasons for me posting about this project is because some of the best programmers in our field read this list and I highly value their input even if it isnt strictly to do with the RL Framework. I am also extremely grateful for the contributions so far and am looking for more from anyone that wants to help out.

I have been thinking (mainly after writing my last post) too that I should keep an archive of these mails somewhere. I have the domain www.swft.co.uk and I have my personal blog: www.mikecann.co.uk so I think ill setup a subdomainblog.swft.co.uk and document the discussions of this list.

So ill try to setup a basic blog or something this weekend too.

Cheers,

Mike

[Jos Yule]

I'm in the midst of working on a game project right now, and i'm running into some issues when trying to figure out how to save/load or any kind of persistence wrt game state.

Some of this is my fault, i should have been thinking about this more fully from the start, but i wanted to raise it here as a question that might need to be thought about wrt a game framework/library.

I'm looking at using flash.utils.IExternalizable to write out byte arrays to a sharedObject on the local filesystem. The issues i'm having are near legion, but circular references are what are really kicking me in the posterior right now. While IExternalizable has some builtin goodness going for it, a more home-grown approach might solve the reference issues more easily. In which case i might use JSON as the format.

Arg.

Also, Arg.

I'm still trying to figure out where the serialization has to happen - its got to be in the classes themselves... Shit, now i've got to go get my GoF patterns book and figure out how to implement this... Arg.

jos

[Michael Cann]

Hi, 

Sorry I haven't gotten back in a while, even tho it has been a bank holiday here in the UK over the weekend I haven't had time to do any coding. I AM going to make time to look at this this week however.

Ye I have run into problems with generic serialisation / de-serialisation  methods in the past with things like the one you are describing at the moment. Things such as circular references can be managed with by having lookup table / trees but tbh I have always found it easier just to roll your own method in each (de)searilisable class, either exporting a byte array / json or some VO. 

With respect to the component based game framework. I suppose there are a couple of ways it could be tackled. 

1. Have a "PersistedEntityComponent" that you can add to any entity that you want to persist. That could then potentially be used in a manner such as this:

class MyEntity extends Entity

{

[Inject] public var spatial : SpatialComponent;

[Inject] public var renderer : RendererComponent;

[Inject] public var stateMachine : FSMComponent;

[Inject] public var persistor : PersistedEntityComponent;

override public function mapComponents():void

{

injector.mapSingleton(SpatialComponent);

injector.mapSingleton(RendererComponent);

injector.mapSingleton(FSMComponent);

}

override public function onRegister():void

{

persistor.mapForPersistance(spatial,"x");

persistor.mapForPersistance(spatial,"y");

persistor.mapForPersistance(stateMachine,"state");

}

}

2. Alternatively we could decorate certain properties with metadata. Tho im less sure on this one.

Anyways, thats just a couple of ideas.

Mike

--
Mike Cann
http://www.mikecann.co.uk/
http://www.artificialgames.co.uk/

[Michael Cann]

Ughh.. Git and I just dont get on with each other.. I wont bore you with the details, but the short of the long is I deleted the Swft-Examples repository and remade it. How are you supposed to merge the master with someone elses fork?

Anyways the master of Swft and Swft-Examples now reflect the (quite brilliant I must add) changes offered by Shaun.

I first thought that Shaun had made a boo-boo by the fact that Entity immediately calls onRegister in the EntityComponent once the component had registered: http://github.com/mikecann/Swft/blob/master/src/co/uk/swft/base/Entity.as#L37 resulting in the fact that a component may not have some if its dependencies registered in time. Then I realised that it doesnt matter and unless you were to implement some sort of priority based registering system you were always going to have an issue regarding the order of registration.

I have made a small change to IEntity and hence Entity. I have renamed the removeComponent to unregisterComponent, I think this correlates better with its counterpart method 'registerComponent'.

Having the ability to register and unregister components brings into focus the ability to dynamically add and remove components. Im going to give this some more thought over the next few days. I suspect some modifications will need to be made for it to work. Specifically to dynamically add a component to an entity it will need to be manually injected into using the injector of the entity.

I plan on expanding the shooter game a little too, adding scores and the like. Just to see what other issues come up. I may also take a look at that persistence issue Jos is having and see if there is a neat way to solve it.

Cheers,

Mike

[Shaun Smith]

On 04 May 2010, at 8:51 PM, Michael Cann wrote:

How are you supposed to merge the master with someone elses fork?

You add their repo as a remote and do a pull (does a fetch and a merge):

git remote add mike http://github.com/mikecann/Swift-Examples.git

git pull mike master

That's how I just pulled from your repo back into mine (though I got a warning that we don't share any common commits - due to the nuking!). There are better ways, but that usually does the trick. We'll also need to clean up that repo a bit (having project property files and binaries in a repo is a nuisance).

http://github.com/mikecann/Swft/blob/master/src/co/uk/swft/base/Entity.as#L37 resulting in the fact that a component may not have some if its dependencies registered in time

Dynamically added components won't be available yet at this point, correct, but the injected ones will.

I have made a small change to IEntity and hence Entity. I have renamed the removeComponent to unregisterComponent, I think this correlates better with its counterpart method 'registerComponent'.

It does, but.. it's at odds with everything else.. and RL (which I regret.. we should have called it unregister; remove is a throw back to PureMVC). It might be more straight forward to just keep it all consistent though.

Having the ability to register and unregister components brings into focus the ability to dynamically add and remove components. Im going to give this some more thought over the next few days. I suspect some modifications will need to be made for it to work. Specifically to dynamically add a component to an entity it will need to be manually injected into using the injector of the entity.

It could be as simple as:

public function addComponent(component:IEntityComponent):void

{

injector.injectInto(component);

registerComponent(component);

}

Or, more complex if we want the component to be available to subsequent dynamically added components.

I plan on expanding the shooter game a little too, adding scores and the like. Just to see what other issues come up. I may also take a look at that persistence issue Jos is having and see if there is a neat way to solve it.

I haven't made any proper Flash games before, so it would be cool if the Shooter game covered thing like:

Input mapping (possibly configurable keyboard and mouse input.. or something like Gamepad)

Collision detection

Game loop (or Scene Manager? Something that acts as master timing mechanism that can be paused/resumed etc)

And any other bits that might be useful for a typical (!) game. I probably need to start looking at projects like PushButton, Flixel, FlashPunk.. Do you have any good resources/pointers for getting up to speed quickly?

[Michael Cann]

Mmm, cheers for that tip on Git Shaun, unfortunately im a total novice with it and am more than happy for any advice offered ;) Yes I agree that we shouldn't have the project properties or binaries in the project but for some reason .gitignore seems to ignore all my hints that I dont want those files in my project. Ill attempt to coerce it a little more soon.

As for the renaming of the removeComponent to unregisterComponent; I agree that we should keep the naming convention the same thought especially if its to be based on RL it should match it similarly. Before I change it back however I want to investigate the dynamic addition / removal of components for as you suggest it may require the addition of another method "addComponent" and im wary of naming confusion.

On the dynamic component point, im wondering if it should indeed be a part of Entity or not as you point out there are potentially several levels of complexity. Perhaps it better to have a subclass of Entity called DynamicEntity or something that would allow for dynamic addition subtraction of components. This could keep the Entity class nice and simple for everyday use and then have the more complex version for those special instances.

Ill be sure to take a look at those game features you mentioned Shaun. Im also particularly interested in investigating a better way to handle the display list. Im also very interested to investigate whether its beneficial / wise to have a concept of hierarchical entities. I read PBE took a concious decision to shy away from this complexity, but im interested to know whether there are any strong benefits to it.

Unfortunately, im self-taught flash game developer through a process of trial and error over the years so I don't have any particular resources I found useful while learning. When asked in the past how to learn AS3 or games I have usually just told the other person to have a goal then google and hack your way to a solution. Not very scientific I know. 

I personally havent tried Flixel though I understand its very popular these days, it being one of the primary tool for flash-devs of the recent Ludlum Dare compo. Im not even sure if its component based or not, tho I suspect not, component based games are quite a radical concept if you are used to the usual game making methods. 

I have used PBE quite extensively obviously and is one of my main drivers behind this project. It was an eye opening experience developing games in a component like manner, and I really liked using it at first, but as the project progressed I soon started to encounter issues. I have mentioned them before so wont mention them again.

I believe Unity3D is also component based, I haven't gotten very far with that engine however as the windows version was in the very early stages of development when I gave it a look. I really should go back to that and see how they have done things. If anyone reading this has any experience I would love to hear it.

Other than "have an idea, then try to make it" I cant really offer much other advice unfortunately :S

In other news, im not sure if I mentioned this but I got a request off-list about this project and whether there was a blog for it so they could follow the development. Well I have had a quick stab at chucking one together here: http://blog.swft.co.uk/

I have done just two posts so far but im not sure about it. Firstly I havent asked people on this list if its okay if I quote them in a blog post, im sure its okay but its abit impolite. Secondly im not sure if its really interesting in its "today I someonene suggested this.. and then I did this.." format. Thirdly its alot of effort and im wondering if it best just to wait till its abit more presentable then write a few documents / examples to explain how the various parts work and the thinking behind them might be a better format (a-la-robotlegs). Anyone has any thoughts?

Mike

--
Mike Cann
http://www.mikecann.co.uk/
http://www.artificialgames.co.uk/

[Michael Cann]

Hi Chaps,

Had a little bit of time this weekend to do a little more work on the Shooter game. I decided just to develop it a little more to see what other issues may crop up.

If you actually play the game ( here: http://www.swft.co.uk/examples/shooter/Shooter.html ) you will notice that there isnt a whole lot visually changed. You can now destroy the enemies as they fly towards you and thats about it. Under the hood however I made quite a few changes and wrote quite abit of code.

I have now arranged the "proxy" code into managers. So each manager looks after a distinct part of game logic. For example the "EnemyManager" (http://github.com/mikecann/Swift-Examples/blob/master/Shooter/src/co/uk/swft/shooter/proxys/managers/EnemyManager.as) looks after the spawning and destruction of enemies. These managers could be as granular as we want so you could potentially have a single "GameManager" that handles everything.

I was thinking that perhaps we could automate some of this by putting in the ability to add and remove managers into the game context. The reason I say this is that it would be nice to encourage a game structure similar to the way MVCS encourages structure. I imagine having a "GameManager" and "IGameManager" and it will extend Actor. A game manager can override a few hooks such as onInit, onStartLevel, onLevelComplete. 

Im not 100% sure on this and am keen to hear your opinion. The framework definitely needs some way of managing various groups of entities, if you can think of a better way I would love to hear.

Cheers,

Mike

[Michael Cann]

Ughh.. Just walked away from the computer and came back and had a thought. I was assuming that signals are weak referenced, but I just looked at the signals source and it appears not. So when I am adding listeners such as..

http://github.com/mikecann/Swift-Examples/blob/master/Shooter/src/co/uk/swft/shooter/entities/bullets/Bullet.as#L41-42 

..and then not removing the listeners when the Bullet is removed I am probably causing a memory leak :( This is a shame as I liked the way I was using them.

Can anyone confirm?

Mike

[Shaun Smith]

(As we're deviating more and more from Robotlegs itself I think perhaps we should set up a separate mailing list.)

Cool stuff. I was thinking: we'll need an object pool - ideally, GC shouldn't run during gameplay, esp with this injection based architecture. I might take a stab at implementing that with the bullets or enemies. I think the GameManager idea is worth pursuing. Though is does bring up the issue of naming: GameContext, GameCommand, GameManager on one side, and Entity, EntityMap and EntityComponent on the other. I wonder if it wouldn't be better to prefix everything with Swft?

SwftContext, SwftCommand, SwftManager, SwftEntity, SwftEntityComponent, SwftEntityMap

Then again, that's what namespaces are for :/

[Shaun Smith]

Yeh, Signals need to be cleaned up after use.

[Joel Hooks]

I vote that you don't ;)

On May 10, 2010, at 5:31 PM, Shaun Smith wrote:

> (As we're deviating more and more from Robotlegs itself I think perhaps we should set up a separate mailing list.)

[Shaun Smith]

Ah, it's a poll!

Keep Swft Game Framework discussion on RL list: 2
Move Swft Game Framework discussion elsewhere: 0

(I'm fine with this discussion staying on the list, just thought that
other might be getting irritated.)

[Michael Cann]

Haha! Well im happy either way. Im just very grateful for interest and discussion so far :)

Shame about the Signals. I just did an unscientific test test. Held down the fire button on the game and the memory usage ramps up pretty quickly and doesn't come down so ye, im going to have to sort that out.

I cant comment too much right now on the naming Shaun as im just off to bed but it sounds like a good idea.

Mike

--
Mike Cann
http://www.mikecann.co.uk/
http://www.artificialgames.co.uk/

[Michael Cann]

Having slept on it im not sure about the prefixing of everything with Swft. Although it may make sense to prefix for SwftContext im not sure its really necessary for Entity or EntityComponent as Entity and EntityComponent are concepts / types that dont appear in the AS3 / Flex / RL libraries and so there shouldn't be confusion why what is meant by "Entity" unlike with Command, Manager or Context.

I have been thinking about your ObjectPool idea and I think it would work well being used in an "EntityManager" that looks after a collection of entities, simmilar to what im doing in the Shooter managers anyways. You could configure the manager to use pooling or not.

On a different note I am now starting to wonder if there should be a separate project for alot of this "GameEngine" logic rather just framework code. As each game will have different requirements, some may be 3D some isometric some multiplayer etc im wondering if all these premade components should be supplied with Swft or not. I would like to keep Swft Framework as concise as possible much in the same way RL is however without some starting components it is going to be a tough ride for a newbie.. Hmm im going to have to think on this..

Mike

[Michael Cann]

Hi Guys,

Had a few more hours this weekend to look at a couple of the points I have talked about.

Managers

I have now added a GameManager and a GameManagerMap. The idea is that you map managers in the GameContext which look after their respective parts of the game engine. For now I have made the Managers very simple, just providing some basic hooks to override:

http://github.com/mikecann/Swft/blob/master/src/co/uk/swft/base/GameManager.as

Once you have mapped some managers (http://github.com/mikecann/Swift-Examples/blob/master/Shooter/src/co/uk/swft/shooter/ShooterContext.as#L31-37) you can then call startup on the GameManagerMap which will in turn call startup on each Manager (http://github.com/mikecann/Swift-Examples/blob/master/Shooter/src/co/uk/swft/shooter/commands/GameStartupCommand.as#L42). I have added a priority sorting method as you may wish some managers (such as resources) to be initted before others.

Im not sure on this last point as it may better just to have another hook to override "onPreStartup" or something and have the managers wishing to init first init in there.

Also I was thinking of putting the responsibility of managing the game update loop into the GameManagerMap so that there is one clearly defined central place for game updates. It would also mean that managers wouldnt have to register with some place for updates (such as http://github.com/mikecann/Swift-Examples/blob/master/Shooter/src/co/uk/swft/shooter/proxys/managers/EnemyManager.as#L34) and instead would just override an "onUpdate".

Signals & Memory Leaks

I have also taken a little look at that memory leak issue. Holding down the fire button causes bullets to fire, memory usage to go up but it never goes down after the bullets have been removed. I assumed this was to do with the way I was using signals. I was adding listeners to component signals in the entities and I was adding listeners to entity signals in the managers and then not unlistening to them.

I tried removing the signals manually in onRemove in the entities and managers however I was still getting the leaks. Also I didnt like the extra code involved with managing the signals manually. So I have had a go at making some sort of automatic signal management. You "register" a signal in an Entity or EntityComponent so that when that object is destroyed it loops through all the registered signals and calls "removeAll()" theoretically removing all the listeners and hence freeing the object for GC. 

Now, im not particularly happy with this. Other than the fact that it doesnt seem to work and im still getting the memory leak there is a theoretical issue here. Should the object that listens to the Entity/Component be responsible for removing its listener when the Entity/Component is destroyed or should the Entity/Component be responsible for its own Signals and hence should remove any listeners that have been added?

I feel as if I am missing something obvious here. Why dont Signals reference weakly or have an option to reference weakly?

License

One final issue guys. I have been talking with my current employer about this project and I was saying how I would like to use it on our next project at work. I think this would give it some solid real-world testing and would improve it greatly. They were however nervous about me giving away company secrets to the community in case I empowered our competitors. After much discussion they agreed it is in the benefit of the company for me to keep working on this open source, there was one stipulation however. When released Swft will need to have a licence that will require companies of 3 or more employees to first seek permission from them.

I have been extremely hesitant to mention this as I have enjoyed discussing my ideas with you guys and have gained alot of insights. I just hope this can continue!

Cheers,

Mike

[Jos Yule]

>
> License
>
> One final issue guys. I have been talking with my current employer about this project and I was saying how I would like to use it on our next project at work. I think this would give it some solid real-world testing and would improve it greatly. They were however nervous about me giving away company secrets to the community in case I empowered our competitors. After much discussion they agreed it is in the benefit of the company for me to keep working on this open source, there was one stipulation however. When released Swft will need to have a licence that will require companies of 3 or more employees to first seek permission from them.
>
> I have been extremely hesitant to mention this as I have enjoyed discussing my ideas with you guys and have gained alot of insights. I just hope this can continue!

Licences are such a political and emotional issue.

I've written this message like 5 times, trying to come up with something that doesn't sound argumentative or overly "political" or whatever.

So, without any rancor, i would be unable to continue to offer what little input i have to the project, if it was given a licence like that.

Anyway, like i said, licences are such a political and emotional issue.

jos

ps. i don't want anyone to take offence at _my personal_ take on this, or to project anything out of _my personal_ take on this to your own personal take on this. I don't expect anyone else to think/feel/react the way i do, so please don't take this as some kind of angry reactionary posturing! I can get into the reasons for why i choose to react this way, if you are interested, but that is better off-list. Peace.

[Michael Cann]

ps. i don't want anyone to take offence at _my personal_ take on this, or to project anything out of _my personal_ take on this to your own personal take on this. I don't expect anyone else to think/feel/react the way i do, so please don't take this as some kind of angry reactionary posturing! I can get into the reasons for why i choose to react this way, if you are interested, but that is better off-list. Peace.

No offence taken. This is why my meetings at work about this got so heated. The last one went on for two hours and it was such a minefield of analogies and ambiguous arguments. I was fighting to keep it totally open source so that creative flow of ideas in unimpeded but they were obviously wary of empowering their competitors. The annoying thing is I can see their point of view so it is very difficult to play the moral-open-source high ground when they have a point.

In the end I agreed on a compromise which I hoped wouldn't restrict the project too much. By asking for permission from companies of three or more they are only attempting to restrict competitors leaving it open for use and contributions by individuals.

I can totally understand if you have reasons for not agreeing to a license such as this and if you wish to take it off list I can try again with them to see if I can argue your point.

Cheers,

Mike

--
Mike Cann
http://www.mikecann.co.uk/
http://www.artificialgames.co.uk/

[Neil Manuell]

have you guys seen this? http://bit.ly/bSyxep, just a really good animation regarding motive/incentives and open source pops in there too.

also this:

ps. i don't want anyone to take offence at _my personal_ take on this, or to project anything out of _my personal_ take on this to your own personal take on this. I don't expect anyone else to think/feel/react the way i do, so please don't take this as some kind of angry reactionary posturing! I can get into the reasons for why i choose to react this way, if you are interested, but that is better off-list. Peace.

is the best disclaimer ever, surely all emails/posts should come with this attached

[Stray]

Hi Mike,

so far my input has been fairly limited - just some discussions at the outset really, but I'm with Jos.

Open should be open in my mind. If your boss wants to contract me on an hourly rate etc etc blah blah... you know where that's going.

I'm very lucky to have a client who recognises the value of open source and allowed me to develop my secure module loading stuff in the open. They 'get' that the testing that happens in the community when you release something is beyond anything they could fund within the project.

Ditto what Jos said - it's just my personal take on it.

And the whole '3 people' think just sounds unworkable to me. You can slice the freelancer pie so many different ways: there's 5 folk on my current project, plus the project manager at the client - but I could just pay 2 of them direct and then they could pay the others. Or I could pretend that only 3 of us really use the code base. You get what I'm saying I'm sure.

Ah well!

(awesome video that one - saw it at the weekend, love it)

Stray 

[Michael Cann]

Whoop! I didnt realise my reply off Jos was off-list it was intended for the list. Copy/Paste:

Hi Guys,

Yes I totally understand the point of view mentioned by you and Stray and im going to fight for that again next week when I will have another meeting with my bosses. I had already proposed that I fork the project and only work on the work fork during office hours. They were concerned that any experience I gain during office hours would then be used to fuel the development of the OS version which would then empower competitors.I understood this as it was true.

I actually got rather angry at this point as they were in effect saying that any ideas I have in work belong to the company even if I hadn't acted on them in work. This is in fact apparently true and is written into my contract. This to me seemed incredibly draconian and reminiscent of the thought police. Again however I can see their point and they are paying me to do a job and should I happen to have an idea as a result of my paid-for experiences then technically they own that idea.

I have worked with them for several years and so I know that it sounds like they are being very harsh but they are just doing what is best for the company. They are generally very open to new ideas and methods however and im sure they would rather keep the project going and sacrifice some control rather than see it collapse.

If you have any more ammo to give me for when I meet with them again next week I would love to hear it as I want to keep this going and to keep contributing to it.

Cheers,

Mike

[Till Schneidereit]

Same as what Stray says: I haven't contributed to this thread before,
so feel free to entirely ignore what I'm about to write. (Update:
Reading your latest post, it seems like much of my post is besides the
point. I'll still post it as I think that not everything is besides
the point, though.)

Still with me? Okay, here goes:

Apart from all considerations about (legal/ practical) workability of
what you decided upon as it pertains whatever code you'll produce in
the future, I don't think you could impose these new restrictions on
the code that's out there right now. If that's not at all what your
company wants you to do, then you really should ignore this post. If,
however, they want you to put the code that's there now under a
proprietary license, then that might be difficult to do.

As you didn't specify any license at all, it's technically not even
allowed to be copied by anyone. I'm fairly certain that that's been
mooted by your conduct in not only distributing it via github, but,
more importantly, by discussing it on this list in the way you did and
by accepting code that Shaun wrote into your own repository.

As it is now, you've included code from Shaun into your repository and
(I'm guessing) built upon that code. That means that Shaun would have
to grant you the rights to the code he contributed. Or you'd have to
completely remove all code you didn't write and make sure that it
doesn't somehow live on in your code in some form.

A little more difficult are issues about how your code came to be.
IANAL and all that, but I guess that all of the fruitful discussions
here on the list might make it difficult to argue that the resulting
code is 100% your company's property. Also, it would definitely make
it pretty unfair, if you ask me.


I want to emphasize that I don't mean imply that you misrepresented
anything you did or whatever. It's just that putting the current code
under a restrictive license might be harder from a purely technical/
procedural point of view than your company expects it to.
The cleanest solution would certainly be to use a liberal license such
as MIT or new BSD for the current code (or to just put it into the
public domain) and then use a proprietary license for everything
you're doing from this point on.


Another point altogether is that I _really_ think your company is
wrong about this. Releasing code costs time, compared to just keeping
what you have in-house. Thus, you'll want to gain something from the
effort you put into releasing Swft in source code form. The scheme you
agreed upon is, IMHO, almost guaranteed to prohibit pretty much all
there is to gain by such a release. I can speak from good (and bad)
experience when I say that releasing libraries as open source has huge
advantages. SwiftSuspenders wouldn't be nearly where it is now had I
not gained a lot through feedback, bug reports, bug fixes, motivation,
etc. Compared to whatever real or perceived competitive advantage I
might have lost through sharing it, all of that together wins every
time!


cheers,
till

[Stray]

Meh. I never make my employees sign 'I own your every waking thought' contracts. They are the norm, but that's not to say they're acceptable - or even make any sense.

The counter-argument is that although the community benefits from your ideas and energy, because you are but one and we are many, your benefit (and theirs as a result) far outweighs the output.

The vast majority of work output is discretionary energy. They can't contract you to have x ideas per day, of 87% quality. The best stuff we give is beyond contract.

But, you'll never win. No point arguing because people either 'get it' or they don't! Might be worth showing them that video though :)

Stray

[Neil Manuell]

my two pence:

1) can't you open source it with you and your companies name on it.  this is free ADVERTISING for them. If it then becomes really popular, and can actually be said to be helping competitors, Their name will be stamped across it and the internet, and clients will come to them first as the creators of the framework.

2) what if you have the beginnings of a great idea at work, then go home, do a bit of geeky browsing on the net, then later in the bath have a eureka moment when two things come together. Or what if you have a great idea (in the bath), then a year later bring it to a project at work? My good ideas NEVER come at work. They always come in my own time (not always in the bath)... they are are only implemented at work.  

[Shaun Smith]

I don't think your employers should be worrying about the Swft framework itself - it's just an abstract component wiring mechanism.

Their concern is perhaps more valid when it comes to the specific components that are used to build games - this is the realm where trade secrets, competitive advantages etc lurk.

Perhaps a workable solution is to keep Swft itself completely Open Source, provide a number of Open Source components, and then apply more specific licences to components (or component sets) that really do provide some kind of competitive advantage.

Just a thought.

On 16 May 2010, at 3:37 PM, Michael Cann wrote:

License

One final issue guys. I have been talking with my current employer about this project and I was saying how I would like to use it on our next project at work. I think this would give it some solid real-world testing and would improve it greatly. They were however nervous about me giving away company secrets to the community in case I empowered our competitors. After much discussion they agreed it is in the benefit of the company for me to keep working on this open source, there was one stipulation however. When released Swft will need to have a licence that will require companies of 3 or more employees to first seek permission from them.

[Michael Cann]

15. DESIGNS AND INVENTIONS

15.1 All designs, inventions, programs, discoveries or improvements conceived or made by you during the course of or arising out of your employment with the Company (whether alone or together with any other person or persons) and which concern or are applicable to products or articles manufactured or sold by or to services provided by the Company ("Designs and Inventions") shall be the exclusive property of the Company.

Unfortunately Neil they do own any idea I have in the bath if it pertains to products manufactured by the company (which in this case it does). This is a common practice in software unfortunately.

But this is beside the point. As I said they are very open and understanding and im sure we can come to some sort of agreement.

Till, thanks for sharing your points. 

To be fair this is the first open-source project I have had any involvement with and as such it is all a learning process for me. So I apologise if I have done anything wrong in my process. As I have mentioned before, I just had an idea and was just interested to know if it would be possible to implement. I didnt know exactly who to ask, but I had just discovered RL and SwiftSuspenders and the wonderful world of IoC so I thought I would ask those I consider the experts in the field, you guys :P And I am extremely happy with all the discussion so far. If Swft could be 10% of RL/SS I would be over the moon!

Cheers,

Mike

[Till Schneidereit]

I _really_ didn't mean to imply that you did anything wrong! :)
Releasing software isn't easy - and releasing libraries or frameworks
is much harder; from a technical as well as a business point of view.

I think Shaun's proposal is a good one: Leave the core as-is and
realize your competitive advantage through components. As long as
Richard Stallman isn't lurking, I don't think there are any free
software fundamentalists around ;)


cheers and good luck with your bosses,
till

--
Till Schneidereit
Schneidereit Link GbR
technical concept, consulting, development
Tel: +49 40 970 7848 1
http://www.tillschneidereit.de/

[Joel Hooks]

If you need a gig that will empower you and do what you like with your free time, let me know. I'll put you in touch with some people. ;)

Joel Hooks (@jhooks)

http://joelhooks.com

[Joel Hooks]

This approach is *extremely* practical and would be twofold advatage
for the suits from a business perspective. The get to secure their ip
via the components, but get a hoard of nerds that want to help/use the
framework. Look at what pushbutton has done. The have some free
components sell some and I am sure there are lots of proprietary ones.
In addition to the 'free work' win, they get a huge pr boon by
supporting OSS that can attract mor deva and potentially create a
modest profit with component sales.

Joel Hooks (@jhooks)
http://joelhooks.com

On May 17, 2010, at 12:47 PM, Till Schneidereit

[Michael Cann]

Ha! 

That is a very interesting offer Joel, I am however committed to this company for the foreseeable future, tho good to know there are alternatives ;)

I like the sound of that suggestion Shaun, which kind of falls in line with what I was thinking anyway. Keep the core Swft "Framework" separate from the various "Engines" that builds upon it. So long as the framework is lightweight enough I should think they would be okay with that.

I suspect there are two points of contention here however: Where do you draw the line with with what is framework and what is engine? And whether I can work on the engine bits in my free time or not.

I suspect the former point will be okay to sort out, but the latter would be more difficult and I guess is down to the decision of my employer (and perhaps my persuasive skill).

Anyways, ill let you guys know how it goes next week.

Mike

[Joel Hooks]

Like RL you build engine bits, components, as externals (think RL utilities). Those could range from 100% opent to 100% proprietary and all shades in between. Really basic bits can be free and open. Crazy innovative IP bits can be whatever. Seems like a very viable model for all concerned.  

Joel Hooks (@jhooks)

http://joelhooks.com

[Nikos]

one of the things about game programming im trying to figure out is do
I do it in the new spark framework or do it in pure flash?

[Michael Cann]

Depends on the type of game you are making really. 

If you are going to need alot of RIA functionality such as lots of in-game menus and interface controls and things like that then it may save you time to include the Spark framework. You have to be aware of some of the performance implications of using flex however!

On our current project, we are making a Facebook game (think farmville) which has many interface elements and menus and things like that so we took the decision to use Spark for the (intended) time it would save us. In effect there are two halves to the game. One is the interface sparky bits and the other is the game engine and logic side. The sparky bits lends itself nicely to RL as it is in effect just a RIA, the game engine bits however dont fall into a neat MVC structure, which is what this projects Swft is intended to do, create abit more of a structure for the game bit.

Hope this helps!

Mike

On 26 May 2010 11:47, Nikos <nkats...@googlemail.com> wrote:

one of the things about game programming im trying to figure out is do
I do it in the new spark framework or do it in pure flash?

--

You received this message because you are subscribed to the Google
Groups "Robotlegs" group.
To post to this group, send email to robo...@googlegroups.com
To unsubscribe from this group, send email to
robotlegs+...@googlegroups.com
for support visit http://knowledge.robotlegs.org

[Michael Cann]

Hi Guys,

Just incase anyone was wondering. From our last discussion I said I was going to go back and meet with my bosses this week to try to sort out this license issue. Unfortunately one of the bosses is away this week so its going to be Tuesday before we can meet. 

Im keen to get cracking on working on this again. I have had many more ideas about things, just want to make sure everything is kosher before starting again.

Cheers,

Mike 

[Michael Cann]

Ello All,

Good news! I have met with my bosses again today and after a couple of lengthy meetings we have finally reached a conclusion on the license issue. 

They have agreed to keep it all open source with no license restrictions atall! 

This is obviously great news. 

There is one caveat for me personally that before I release anything major I have to consult with them first to be sure that im not giving away anything too proprietary. I can live with that no problems.

So hopefully I haven't pissed you guys off too much with all this, we can continue the ideas and discussions ;)

Mike

[Jos Yule]

Wow, that's great!

Thanks for taking the time with you company to really push for this - Congrats again.

j

ps. Shaun's idea of keeping Components "internal" and closed is still a good one, i think. There is always going to be "goodies" which you develop which are really for internal use only. Having the framework and whatever other components the community works on together open is going to be a huge win as it is.

[Shaun Smith]

hey that's great news!

[Michael Cann]

:) Cheers guys. 

Im not exactly the most eloquent of people so I didnt find it particularly easy but I think it was worth fighting for!

Ill be starting a new post soon. I think this one is getting abit too beasty :P

Mike

[Ben Garney]

Hey all!

I saw this thread and wanted to jump in. I'm Ben Garney, the author of
PushButton Engine. It's awesome to see it being used in this venue.
Mike, great work!

It's especially timely as this very week I am researching Robot Legs
as a way to build UIs for some of the games we work on. :)

I'd love to find a way to bring some of these concepts into the core
PBE codebase. PBE will never be one-size-fits-all but I think there's
a lot of value in trying to support the common cases and maintaining
common code!

Again - awesome discussion, it's great to see people remixing ideas to
find the best fit.

Ben Garney
Lead Programmer
PushButton Engine
www.pushbuttonengine.com

On Jun 1, 11:22 am, Michael Cann <mike.c...@gmail.com> wrote:
> :) Cheers guys.
>
> Im not exactly the most eloquent of people so I didnt find it particularly
> easy but I think it was worth fighting for!
>
> Ill be starting a new post soon. I think this one is getting abit too beasty
> :P
>
> Mike
>

> On 1 June 2010 19:00, Shaun Smith <dars...@gmail.com> wrote:
>
>
>
> > hey that's great news!
>
> > On 01 Jun 2010, at 7:44 PM, Michael Cann wrote:
>
> > Ello All,
>
> > Good news! I have met with my bosses again today and after a couple of
> > lengthy meetings we have finally reached a conclusion on the license issue.
>
> > They have agreed to keep it all open source with no license restrictions
> > atall!
>
> > This is obviously great news.
>
> > There is one caveat for me personally that before I release anything major
> > I have to consult with them first to be sure that im not giving away
> > anything too proprietary. I can live with that no problems.
>
> > So hopefully I haven't pissed you guys off too much with all this, we can
> > continue the ideas and discussions ;)
>
> > Mike
>

> > On 27 May 2010 13:05, Michael Cann <mike.c...@gmail.com> wrote:
>
> >> Hi Guys,
>
> >> Just incase anyone was wondering. From our last discussion I said I was
> >> going to go back and meet with my bosses this week to try to sort out
> >> this license issue. Unfortunately one of the bosses is away this week so its
> >> going to be Tuesday before we can meet.
>
> >> Im keen to get cracking on working on this again. I have had many more
> >> ideas about things, just want to make sure everything is kosher before
> >> starting again.
>
> >> Cheers,
> >> Mike
>

> >> On 26 May 2010 11:57, Michael Cann <mike.c...@gmail.com> wrote:
>
> >>> Depends on the type of game you are making really.
>
> >>> If you are going to need alot of RIA functionality such as lots of
> >>> in-game menus and interface controls and things like that then it may save
> >>> you time to include the Spark framework. You have to be aware of some of the
> >>> performance implications of using flex however!
>
> >>> On our current project, we are making a Facebook game (think farmville)
> >>> which has many interface elements and menus and things like that so we took
> >>> the decision to use Spark for the (intended) time it would save us. In
> >>> effect there are two halves to the game. One is the interface sparky bits
> >>> and the other is the game engine and logic side. The sparky bits lends
> >>> itself nicely to RL as it is in effect just a RIA, the game engine bits
> >>> however dont fall into a neat MVC structure, which is what this projects
> >>> Swft is intended to do, create abit more of a structure for the game bit.
>
> >>> Hope this helps!
>
> >>> Mike
>

> >>> On 26 May 2010 11:47, Nikos <nkatsika...@googlemail.com> wrote:
>
> >>>> one of the things about game programming im trying to figure out is do
> >>>> I do it in the new spark framework or do it in pure flash?
>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups "Robotlegs" group.
> >>>> To post to this group, send email to robo...@googlegroups.com
> >>>> To unsubscribe from this group, send email to

> >>>> robotlegs+...@googlegroups.com<robotlegs%2Bunsu...@googlegroups.com>
> >>>> for support visithttp://knowledge.robotlegs.org

>
> >>> --
> >>> Mike Cann
> >>>http://www.mikecann.co.uk/
> >>>http://www.artificialgames.co.uk/
>
> >> --
> >> Mike Cann
> >>http://www.mikecann.co.uk/
> >>http://www.artificialgames.co.uk/
>
> > --
> > Mike Cann
> >http://www.mikecann.co.uk/
> >http://www.artificialgames.co.uk/
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Robotlegs" group.
> > To post to this group, send email to robo...@googlegroups.com
> > To unsubscribe from this group, send email to
> > robotlegs+...@googlegroups.com

> > for support visithttp://knowledge.robotlegs.org

>
> >  --
> > You received this message because you are subscribed to the Google
> > Groups "Robotlegs" group.
> > To post to this group, send email to robo...@googlegroups.com
> > To unsubscribe from this group, send email to

> > robotlegs+...@googlegroups.com<robotlegs%2Bunsu...@googlegroups.com>
> > for support visithttp://knowledge.robotlegs.org
>
> --
> Mike Cannhttp://www.mikecann.co.uk/http://www.artificialgames.co.uk/

[Michael Cann]

Hi Ben!

Great to hear from you! I have spoken to you a few times on the PBE forums several months back but you probably dont remember ;)

Glad to hear you are still forging ahead with your games, hows Gruntz going?

Im glad you approve of the idea, I have much respect for PBE in much the same way I have respect for RL for opening my eyes to a new way of doing things. 

I have been thinking over the little 2.5 week hiatus about how this project could take shape with regards to the existing game engines out there (Joel made a suggestion that got me thinking). Ill talk more about this in a separate post soon.

Looking forward to hearing your thoughts and suggestions,

Mike

for support visit http://knowledge.robotlegs.org

[Ben Garney]

Hey Michael,

Oh cool, re: forums. :) You're right, with some 5000 posts I don't recall every user. Glad to know you're in the community.

Grunts is good, but more recently, we helped Playdom ship Social City (facebook.com/socialcity) which has been doing well - top 20 facebook game. Doing all the UI work in that game really opened my eyes to why something like RL is awesome.

I'll contact you offlist. I'd love to pick your brain a little bit.

-- Ben Garney