This is a little late but I wanted to jump in with respect to the
Flail example. Most of my modeling experience is in relational
databases so bear with me :)
interface WeaponType {
ManyAssociation<WeaponCharacteristics> characterisics();
Property<String> name();
}
interface Weapon {
Association<Player> player();
Association<WeaponType> type();
ManyAssociation<WeaponCharacteristics> customCharacterisics();
}
interface Player {
ManyAssociation<Weapon> weapons();
}
interface WeaponCharacteristics {
Property<Integer> boom();
Property<Integer> pow();
Association<WeaponType> weaponType();
Property<Boolean> default(); // whether or not this is an allowed
custom one or a part of the basic weapon model
Property<Boolean> active();
}
So here the player has a weapon that inherits characteristics from a
system-wide type but it can also have extra custom characterisitics.
The admins can change the system-wide characteristics associated with
the weapon type and can also take away custom characteristics. I don't
have the implementation idea down yet but this is a common scenario in
a lot of projects I've worked on. It would be nice if we all can flush
this out :) Just dropping my two cents in.
On Fri, May 8, 2009 at 1:58 PM, Staz . <[email protected]> wrote:
> 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.
>
> ________________________________
> What can you do with the new Windows Live? Find out
> _______________________________________________
> qi4j-dev mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/qi4j-dev
>
>
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
