Yuk to Spring 
Check this out: gidrahs.xml
(with accompanying include tags.xml)
The guts of it all works with just 4 classes! If I had access to @annotations I’d have an even easier time of it too.
Cas
interfaces are about communication between objects, inheritance had something to do about Liskov substitution principle to be right. Are you sure your objects are capturing the stuff you want to capture? Differently put: are you modeling from the right perspective?
[quote]Yuk to Spring
[/quote]
I wanna fiddle with ROO
I assume this is meant for princec?
Dependencies/communication between components is utilizing separated interfaces pattern, as they are dependencies between packages. This is all very standard.
I don’t know about those gidrahs.xml and tags.xml, they seem to be very implementation specific. It will be a nightmare to refactor your code.
Actually I’ve been using a fork of Cas’ resource code for ages now, and IMHO it’s pretty good - copious use of reflection makes it trivial to write a data-driven game with minimal boilerplate code.
Were I to write it these days I might be tempted to use something like XStream, as my uneducated view of Spring is that it’s a bit heavyweight for my liking.
I was thinking about using XStream. But I guess somewhere on that road I drifted towards Spring. I guess I didn’t want to create my own schema.
Orangy - you should look at the latest stuff I’ve got in SPGL - it’s even more super simple and flexible than it was before, XML wise! And the sprite engine has gone from strength to strength with labels and subroutines and floating point coords etc. Soon I’ll put timebased animation into it (rather than tickbased).
Cas
Actually I keep meaning to rewrite the resource stuff because it’s not quite keeping up with what I want to do with it (in particular background loading/streaming and reloading automatically when files are changed). I’d be interested to hear what other people use/want in terms of resource and metadata loading.
not really… not specifically.
[quote]Dependencies/communication between components is utilizing separated interfaces pattern, as they are dependencies between packages. This is all very standard.
[/quote]
I’m pointing at something much more basic than that, to use a anything you need to know how to interact with it. If your not interacting with it it might as well not exist.
one level of abstraction fits all?
HeavyTank do we need another class for that? isn’t that just a tank that looks a bit different has a little more armor, weighs a little more. Perhaps Tank should be able to capture those difference. A Tank isn’t that a armored vehicle with tracks and a cannon mounted on it? Does a tank interact with the terrain or is it the tracks that interact with the terrain? Or does a Tank interact indirectly interacts with the terrain through it’s tracks… Sure if your game only contains tanks it’s over-designing if your wondering about that. The more sophisticated your world is the more sophisticated your model should be. Why do we seem to favor one-way-of-modeling-your-stuff-fits-all approach here?
sure other roads lead to Rome too, but they have their own bumps.
I’ve been meaning to add that feature too. We should probably have a chat about it.
Cas
First: definitely read Mick’s and my articles (and Scott Bilas’s stuff too).
But after that, off the top of my head, here’s an idiot’s guide to the value of ES:
-
The typical, most basic, simplistic of all game designs is a 3-way difference of options; RPS is a specific form of this (R > P > S > … R), but there are a few classic other ones, such as (A approx.equal to B; A > B; A > C; … but if everyone else goes A or B, then C >> A + B - for instance Microsoft Hearts). OOP is completely incapable of representing either of these forms of game logic, and they are two of the most common forms of game logic we see every day in games everywhere. This is because OOP fundamentally requires that everything fits in a DAG - and DAG == very-boring-gameplay
-
ES allows - positively encourages! - limitless recombinations of game-logic to achieve anything you could possibly think of, with minimal re-typing by a designer, and even less custom programmer code per new combination
-
ES fundamentally works on limitless datasets: it’s very easy to build caches for, it’s very easy to write hyper-efficient memory managers, it’s very easy to write distributed executation algorithms (using divide-and-conquer), and it’s very easy to write approximation algorithms. This makes life a LOT easier when you have large numbers of MOBS (e.g. in an RTS, or in any MOB-heavy game where MOBS have non-trivial - or a wide vareity of possible - behaviours. Obviously it works extremely well in any MMO, too)
-
When you have an existing codebase, and want to add a new type of enemy, or even a new small game-feature that will affect many - but not all - game entities (perhaps add a feature “reload time” that affects 75% of the existing weapons), this is trivial to add with any ES, but the more OOP your codebase, the harder it is to add (unless you get very lucky and find that the 75% has a 100% correlation with the subclases of a particualr class; in real-world game design that never happens because it would be an extremely dull change to the gameplay
-
very fast, easy to debug, network code is very easy to write for ES (because all data fits a very small set of known templates; this is just a corollary of the other data/distributed-processing/caching benefits)
-
very powerful debugging and gameplay-testing tools are much easier to write (ES work very well even when you “take away” entire subsystems: so, for instance, you can disengage your render layer trivially - but you can equally disengage any other layer, and mock it - suddenly automated testing becmes very easy, and it’s quite easy to write compile-time behaviour checkers that will tell you in advance the “side effects” of altering behaviour X, or component-onwership Y)
-
anything to do with data serialization and replay is much easier to write - very powerful for debugging and for reproducing bugs seen in the wild
…and a bunch of others. But that’s just from the top of my head, as noted.
First paragraph throws a TooManyAcronymsException ?
Anyway, it’s just a big task to write a game that actually benefits from ES.
It’s is a power tool, and most of us are used to hitting nails with hammers.
The end result might be structurally flawed, but we deal with it just fine.
That said, I’m very interested in giving it a whirl, although I don’t really like the EntitySystem, as your EntityComponents simply become flags, and your set of EntitySystems is basically structured like a relational database. I know that’s the whole point, but it doesn’t feel intuitive. For some reason I’m too used too OOP, and it’s not easy to let go. Programming everything in the EntityComponents feels much more natural to me - and if you can keep your dataset in RAM, you can easily get away with the ‘hybrid’.
I already read Mick’s paper and it helped me to see some benefit ES can have, I did not know about Scott Bilas’s but found this one wich seems to be pretty well explained ( it also provide some code snipets for a better understanding ) http://gbgames.com/blog/2006/03/object-oriented-game-design/ , so thanks to have pointed me its work as it is very nice, I did not read yours yet, but be sure I will. I already read most of the benefit you pointed out in others papers before my last post, it is just that I have trouble to have a “very clear vision”, anyways thanks for those precisions.
NB.: my question may be more revelant this way, if it is so much fantastic (and I beleave it can be…) “when we must not use such component based architecture ?” and why it is not used often ?
EDIT :
an excellent paper too : http://www.devmaster.net/articles/oo-game-design/
EDIT 2 :
[quote]The typical, most basic, simplistic of all game designs is a 3-way difference of options; RPS is a specific form of this (R > P > S > … R),
[/quote]
R < P < S < R 
so, that’s may be the big advantage : dealing with cyclic graph game design (or aribtrary one) ?
Spring is a very useful tool for large application. But for use as in a game, I would think a smaller API to pre-build game objects would work better.
I’m currently working on a similar project. I have a tool that builds an XML that would then be use for basic game object setup, allowing me to focus more on game design.
YES - if you have stateful programming, you do not have a functional programming language. That’s a simple law - by definition you mustn’t break it (or, if you’re going to break it, you have to be very careful to viciously limit the kinds of state and the ways in which state can be retained - most practically useful real-world fn-programming happens in languages that have “a little bit of state, but stored in a functional way”; in fact, IIRC, they all simulate “state” only by using true fn primitives - so, in all honesty, it’s not really brekaing the cardinal “no state” rule).
Allowing state is like saying that “all private members in an OOP langauge are constantly exported and accessible to all code - in all domains - at runtime”. Fine. But you just made it impossible to enforce several tenets of OOP (data hiding, abstraction, etc). That’s no longer an OOP language - although you’d still be capable of writing OOP code, other people could piss all over it :).
Ok, at least I understand your claim, then, even if I disagree with your definition of “functional programming language,” which seems a bit restrictive for my taste :). A hard-line approach would have to consider even Lisp a non-functional language because it contains direct mechanisms for dealing with state. Merely having the ability to do it doesn’t mean most people do, and since probably 95% of the Lisp code in existence is purely functional, I have a hard time saying it’s anything but a (impure, perhaps) fn language.
I’d say a closer analogy would be to say that an language is not OO unless it explicitly disallows public members, right? Otherwise anyone can still piss all over your code and use your library in an imperative way - who amongst us hasn’t seen this done (and likely done it ourselves!) once or twice?
In any case, we both certainly agree that functional programming is entirely about immutability and state-free programming, which is really the issue; we simply differ as to what we consider a functional language; I see it as something that allows functional programming, you see it as something that enforces it. I’m happy to chalk it up to a difference of definition - the wars over this at Hacker News wage on to this day, so there’s clearly no “right” answer.
[quote]Normally if you have an abstract class called Human, you might derive Man and Woman classes from it.
[/quote]
errr?
[quote]you can say human->activateAction( CATCH_CRIMINAL ). If it isn’t a PoliceOfficer, then it won’t have that Action. Nothing happens, just as we would expect.
[/quote]
Vigilante extends Human :
Anyways am I missing all this non-OO-ness what everyone is talking about, all I see is OO with a dash of persistent attempts at throwing static typing out the window.
You have completely missed the point, then, and I strongly advise you “don’t bother, forget you ever heard about this, and enjoy OOP. One day, when you find you’ve suddenly understood the meaning of ‘OOP-hell’, come back and have another go - you might find you like it”
If you read through my early articles, you’ll see that I explicitly mention (several times, I think) how hard a lot of OOP coders find it to “stick” at ES - they keep “accidentally” going back to OOP paradigms; this is not easy if you’ve heavily internalized the OOP way of thinking. Most of my difficulty / time / work spent on ES in the field was in getting OOP programmers to stop (trying to) writing OOP code in the ES - including myself! It was really tough to break the habits of a lifetime.
But totally worth it :).
Yes - OOP sucks donkey when it comes to game-logic design + impl.
OOP: I AM THE LAW!!! You WILL obey your parents! Your parents WILL obey your grandparents! TO INFINITY!!!
ES: I have his legs, her arms, their eyes, your left ear, your brother’s right ear, and I have the wings of a bat. Since I contain no new functionality, it took literally zero source code to implement me. Oh, and by the way - I have a sister, and she’s got the exact complement of everything I have. She also is zero source code.
The “obvious” advantage over OOP is in the first sentence (you can “pick n mix” behaviours from anywhere, and it all works 100%).
The “subtle” advantage over OOP is in the last sentence (even though with an OOP-sourced compositional logic system, there are some things you can implement efficiently, recombining them is generally impossible. this is built in to the concept of OOP at a fundamental level).
If you’re still not sure, then you maybe don’t understand OOP well enough, in which case I suggest you go learn more about the theory and history of it - you’ll probably find it improves your own understanding of the more complex and esoteric bits of OOP, and helps you write better OOP code first-time, every time. Objects were invented antithetically to the idea of “compositional logic” - they were invented as “hierarchically inherited logic”, like parent -> child -> grandchild.
NB: you can have hierarchical logic in a fn language (e.g. have a look at XSLT…), but you cannot enforce it in a fn language - the fn nature means it can always break out of that. OOP lets you enforce it (or, at least, make it really really difficult not to live inside it).
…but I’m probably just confusing the issue more than I’m helping here. The original blog posts I did on this topic took many many many hours each of careful thought and re-writing to try and make extremely clear … what is actually very easy to misunderstand. The posts I’ve done in this thread - on the other hand - are tossed out quickly, and are probably rather poorly explaining things / making a complte mess of it.
Sorry!
Hmm. I see what you mean, but no, that’s definitely not “the big advantage of ES”, rather it’s “something that OOP is guarnateed to f*** up every time, but with ES Just Works”.
i.e. it’s more of a reason “not to use OOP” than it is a reason “to use ES”. Unfortunately, there aren’t many viable alternatives to OOP …
I’m not sure still