User Tag List

Page 4 of 4 FirstFirst ... 2 3 4
Results 31 to 32 of 32

Thread: Message system discussion

  1. #31
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    I think the problem is actually simpler than some of that. Of course, this may just be previous experience with AS talking. We should probably just simply write those scripts as a first test case to get a better top-down view instead of an inside-out one, in any case.

    There's an interesting detail you've brought up here though: Conditional scripts. A script shouldn't even be created if it's dead or doesn't meet the necessary requirements. Of course, these would have to be set up in the editor first unless we do one of the following:
    1) Expand script metadata so that users can make script objects themselves conditional,
    2) Expose conditional variables to scripts.

    ...Maybe something else?

    At any rate you guys can have fun with it. There's probably lots of cool stuff that can be done as it progresses, I'm sure.
    Last edited by Gleeok; 02-14-2017 at 07:25 AM.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  2. #32
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    Quote Originally Posted by Grayswandir View Post
    Here's how I'm imagining the system:

    Global:

    • We have a global persistent key/value store for miscellaneous data. This can be used to store data between instantiations of the same object if needed.
    Is this really needed as a separate data structure? Or is this functionality already covered by the Game's key/value store?

    Objects:

    • Every object can be interacted with by its class. So a screen object has methods and variables that make sense for Screen, etc. (Like the Screen-> we have now).
    Are these fixed by the game engine? Or can the user modify/subclass the existing classes? The former is simpler, of course; are there sufficiently compelling reasons why users may want to define their own object classes (as opposed to script classes, which obviously they want to be able to write)?

    Every object has a publicly accessible key/value store. Again, this isn't saved persistently across instantiations of the object. This bit is nice to have, but it isn't particularly important that it's done right away, or at all.


    • The Screen object, and others that make sense to, may optionally have a persistent data store.
    I would think that either the store should always persist, or never persist? Is there a need for this to be case-by-case depending on the object type?
    Actually, this raises a confusion I've had for quite a while. For some types of objects, e.g. items, npcs, weapons, etc, there are two types of data associated to that object: there is the "default"/template data that is set globally for all instances of the object, for example in the item or enemy editor, and then there is the data that is *individual* to one particular instance of that object. A enemy script, for example, might want to 1) change the cset of one specific darknut on the current screen (leaving all other darknuts unaffected), or 2) change the cset of all future darknuts that are created in the game (i.e. by changing the default cset of all darknut objects). I assume there needs to be a mechanism for both.
    Items have the yet additional wrinkle that instances of the same item can appear on the screen (via a drop or item chest combo, etc), on the active subscreen, on the passive subscreen, and in random other places (all of treasures), and that scripts presumably want control over the cosmetic variables of the item in all of these places.



    • Each script has a public pointer to its attached object and its own name
    Why does it need a name? Can't it store its name in its own variable, if needed?

    Scripts can be moved between objects, but can't live on unattached. (Though there will be a global Game object for global scripts.) Every script can have a destructor message for when its attached object dies (possibly letting it move to another object before it disappears.)
    Why not let them live unattached? Once could imagine, for example, implementing an item use script for the candle which creates the flame sprite and controls it for a few frames (until the flame dies out). If the candle is removed from the player's inventory during that time (thereby leaving the item use script orphaned) I don't see why the use script shouldn't be allowed to finish its thing, until its use message handler finishes.



    • Every script has a vod receiveMessage(string message, args...) method which adds a pair<Script, Message> to the global queue. The queue is run through several times a frame - during Waitdraw(), Waitframe(), etc. Basically, any time the main program stops to send the built in messages, we run through the queue first. Messages can be appended to the queue by messages started from the queue, and they will still execute during this time step.
    • Every script has a public bool hasMessageHandler(string name).
    • Scripts don't need a key/value store, since they can just make variables as needed.
    All makes sense to me.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social