frame

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register

Cloned enemy behavior

In my game I have an enemy that I have follow me when my player gets close enough and attack when my player is really close. Everything works fine for a single enemy. I want multiple enemies of the same type on my level so I cloned several copies of them but when I play my game enemy behaviors are not consistent; different enemies will do actions that do no coincide with where my player is. For example, I may be close to enemy 1 but enemy 3 will be the one that moves toward me, or enemy 2 will attack even though enemy 1 is close to me. Do cloned objects all share the same values of each number, switch positions, etc?

Or maybe it's a problem with my code. Currently my player will send his position to every enemy object every second. Then in my enemy I have mailboxes with those coordinates that go to a switch, then a point-at, then velocity but the switch is only turned on when in proximity of the player. So while the players coordinates are updated every second, the switch should on turn on to actually let the enemy act on those coordinates when in the proximity of the player.

Comments

  • I know proximity is buggy, but it shouldn't be that off. Post a link and I'll check it out after work if nobody beats me to it.
  • http://www.flowlab.io/game/play/756945
    Thanks, this is driving me a little crazy trying to figure out why the wrong ones are moving.
  • Hey, looks like you used the whole “send coordinates” thing.

    Nice!
  • @CrimsonBlackGames
    Ya, I messed around with extractors before but from what I understand extractors have to be redone for every level and I don't like doing that. I've got a weird compulsion to make everything work all the time rather than redoing it for different levels.
  • What do you mean by "extractors have to be redone for every level"? I definitely have to check out your game tonight because I have no idea why your logic wouldn't carry over to the next level.
  • @Mhx Aîr
    From what I understand whenever you add an extractor you select the type then the object number, when you change levels and add in a previously made player or whatever the object number changes. So you would have to fix every extractor to have the new object number for every level.

    I could be wrong though, I made turrets on another game with extractors and they worked fine on my original level but when I tried to put them on another level they wouldn't ever point to my character.
  • There's your problem. There are a couple solutions to fix this. The first solution would be to have the player stay on every level and then it would always be the same object. Another option would be to have whatever you are extracting actually not extract but rather received a message from the object sending the extracted numbers to the player. You would have the object extract its own x and y then send messages to the player and the player would interpret that, rather than extracting from a distance. You may want to use a proximity as well, since proximity is similar to extract, but again I'm not 100 percent sure what you are doing in your game until I look at it. Another possible solution that I have not tested yet, would be to rename the object instead of having an object number, you would rename all of them the same number, or something like that would maybe work. Like I said, I have not tested this, it's only a theory, I'm not 100 percent sure that would work either. I have a little bit of testing to do, but like I said I'll check it out tonight.
  • I used the send coordinate thing that you mentioned to send my actual coordinates. My player will extract it's own x/y and send them to every enemy. Every enemy will receive coordinates but should only act on them when the player is within proximity of the enemy. Which is where my problems come in, enemies that are no where close to my player are reacting rather than the ones that are close.
  • edited November 21
    That's odd, maybe it's an inverted situation, I'll check if this can be solved by inverting the equation, or using a gate like AND or NOR. Were you using an equation for proximity - extract? Like I said, I can't check your game right now so I'm just imagining the situation.
  • I was using the built in proximity trigger, do you think I should do something like Timer - extract enemy coordinates - compare to player coordinates - if close enough then react?

    In other words, work around the built in proximity trigger and jury rig my own?
  • No, you shouldn't have to. I'm sure there's a simple fix but I just can't see it in front of me right now. I should be heading home in about 2-3 hours, then I'll bugtest it.
  • Ok, thanks!
  • edited November 21
    I can't figure it out. I'm gonna say proximity is shared between clones.
    @grazer I can't figure out why these objects are activating from each other's proximity check. Is it bugged? Do they all share proximity? Maybe this is why my proximity black hole gravity was always so broken. I even tried this method http://flowlab.io/game/view/2111?v=2, but the issue is one enemy's proximity is turning on the switches for all the enemies. I'm definitely thinking it's a bug. Hope grazer can confirm.
  • @Mhx Aîr

    I think that’s actually incorrect. When you play and look at the behaviors simultaneously- it’s a little confusing. Because when a switch turns on for a clone- it looks like they all turn on. They don’t- or that’s what I think the case is.
  • If you were to have an enemy outside of the prox fire a signal into a switch, it would turn it off- because that’s what that specific clone has....

    I may be incorrect though, but that’s what I gathered over the years.
  • I've gone back through again and changed enemy behaviors to not use proximity triggers and now my behaviors work. I'm still having my player send out the coordinates but then they get sent into a big compare filter that checks the (x,y) of the player compared to the enemy and moves the enemy if it is close enough.

    I'm still not sure if the proximity trigger is broken or I am just misunderstanding it, but at least my enemies work now.
  • I told grazer about that bug and he said he couldn't reproduce it and it was really weird. I haven't had any time this week for flowlab, but tomorrow I finally get a day off work, so I can make a bugtest for proximity.
  • https://flowlab.io/game/play/767354

    I made an example game to demonstrate the glitch.
  • I'm making lots of assumptions here, but I almost wonder if when the proximity trigger happens, whichever enemy the game engine happens to be checking takes over that trigger instead of the one that is actually closest to the player.

    OR I'm just bad at programming/understanding the relationships between the objects and triggers.
  • I've had issues with proximity for years, that and emit. Every time they get fixed, eventually a new bug happens. That's how it works, though. You fix all the important bugs, and choose to ignore small bugs that aren't a huge issue.
  • hey @zgaulke - you definitely found a bug, and I have been trying to reproduce it myself with no success. This simple test you made will be a huge help in tracking it down, thanks!
  • Thanks for making that for grazer. I can't seem to get two hours to work on my game. Just two days ago my car battery died, and now my check engine light is on. I can't get a break and the stress makes me lose sleep. I do however really want to make a proximity bugtest for several different tests. One of them is xy check. For SOME odd reason, even after I kill an enemy, the coordinates for homing attack stay on the empty space, even when I get within proximity to another enemy. I assume the clone bug you found is related. I made an auto targeting example and I attempted homing attack in a logic tester, but maybe I just am missing something obvious. I'll look over your example and mine when I have a chance, so grazer can look into any other proximity bugs.
  • Hey guys, thanks for helping me track this down. Turns out there was a problem with the repeat delay that made the targets get confused. I just deployed an update, so it should be good to go now. Sorry for the hassle, but I'm glad that's fixed.
  • Thanks, that will make the game I'm working on much easier now.
Sign In or Register to comment.

flowlab.io

| make games in your browser
@ 2017 Flowlab.io, All rights reserved.

Contact us

Get In Touch