I find it quite fascinating that so different projects (topic-wise) have so
much in common. :)
About those things you mentioned:
> 2. Each Controller has X inputs and Y outputs.
At first I thought those were similar to my WorldObjectCharacteristics, but now
I think that's not quite the case.
> 3, Each Input can only be Wired (inter-WorldObjectInstance
> interaction) to a single Output (inter-WorldObjectInstance interaction
> responses)..
Ahh, so kind of separate the interaction between WorldObjectInstances
(Controllers) and interaction between WorldObjectInstance and something else?
This is quite interesting idea - I need to think about it for a while and test
how it works out. :)
> 5. The ControlProgrammer can modify the ControlProgram, by requesting
> the Controllers as ProgrammableControllers (i.e. WorldObjects). It is
> the same underlying entity state, and the ControlProgrammer have now
> access to make Wiring changes. It can also query for what
> Inputs/Outputs and Parameters(see below) are available.
Hmm, I think this is where our systems differ a bit. I see WorldObjects as
"static" structure, and WorldObjectInstance does not share same entity state as
WorldObject. For example, like this: we could have WorldObject, which would
represent some weapon, let's say that familiar flail. It has name ("Flail"),
and some description ("This is a stick which has a spiky ball attached to it
with a chain. Try to hit enemies with a ball."). Now, as such, it just sits in
database and pretty much does nothing. When something happens ingame, for
example a monster is killed which by some mechanism decides to leave a flail as
a loot, a new WorldObjectInstance is generated, which has some
instance-specific things (like random material for ball, varying from "wood" to
"adamantite", etc). This new WorldObjectInstance has a Association to
WorldObject, and this WorldObject represents the actual "type" of object, sort
to speak. I ended up to this kind of solution because in long run (and with
thousands and thousands of WorldObjectInstances) it is pointless to keep
non-runtime related things on runtime-objects, as it wastes space and time, and
makes things harder to manage.
Another example: game developer of some MMO which uses this framework decides
that some weapon is too overpowered and needs its base damage to be changed.
(S)he then changes some WorldObject, and ALL WorldObjectInstances that refer to
that WorldObject now automatically update their damage to new one. This way,
for example, game-content patches could be done runtime, without needing to
bring server down.
On a problem of "custom" or "unique" or "random" items : I think that can be
circled by having such items being really rare, and whenever this item decides
to appear, a new WorldObject would be created specifically for it. It would
have some flag, which would tell that this is uniquely-generated WorldObject
and this would tell the engine to allow maximum of one WorldObjectInstance to
have association to it.
> 6. Each Controller also has Parameters.
>
> 7. Each Parameter is either a ProgramParameter (i.e. charateristic) or
> a RuntimeParameter (i.e. for dynamically changable characteristics,
> such isBlind() ).
Ahh, now I see the parallel of my WorldObjectCharacteristics in your system.
So, the user can change Parameters and Wirings of a Controller? How Parameters
affect on Controller? Or do they only affect on Wirings/Inputs/Outputs?
I also thought of separating WorldObjectCharacteristics to programmed and
dynamically changing. However, when I started to think, I couldn't find any
characteristic, which shouldn't be able to change runtime. For example, MOBILE
characteristic can be removed (temporarily) with "root" effect (kind of "magic"
thing, which purpose is to make target immobile), and well, pretty much
anything else can be removed/added dynamically. So my
WorldObjectCharacteristics are purely runtime - anything can be added and
removed. I was thinking of adding a role of "Instric", which would be some sort
of guard on what characteristics can be added or removed. It would be
practically same thing as adding Constraints on add/removeCharacteristic
methods on WorldObjectInstance, except Instrics would be entities and thus
could be saved in database. WorldObjectInstance then would provide methods to
add/remove Instrics.
> 8. A third role on the Controllers is the QueryableController, which
> basically allows you to retrieve the internal state of the Controller
> for display purposes.
I think now that I should also introduce some sort of
"QueryableWorldObjectInstance" and "ProgrammableWorldObjectInstance" to my
system too.
> 9. When a ControlProgram (in my case could be "WarmWater regulation to
> 55degrees Celsius with burn protection" ) is requested, the runtime
> engine (no name yet) will create a UnitOfWork and load the
> RuntimeControlProgram aggregate, which in turn holds the Controllers,
> which in turn holds their "interaction wiring" between themselves.
Yes, sounds quite like WorldZoneInstance creating. Except that I have
WorldObjectInstances there (would be ControllerInstance in your system).
> 10. Ultimately, 'wiring' has Sources and Sinks, which are stuff like
> Timers, Physical Input/Output, TCP ports and some others. They are
> provided via the Service mechanism, as they are a lot more resource
> intensive a require special handling. Sources initiate the
> 'interaction event chain' and the 'event' spreads though the
> ControlProgram and eventually dies down when all events have 'died
> down' either from being filtered in Controllers or reached Sinks.
Ahh, so Sources are the event generators. I was thinking that my
ActionBehaviours would be the ones generating the events, whenever performing.
But this event-mechanism also requires me to think about whole time-issue (the
game-world having its own time universe), since I want to easily add events "to
future". And that's why I haven't mentioned anything about events in my
original description - I am yet to properly to think about whole thing. :)
Maybe more versatile way of telling what Action requires - right now it is just
a list of required WorldObjectCharacteristics.
> 11. Finally, the logic of each Controller, both the Runtime role and
> the Programmable role, are implemented in Java, so there are many
> sub-types of Controllers, such as PID-regulator, HighLowLimiter,
> AlarmPoint, ZoneController et cetera. Programmers will add to the
> repoertoire of controllers, and install the "Controller types" as OSGi
> bundles, and the ControlProgrammer will ask services for available
> types. Ultimately, those shows up to the user during "programming" as
> tools in a Palette, to drag into the ControlProgram and be wired up.
>
>
> Now, I don't know about you, but I see a lot of similarities here, and
> I think what you are doing can be implemented with the same pieces
> (different names), except that you would need to make the wiring
> system dynamic as well, since as your characters move around you will
> end connecting and disconnecting with other elements in the world.
> Personally, I think event-driven (a.k.a write-only) systems are
> superior to request-response systems, and if the 'wire' is abstracted
> as well, the system can much easier be spread across JVMs, as a
> single, one-directional transport mechanism needs to be implemented.
>
I agree with you on write-only systems. Think I "was raised" with event-driven
system so it goes deep into my way of thinking things.
I also agree that what I am doing can be implemented with same pieces - or at
least heavily taking influences from. However, I need also to be prepared for
quite "unrealistic" demands, such as for example "make gravity disappear at
point X,Y,Z and everything else at radius of W meters" (as an effect of some
sort of spell, for example), so every single rule and feature in game-world
needs to be customizable or disablable. It's like in the Matrix the movie:
"some rules can be bent, others can be broken".
All in all, I think this all needs some time to digest and properly understand.
Maybe I will end up implementing system exact way you did yours - but I don't
want to just imitate, if not for nothing else, then at least for respect for
other people's ideas. But thank you for telling me about all those things - it
certainly made me look at things from new perspective. :) I'll keep you updated
on what solutions I've made, once I've made them - if you're interested.
_________________________________________________________________
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
