Using containers and families?

Post reply
0 favourites
  • 10 posts
From the Asset Store
Zombie Family - Game Sprites
$12 USD
A collection of various zombie characters sprites for creating a 2D platformer or sidescroller game
pzUH's avatar
pzUH

  • In my platformer, I want each enemy sprite to have an enemyBox sprite to use for movement positioning, along with an enemyLabel text. To make things easier, I was hoping to use containers.

    Since an object can't be part of more than 1 container, and I have many different enemy objects, I can't just create a generic enemyBox sprite and add it to each enemy's container. Therefore I was planning to create 3 families: enemies, enemyBoxes, and enemyLabels. Then I would make individual containers for each enemy type. I.e., zombie, zombieBox, and zombieLabel would be 1 container.

    My prototype works except for the code that positions the enemy on the enemyBox. When pressing 'z' or 'w' to create the first enemy, it places it fine. If I continue to press the same key to create the same enemy type, the new enemies are created and placed as expected. But when I press the other key to create the other enemy type, the new enemyBox is created properly but the enemy is placed on the previously created enemyBox. Pic and c3p attached.

    What am I doing wrong here?

    Question 2: is using containers + families a good approach for what I'm looking to do, or is there a better way? I originally tried using a common instance variable called uniqueID to tie the different objects together, but I ran into picking inconsistencies. The container approach seemed like a promising solution, but this issue is giving me pause.

    Thanks

    https://drive.google.com/file/d/1glQSeDO72Fvi3SsmARA-Xsh_s_3nDdIJ/view?usp=sharing

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You can't use families here because they don't relate to the containers. You need to just set position for things that are in a container. You don't need to use the variables either because the containers already do the work of linking them.

  • Gotcha - so is this what you're suggesting? It works :)

    If I have 20 enemy types I'll have to do this for each type. Not a huge deal in this case, but I can't anticipate how often I'll have to do something similar for all enemies, and I want to be clean and efficient with my code if possible. If I use the containers+families approach, is there any way I can leverage the families to simplify container-related activities? I'm assuming 'no' per your response but making sure I'm not missing something.

    Thanks

  • You can't use families here because they don't relate to the containers. You need to just set position for things that are in a container. You don't need to use the variables either because the containers already do the work of linking them.

    So it looks like I lose the value of families if I use containers. For example, if I every want to change the text of an enemyLabel when I click on its enemy, I can't use this because it will change the text of EVERY enemyLabel:

    Instead, I need a block like this for EVERY enemy:

    Is this correct? If so, using containers+families is a non-starter, and I'll have to go back to using families and tying enemyBox objects to enemies using the uniqueID approach (groan).

  • Yes. When you pick enemies or enemybox you are not picking the container but the family. Families are good for some things but if you want to use a container better to pick the container objects.

    If you are going to use many objects then it looks like you don't need to make a separate enemybox object for enemies, you should just use one object. I don't know what its use is but I can't imagine you need different objects.

  • If you are going to use many objects then it looks like you don't need to make a separate enemybox object for enemies, you should just use one object. I don't know what its use is but I can't imagine you need different objects.

    I was thinking the same thing. The enemyBox is just for positioning and movement, so I was first thinking to have a single enemyBox object with 1 animation (and collision polygon) per enemy type. But and you can't have an object (i.e., the enemyBox) belong to multiple containers, so instead I was planning to create an enemyBox object type for each enemy type and then put the 2 in a their own container. But since containers cant be used for families, it looks like the best option is to use my family of enemies with a single enemyBox object type, and tie the 2 together using a uniqueID instance variable.

    I got so excited when I saw what containers can do. I haven't use a scene graph object yet, do you know if that may be a good option for what I'm looking to do, and if it works with families?

    It's a bummer C3 doesn't support containers with families. Both features have significant benefits and if they worked together it could make the pick code more elegant and much less error prone. I spend a lot of my time debugging issues related to object selection. Thankfully folks like you have been very helpful when I run into problems!

  • Not really understanding the problem here? If you want to create a specific enemy then you have to pick that enemy anyway, nothing to do with families. If the animation object is in a container with the enemy then great.

  • Not really understanding the problem here? If you want to create a specific enemy then you have to pick that enemy anyway, nothing to do with families. If the animation object is in a container with the enemy then great.

    Here's one scenario: When an enemyBox is hit by bullet, stop enemyBox's motion (using platform behavior) and reduce enemy's health

    Let's assume the enemy object has the relevant enemy data in instance variables (health, speed, power, etc), and the enemyBox object has positioning info, collision polygon, and Platform behavior. And the enemy and enemyBox are in a container.

    If I was able to use enemies and enemyBoxes families and put them into containers together, I can write the above with a single condition and 2 actions and it will apply to all enemy types. But because I can't use families with containers, I need to write this code block specifically for every enemy type.

    There are tons of places in my code where I leverage families for actions to apply to all enemy types, so I foresee the issue above being replicated many times.

  • The problem is you've split the data across two objects, everything should be on the enemybox, the other object which I assume is just the visual should have nothing except be in a container with the box and be created along with it. Put the data on just the one enemy object and all the problems go away. You should only need one enemy family as well which contains the boxes.

  • Yeah I get what you're saying. But I do have lots of logic that makes decisions based on animation state (when the collapse animation ends, when frame 2 of an animation is played, etc), so even if I moved all the data over to the enemyBox object, they'll still be plenty of instances where I'll need to get data from the associated enemy object.

    I have 1 year's worth of code where enemy was the only object, and I recently determined I need to have an enemyBox object for positioning. Live and learn. Thanks for the help!

Post reply
  • 10 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)