@Empire Phoenix said:
Anyway back to the topic, what might help you is something like annovention, that allows you to search for tagged classes, and register them properly.
(Spring framework can do the same and more, but I find it overkill for games)
That way you can do some more flexibility.
That is something I hadn’t considered. I use Spring a lot on other non-game projects and I was thinking about implementing a game server using it. I suppose it could be used on the client as long as all of its automagic doesn’t get in the way. For that reason, something like annovention sounds very interesting…
Groovy integration isn't really that hard... which may be why examples are lacking, I don't know.
I mean, literally the code is as simple as (presuming groovy-all.jar is in your project dependencies):
ScriptEngineManager factory = new ScriptEngineManager();
ScriptEngine engine = factory.getEngineByName(“groovy”);
Bindings bindings = engine.createBindings();
bindings.put( “myObject”, someObject );
Where ‘bindings’ is where you put the stuff you want to expose to the script. eval() can be passed a Reader or a String or whatever.
That’s all part of standard Java:
Groovy is nice because it has some built in boiler-plate for passing parameters as maps and stuff. So even if you didn’t want to implement a full builder pattern, in groovy you could do something like:
myFactory = new DudeFactory(name:“John”, hitPoints:123, etc…)
That would automatically call setName, setHitPoints, etc. during object instantiation.
I guess I never really looked at it using common sense. That might be a good way to go, but I’m not sure what it would really buy me over Java itself. Maybe unit properties defined in XML would be something better… as long as we are dealing with a fixed set of behaviors (controls).
i create a Factory/Manager App State for each type of piece in my game. (actors app state, scenery app state, decals app state. etc);
the app state handls all the stuff like pause/unpause, starting/ending the simulation, screen resizing, global quality settings, etc etc for the spatials it controls. If your game uses a seperate model outside of the scene graph, youd use this app state to read the model and do the appropriate spawning/despawning of spatials and moving them around and stuff like that.
just one way to do it.
I am doing that for certain classes of entities so far, however as the list of core “units” in an RTS game grows, all of those app states could become expensive.
On another note, I fully agree with and embrace the composite “entity” model where behaviors and data converge into the entity. While this departs from standard OOP inheritance, I foresee my concrete “builder” mechanism would probably follow inheritance in at least some way (see example above).
I really appreciate the feedback, you all have given me a lot to consider! =D