Player 1, 2, 3, 4... Duplicate Events?

  • Hey All,

    As I keep learning while working on my game, For start I have Player 1 which have it's own Mask for collisions called: "Player_1" and another Sprite for the Character's Main Graphics, Sprite for Different Animated Attacks and another Sprite for Wearable Items.

    .

    So I did make a Family for "Player_1" and included most of the above just for the Flashing animation when my player is damaged (temporary invincibility mode) but not for all the variables.

    The thing is that I can't put all the elements in it because of the different mechanics of the game that affected by the Sprite for Attacking, and the Sprites for each item that will Pinned to the Player's sprite who pinned to the Mask.

    .

    I NEED YOUR ADVICE:

    Once I will finish with Player 1 mechanics, I would LOVE to add Player 2, Player 3, Player 4 to the game. but I'm not sure how to do that with minimum manual changes after duplicating Player 1's dedicated event sheet.

    .

    My first thought is to duplicate ALL the sprites and what not, Rename them of course and make another Dedicated Event Sheet for each one of the players.

    .

    I thought about Family for all the Players where I can share their properties, but as I described above it's more than just Mask + Sprite connected, there are other elements so it's more complex.

    Also, If I will make a Family for all the Players for their instance variables such as Hit Points, Damage, Jump Strength, etc..

    Whenever Player 2 or Player 3 be affected, it will change ALL THE PLAYERS right?

    .

    What is your advice for a safe, clean, better way to make my game from 1 Player to 4 ?

    I'm not sure if it helps, but I'm planning to make an extra mode to play with friends, while the main mode will be single player, different game-style / rules.

    .

    The reason I'm asking this now is because I'm still working on the base mechanics and I don't want to code the other elements wrong so it will be much more work to control later on.

    .

    Sorry about my bad English and Thanks ahead! :)

  • I would make a separate save file and try a few different approaches.

    Keep in mind, there are different ways to do everything in development and none are wrong, although some may be more efficient.

    My Recommendations:

    You will want to use containers for the sprites, I would then create a player family and use that for the logic, you wont need to re-write or copy any code or duplicate an event sheet, then use a family variable to declare which player is which when you get to that point, use that variable to assign to a player and instance of a player.

    As for Family variables, they will assign each instance of that family member its own instance variable, they are not global so that won't be an issue, they simply automatically assign the variable which you can then access through the object itself.

    I recommend opening up the RTS template to get a good look at containers and families.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Also, If I will make a Family for all the Players for their instance variables such as Hit Points, Damage, Jump Strength, etc..

    Whenever Player 2 or Player 3 be affected, it will change ALL THE PLAYERS right?

    --

    To identify the players you can have a family instance variable for 'player number' and pick based on playerNum=1 etc

    I am player 1 = family.playernum=1

    For family, where playernum=1, set my P1 stuff.

    I am player 2 = family.playernum=2

    For family, where playernum=2, set my P2 stuff.

  • You made a mistake adding those sprites into a family!

    They may be added to a container, but not to a family!

    These two features have completely different meaning, but many people confuse them..

    You should add objects to a container when they should be logically linked together (when they all combined make one big complex object). PlayerBox+PlayerSkin+PlayerAttackAnimation+PlayerWearable+PlayerHealthBar=make one Player

    All these sprites refer to one player, so you can add them to a container. This will make lots of things easier - picking, creating/deleting instances etc.

    Also, containers make sense when you have many instances of these objects. For example you add 4x instances of PlayerBox to the layout, and the system will create PlayerSkin+PlayerAttackAnimation+PlayerWearable+PlayerHealthBar for each of the 4 players automatically.

    If you only have one instance of each of these sprites, there is no point to add them to a container.

    .

    Families are different. You add objects that have similar features to a family. For example you can add all different monsters to one family Enemies. Or all different controls in your game into a family Buttons. This allows you to create universal events, for example: On Buttons tap -> Play "Click" sound

  • Thank you for your advices AnomalyHatchery and plinkie I appreciate it.

    The reason the containers didn't work for me is because of all the other sprites that connected to the main character react to each once code, for example destroy and others so unfortunately I cannot use containers from what I tested.

    .

    As for Family variables, they will assign each instance of that family member its own instance variable, they are not global so that won't be an issue, they simply automatically assign the variable which you can then access through the object itself.<

    Oh! I didn't know that, so I should do some test and see how it works exactly on my complex case of so many "parts" for each player.

    .

    To identify the players you can have a family instance variable for 'player number' and pick based on playerNum=1 etc I am player 1 = family.playernum=1 For family, where playernum=1, set my P1 stuff. I am player 2 = family.playernum=2 For family, where playernum=2, set my P2 stuff.

    I'm not sure if I'll know how to make your example works since I'm still learning Construct as I go, but it sounds like FAMILIES ARE the answer after all!

    Thanks again for your suggestions, I should do some tests and see if anything will work or not.

  • You should add objects to a container when they should be logically linked together (when they all combined make one big complex object). PlayerBox+PlayerSkin+PlayerAttackAnimation+PlayerWearable+PlayerHealthBar=make one Player <

    To be honest I'm still confused, probably because of my specific game mechanics "engine".

    It will not work for me to put all these you've mentioned as one container because each one of these items affect something else, and must be independent because of that.

    .

    For example if I will destroy the wearable, the Player and other stuff will get destroyed as well (that's from what I've tested for container instead of families).

    .

    Or when my Player's Sprite is flashing for few seconds, all the other sprites will be invincible for few seconds but that's not what I may want for some of the items.

    .

    What I'm saying is, it is much more complicated for me because I probably built everything wrong but it is working now and I just need to find a good way to build over it, that's probably a stupid way but I can't just duplicate my players with Families and of course not with Containers.

    .

    The only solution I can think of is maybe to make Families inside Families to control general groups that needs the exact same control or share the same properties / variables. but it's getting too complex so I'm still testing options.

    .

    It's like when I tried to use the Arrays, I found out that it is sooo hard to manage even with the Array Editor the code with the Ajax, Json, etc... is sooo confusing to me, so I decided to go for the most simple way: Groups and variables.

    .

    I bet you read this and you're thinking: "How stupid is he, why he's doing this in the wrong way?"

    The thing is that, I'm still learning and while I look at the event sheet, I guess the old fashion way make sense to me visually, my "brain" can understand things better.

    .

    Like you've said before, there are many ways to do the same thing but I really feel bad knowing that I'm already doing these stuff in the wrong way and I may regret it as the game gets even more complex with more events and rules to the game.

    .

    I'm just sharing my mind here, I can only blame myself but I will read your advice on this thread (and the others) as they may make more sense to me compare to this specific game I'm working on of course, because in general it is 100% making sense to me.

    .

    Thanks again and sorry about my bad English.

  • You don't need to use containers, they just make life easier :)

    And yes, you should only add objects that live and die together. So that wearable sprite should not be in the container.

    One container can hold only one instance of each object. So you can't add CarBody and 4x instances of CarWheel into the container, it will not work.

    Very common example is to add an enemy sprite and health bar to the same container. You don't need to worry about creating/destroying the health bar, nor about picking it. You can make simple events like On bullet hit enemy -> Enemy subtract 5 from health, HealthBar set width to Enemy.Health (this enemy's HealthBar will be picked automatically)

  • Thanks again dop2000 I'm learning a lot from your explanations and tips!

    Your examples are great and to the point, I appreciate it. :)

  • When I mentioned the picking earlier, so a player 1 has variable playerNum=1, you can assign everything linked to player 1 with an ID of 1. Then for player 2, which has variable playerNum=2, you can link everything to that player with an ID variable of 2.

    So hypothetically if player 2 was attacked and you wanted to pick something related to player 2, like a shield taking damage you would say :

    on player(family) attacked

    pick shield, where shield.ID=player.playerNum

    shield take damage

    But then the good thing is that this generic code actually applies to all players because you are using families.

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