Systematic numbering of containers

This forum is currently in read-only mode.
From the Asset Store
A well commented Dynamic Heart Containers template to learn from or to use as a base for your own game!
  • I've been mulling this over for a day or two. The idea is to give each enemy container a unique ID number. This allows me to selectively activate individual containers for predetermined actions and movements.

    For instance, for my game I have each level broken down into "encounters." Instead of everything being time critical, encounters allow me to set up challenges for the player and seamlessly string them together no matter how quickly the player completes his task. If, say, encounter 24 spawns two enemy containers I need to have full control over each to give them individual movement waypoints and firing instructions.

    The way I'm considering doing this is using a global variable to create unique IDs, and assign them to each container on creation, then ++ the value.

    [Begin Encounter]

    + Encounter == ##

    • Spawn Enemy at (location)
    • Set Enemy.ID to 'UniqueID'
    • Add one to 'UniqueID'

    (above will be more precise than simple add 1)

    • Spawn Enemy at (location)
    • Set Enemy.ID to 'UniqueID'
    • Add one to 'UniqueID'

    + Value Enemy.ID == specific number A

    • Set location of Waypoint to X.Y
    • Set angle of movement toward Waypoint
    • Set Enemy.speed to 30

    ...rinse and repeat for other instances.

    So, does anybody have a better way of doing this that I might be overlooking? Is there a function of containers like this that is yet undocumented?

    Thanks again, guys, gals.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Containers select all in one go - so you only need an ID for one object in the container... and every object has a UID already built in

    What do you use IDs for btw? I've never really needed to use them, considering we have 'For Each' and all...

  • Well, for each and all are fine when the intention is to work them in batch. I will still use containers for that purpose, in fact. However (and I haven't played with any tests yet), I also need to be able to create and manage individual containers on the fly. To do this, they need to have some form of separation, as shown in the pseudo code above. Let's say I create two new Enemy containers, but I want them to place their movement waypoint objects on separate sides of the screen, proceeding to meet up with them later. That's the intended effect.

    Create new container, number it, perform actions on it individually if I want, all the while letting the containers do what they do best as far as batch commands go. Laser hits enemy container #4, destroy it. Special instructions to that container will simply be ignored, allowing the remaining instances to go about their tasks.

  • A visual example:

    <img src="http://www.strouperman.com/Special/screen/test1.png">

    <img src="http://www.strouperman.com/Special/screen/test2.png">

    <img src="http://www.strouperman.com/Special/screen/test3.png">

  • You could use private variables to number them like so:

    http://www.mediafire.com/?fy0uxzykvzy

    The example uses RTS for simplicity's sake, but you don't need to.

  • Once again you come through for me, Deadeye. More cookie for you.

    Shouldn't be very difficult at all to modify this to remove the random functions and create the specific encounters I have in mind. This whole thing has taught me a lot about containers, and I'm really enjoying the concept.

    New dev journal and example caps coming soon. I'll be sure to recognize your contributions.

  • No prob.

    When you get your encounter script system set up, please share. I'm curious to know how that would work. (Are you gonna load it from a text file or something?)

  • I've been considering that. It would certainly be cool to allow users to create custom levels without having to use Construct. The only thing that might hinder that is the way the thing currently handles copy-pasting events as text. There's no easy way to getting things first INTO a text file without copying every individual event individually solo and all by its lonesome individual self. Unless my inability to copy multiple events as text at once is yet another bug.

  • Hmm. I've been mulling over how to use a script (not a Python script, more like a movie script) to control AI in NPC's. I'll have to give it some testing.

    If you did get the load-script-from-file thing working, not only could you define the actions of the enemies and such, you could instruct your NPC comrades on which ships to take out. Heck, you could even put what they say into the script. Just be sure to have Slippy say "Ahhhg! I've got one on my tail!" like every ten seconds.

  • You're precisely right. I'm glad you made me think about it again at this stage in development. I might has well design my objects and names with the intention of outside expandability, if only for the organizational improvements. I'll report back in two or three days.

  • You know what would be nice? External event sheets. Sure we can call python scripts and stuff, but event sheets are still limited to the construct program. Wouldn't it be nice to use Construct's native event sheets as external text files to be imported at runtime?

    To be able to include a custom level template along with the EXE... and have this feature be native to Construct, would really beat the hell out of INI files and python scripts. In your games, you could write functions that could be called by a modder through external events. Want the space background instead of the water background? Change the line of code in the template, and have the layout's events build the level per your commands for that choice.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)