User Tag List

Page 1 of 2 1 2 LastLast
Results 1 to 10 of 16

Thread: Instances to attack each other?

  1. #1
    Clicker Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)

    Join Date
    Jan 2016
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Instances to attack each other?

    Hello. Is there someone willing to help me with a problem? I already asked this in another post, but that post I made was originally about a different topic and I started to feel that this topic needs it's own post.

    I have a base vs base game, with some different minion types. Since I am aiming for "as many minions as possible/ still keep the game small enough to work", I have tried to find ways to keep active object amount as low as possible. One thing I was hoping to do is to use an active object for a minion, like "type1" for an example, and then use instances of that object as actual game units, but it, of course causes that dreaded instance vs instance problem.

    I already got some really kind people to answers about the problem ( http://community.clickteam.com/threads/96174-Active-object-amount-limit/page2 ) of instance vs instance and got this:

    "type1" attacking
    >>> count each one of "type1", loop name "attack"

    on each one of "type1", loop name "attack"
    >>> place "detector" on attackrangeX,attackrangeY
    >>> set detector ID to fixed value "type1"
    >>> set detector "do_damage" to type1_attack_damage
    >>> start loop "test detection" 1 time

    on loop "test detection"
    + detector overlapping "type 1"
    + type1 fixed value <> detector ID
    >>> sub do_damage from "health"

    However, I have not been able to add player1 vs player2 layer to this properly, since the code already there causes all instances to attack all others except themselves. My tests with values, flags and other ways to determine player1/player2 status have resulted with all of them dying, none dying or some other half way there- solution.

    Is what I ask even possible, is it possible on top of the code I already have, or is there another way to try this? I know I could try making type1_player01, type1_player02... objects and use those instances against each other to do this, but that would leave me with twice as many objects and really just put me back to where I started from? Also, if I choose to try player 3 and 4 with less minions overall, the solution will cause 4 times as many objects and will likely cause the game to get too large.

    (Sorry, if this matter has already been answered elsewhere. I have found some post about this matter but none, which would exactly help me to make those silly minions attack as they should. Since many parts of the game, like harvesting, construction and such, are already working, I'd hate to fail with it just because I can't make my minions to attack properly.)

  2. #2
    Clicker Fusion 2.5 DeveloperAndroid Export ModuleHTML5 Export ModuleiOS Export Module
    Fusion 2.5 (Steam)
    schrodinger's Avatar
    Join Date
    Nov 2014
    Posts
    3,155
    Mentioned
    27 Post(s)
    Tagged
    1 Thread(s)
    Heh, this is a bit of a Achilles' heel around here
    (please, you F3 guys, give us multi instances interaction! )

    Not sure if I understood,
    so this approach didn't work for players?


    "type1" attacking
    >>> count each one of "type1", loop name "attack"

    on each one of "type1", loop name "attack"
    >>> place "detector" on attackrangeX,attackrangeY
    >>> set detector ID to fixed value "type1"
    >>> set detector "do_damage" to type1_attack_damage
    >>> start loop "test detection_type1" 1 time
    >>> start loop "test detection_players" 1 time

    on loop "test detection_type1"
    + detector overlapping "type 1"
    + type1 fixed value <> detector ID
    >>> sub do_damage from "health"

    on loop "test detection_players"
    + detector overlapping "player"
    >>> sub do_damage from "health"

  3. #3
    Clicker Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)

    Join Date
    Jan 2016
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My English is crap, so it's not as much about someone understanding me as it is my way of saying it in the first place… Your code seems to work, but what I was planning was a bit different, or I just didn't use it the right way. I will try to explain with what would actually happen in-game:

    1. There are a mass of minions attacking each other from two bases with early tech Type1-minions (instances of Type1 object).

    1.1 One army is Player1 and the other one is Player2, so any instance should identify it's player status respectively, being either Type1 (as Player1) or Type1 (as Player2).

    (I tried using values, like value A=1 meaning player1, value A=2 meaning player 2, and other identification methods, but until now I haven't been able to get it right.)

    2. Minions meet somewhere in between, and they start to collide with each other and by thus start attacking, which brings the code to use. Type1 (Player1) units kill Type1 (Player2) units and vice versa… or however it's spelled.

    However, with the code happens this:

    1. There are a mass of minions attacking each other from two bases.

    1.1 Type1 minions seems to just see themselves as minions and not under any player, no matter what values or checking methods I have implemented.

    2. Minions dont' meet somewhere in between, and they start to collide with each other and by thus start attacking each other whenever two of them reach each other. Since they do not check if they are controlled by the same player, it just turns into a free-for-all slaughter.


    So, what I would need is a Type1 instance with two “layers”
    1. Ability to attack other instances (that one is not a problem with the code I have already)
    2. Ability to check if the instance is a part of the same army and deny attacking it even thou it could do so.

    Did that help at all in explaining the problem, or did I just make it even more complicated? Or did your code actually mean to do what I said above and I possibly just used it the wrong way?

    And sorry, my fear for countless spelling errors causes me to talk like a five year old robot.

  4. #4
    Clicker Fusion 2.5 DeveloperAndroid Export ModuleHTML5 Export ModuleiOS Export Module
    Fusion 2.5 (Steam)
    schrodinger's Avatar
    Join Date
    Nov 2014
    Posts
    3,155
    Mentioned
    27 Post(s)
    Tagged
    1 Thread(s)
    Ah, my bad, it's perfectly clear now (I guess )

    So you need type1 minions to deal damage to type1 minions only when they does not share the same "belonging".

    I refresh the question then,
    so you tried this approach and didn't work? >>

    "type1" attacking
    >>> count each one of "type1", loop name "attack"

    on each one of "type1", loop name "attack"
    >>> place "detector" on attackrangeX,attackrangeY
    >>> set detector ID to fixed value "type1"
    >>> set detector "army" to type1_army (a value or flag or whatever telling which army the instance belongs to)
    >>> set detector "do_damage" to type1_attack_damage
    >>> start loop "test detection_type1" 1 time

    on loop "test detection_type1"
    + detector overlapping "type 1"
    + type1 fixed value <> detector ID
    + type1_army <> detector "army"
    >>> sub do_damage from "health"

  5. #5
    Clicker Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)

    Join Date
    Jan 2016
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Now I think we're on the same page with what I meant, and thank you already for your patience about my rambling writing style.

    I tested your new way to do it, but maybe I still did it wrong somehow. Now none of the minion types attack each other. (That's the other usual end result I get with testing this matter apart from them all killing each other.) Changing the code back makes them again attack each other in free-for-all mode. I made the collision detector visible so I can see that there are attacks recognized, at least.

    You wouldn't know of any example file in any post that would do what you showed above? I think it may well be exactly what I need.

  6. #6
    Clicker Fusion 2.5 DeveloperAndroid Export ModuleHTML5 Export ModuleiOS Export Module
    Fusion 2.5 (Steam)
    schrodinger's Avatar
    Join Date
    Nov 2014
    Posts
    3,155
    Mentioned
    27 Post(s)
    Tagged
    1 Thread(s)
    No, but maybe I can try making one myself later, have to go now but should be back in a while.
    Sometimes there are scoping issues going on, or something else I could have missed..
    will possibly try and make a quick test later!

  7. #7
    Clicker Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)

    Join Date
    Jan 2016
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you do that, I will be really grateful.

    I always hate to ask help from more skilled people, since it means that I can't repay it by giving my own advises in return...

  8. #8
    Clicker Fusion 2.5 DeveloperAndroid Export ModuleHTML5 Export ModuleiOS Export Module
    Fusion 2.5 (Steam)
    schrodinger's Avatar
    Join Date
    Nov 2014
    Posts
    3,155
    Mentioned
    27 Post(s)
    Tagged
    1 Thread(s)
    Back again,
    no worries, making examples is very useful for both,
    and your english does its job pretty well also

    just made a quick test, seems to work?
    (if this is what you need?)

    two_armies_detector.mfa

    You can trigger an attack with spacebar
    you'll see the "detector" area glimpse and objects taking damage will pop out a rotating "damage" counter

    seems like red instances correctly damage blue instances and the other way around.

    Now, a little though on something that could possibly go wrong in your situation:

    "type1" attacking
    >>> count each one of "type1", loop name "attack"

    ^ "type1 attacking" means you are detecting a different "state" for type1,
    like a flag on or an animation playing?

    Be careful because foreach loop are "scoped" already when you launch them,
    so if you say:

    animation attacking is playing >>> count foreach one of...

    you will only cycle among instances who are playing attacking animation

    Don't know if this can be an issue your situation? (possibly not!)

  9. #9
    Clicker Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)

    Join Date
    Jan 2016
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This seems to be just about exactly what I needed. Now the minions seem to attack each other as I was hoping. I even made a test with two bases spawning them constantly and them attacking each other, and it seems to work. The test seems to leave both armies really even, which is a good sign. Also, the attack think will likely not be a concern, since I can change the button activation with any other method and test it, since I know the code otherwise is now working. I can always try to add conditions and events and turn back to the original code if something fails.

    The attack condition may have been my problem, with minions attacking each other unevenly or by counting all instances and causing damage to be dealt to all instances at once.

    Also, maybe I was just looping a mistake with making them either to detect differences or similarities, making:

    type1 type = detector type
    type1 army <> detector army

    the key.

    (I hope and think I'm not as stupid as my spelling makes me sound like, but I have this bad habit of trying to do any changes with as little moves/changes as possible, leaving me trying pretty much almost the same method several times before I actually venture to try an actually different way. Perhaps I just am scared to break the parts that are already working or something.)


    Thank you so much! Sorry for the yelling, but it could have taken me a lot of time to hit this same result with frustrated blind swings, or perhaps fail to make it at all. If I don't hit a wall somewhere else and get this game working, you will get a copy of it.

  10. #10
    Clicker Fusion 2.5 DeveloperAndroid Export ModuleHTML5 Export ModuleiOS Export Module
    Fusion 2.5 (Steam)
    schrodinger's Avatar
    Join Date
    Nov 2014
    Posts
    3,155
    Mentioned
    27 Post(s)
    Tagged
    1 Thread(s)
    Too kind of you, thanks!

    If you hit other walls drop a line

    (+1 making code changes step-by-step is actually a good way to pinpoint issues as they come!
    Wish I did it more in some situation, when I had to rewrite bunch of things from scratch
    just because of my adventurous-testing-not-backuping spirit )

Page 1 of 2 1 2 LastLast

Similar Threads

  1. Replies: 3
    Last Post: 18th May 2015, 07:16 PM
  2. Comet Attack!
    By Mostafa in forum iOS Released Games & Apps
    Replies: 0
    Last Post: 14th February 2014, 08:34 PM
  3. attack on sight?
    By delta9857 in forum The Games Factory 2 - Technical Support
    Replies: 6
    Last Post: 3rd December 2009, 08:53 PM
  4. Making a character attack?
    By delta9857 in forum The Games Factory 2 - Technical Support
    Replies: 4
    Last Post: 8th November 2009, 03:57 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •