Hello Rickard!
I'll reply to your mails on "Fine-grained control of modifying
associations" and "Pattern for modeling Roles, States, Entities" in one
same reply, since approximately same thing is currently being talked about in
two
topics.
> Why? It has quite big repercussions to say that something is an
> Aggregate root. For example, if you delete the WZ it has to delete all
> the WorldObjects. Is that what you want? Or should they just be
> transferred to another WZ? And whenever you change a WorldObject, do you
> have any validation rules you need to run on WorldZone? I don't know
> what you're doing, but from the names it sounds like you're going to
> have a large amount of WorldObjects, right?
>
Yes, indeed that is what I want (with certain conditions, at least).
Some WorldObjects shouldn't be deleted along with the zone, in that
case the deletion should be aborted. However, the most common scenario
is to delete all world objects along with the world zone.
I am not sure yet about WorldObject changing policy. Should I just give
anyone opportunity to change it via its interface, or should I make
changing it restricted into some other place, like WorldZone, which wouldn't
allow just any kind of changing go through. That is
one (more) thing to decide. And yeah, I'm most likely going to have
large amounts (umm hundreds, possibly thousands) of WorldObjects in one
WorldZone.
> > I assume "localIdentitifer" would have to be identity() of the
> > WorldObject. However, finding out which WorldZone WorldObject belongs
> > to, is going to be a little problematic and possibly slow. I am not sure
> > which is going to be more intense - the searching for WorldObject's
> > WorldZone, or the searching for WorldZone's all WorldObjects. I will
> > need to look into that too.
>
> What are your usecases, is the main question. What are the operations
> you will be performing on these things, and for what purpose.
Well, I am not quite sure yet. :) As I said (in other topic, I think),
this is all very new and fresh project (for me), and I am kind of
learning as I proceed. That's why I have these "iteration-rounds" - I
try to do refactoring iteration always after iterations which add new
features. This is going to be (if it ever lifts off) sort of engine
framework for games, possibly MMO's. More detailed description follows at the
end of this mail.
So
actually, at the moment I'm
having (among others) "WorldObject"s, "WorldZone"s,
"WorldObjectInstance"s and "WorldZoneInstance"s. The problem that I
originally asked solution for, was actually for bidirectional
association between WorldObjectInstances and WorldZoneInstances. I
wanted to be short and simple tho, so I left that aspect out from
original description.
So, about usecases and operations performing on those things - I have
vague ideas at the moment, but currently it's all a bit too fuzzy in my head to
put
properly into words. If you ever played any MMO's (too many of those
around now to even start listing) or dungeon crawlers (ASCII-graphic ones, like
NetHack,
ADOM, etc), you most likely would identify at least some usecases just
from experience of playing. I think, at least retrieving world objects
according to some condition from world zone is most likely going to be
quite used usecase. At the moment I don't have any coordination system
yet - I am trying to keep it abstracted away from the very engine core,
but I'm not sure if that will be possible. So if I'll bring that in, it
might bring more usecases to the engine core, especially for
WorldZoneInstances and WorldObjectInstances.
But
the trick of implementing the other direction of association via query
should, I think, not slow down things too much - especially since
retrieving world objects to some condition from world zone is a kind of
query by itself.
> > Maybe "WorldObject" is kind of "role" by itself, being many other roles.
> > It might be useful to tie several roles together. Might save "are these
> > different roles references to same object" checks later somewhere. :)
>
> When I say "Role" I mean roles in actual interactions, so the ***ONLY***
> way for you to know if it's a role or not is to figure out what your
> interactions are. If there is NO interaction that cares about
> "WorldObject", then it's not a role. But this all depends on what you're
> actually trying to accomplish.
>
I'm
pretty sure that the WorldObject is a role. At least the users of a
framework should see that as one single role. Same applies for
WorldObjectInstance.
Let me explain in more detail what is going on in the project at this moment -
at least not to keep you "veiled in darkness". :)
Currently
there are two packages - the structure package and runtime package. The
structure one has the means to manipulate the structure of the game
world. It has such main roles as WorldObject - describing what is world
object like currently only name + description + possible other
WorldObject "children" of which it composes of. For example, one could
think of a "flail" to compose from other WorldObjects, which represent
"stick", "chain" and "spiky iron ball". Then we have a WorldZone -
currently only extending roles ImmutablyNamed and
ImmutablyDescriptioned (these roles are actually extended by all
structure main roles). Then we have a WorldObjectCharacteristic, which
represents some ability. This ability could be "mobile", "sentient",
"canSee", "canFeel", etc. And as a final main role is Action, which
tells which WorldObjectCharacteristics it requires, in order to be
performable. For example, action for moving would require "mobile"
characteristic. Currently this is a little unfinished, since I want
action behaviour to be customized by framework users, so I will most
likely will need ActionBehaviour role there too.
The second package
- runtime one, provides means to create an actual game world, based on
a already built structure. It has the following main roles:
WorldZoneInstance - a role representing a certain instance of a certain
WorldZone in structure package. Can hold WorldObjectInstances.
WorldObjectInstance then is a role representing a certain instance of a
certain WorldObject in structure package. WorldObjectInstance always
belongs to some WorldZoneInstance, and can have many
WorldObjectCharacteristics. The set of these WorldObjectCharacteristics
may change runtime (the character might become blind - take away
"canSee" characteristic). Finally, I have GlobalScope role to hold all
the WorldZoneInstances, but I am not sure how needed that is. Assuming
there are no other games in same repository, equal functionality could
be provided by WorldZoneInstanceRepositoryService. However, since I
haven't yet touched "time" aspect of a system at all (how to model time
in the game universe), I'm keeping this role hanging in so far. Also
notice that I haven't touched graphics aspect either, since I don't
have any experience from 3d-graphics. I'm thinking of getting away with
it the same way as with coordinate system - let framework users
implement it. I wonder if that will be successful. ;) However, since
some of the Qi4j's main ideas is to minimize coupling, and to isolate
behaviour and state, if everything works as it should - that should be
quite possible. Time will tell.
If I used some termins wrong in
previous description, feel free to correct me. But I hope that gave you
a basic idea of what I'm doing here. Even thought this might sound
(too) ambitious, at the moment it is very modest start. :) So I'm not
(yet) dealing with too complex issues - at the moment I'm actually just
trying to figure out at least some kind of working API for the engine,
trying to keep all the performance, security etc issues on my mind.
_________________________________________________________________
Drag n’ drop—Get easy photo sharing with Windows Live™ Photos.
http://www.microsoft.com/windows/windowslive/products/photos.aspx
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
