Enemy Platform Behavior Questions

I've spent quite a few hours looking through the forums and tutorials tonight, but I haven't been able to wrap my head around these 2 issues:

1) As a side-scrolling platform game, how would you have the enemy shoot at you when you are above or below them on a different platform (and detect that you are)? I'm looking for something realistic, where they are actually visibly aiming at you in the proper direction as they fire.

2) How do you spawn multiple enemies of the same type, but have them act out the same enemy type events independently? (attack at different times, die, detect player, etc.).

The examples I have found had all enemies performing the same actions at once, or they had independent events for each instance of a monster; both solutions will not work for my situation.

My skills are fairly amateur, if you can help me out with a capx file; that would be amazing. Thanks!

Some general thoughts:

Making generalized "A.I." is not a good idea. That's why "A.I." is done in most cases at the end of game production cycle. At least not before you know some specific things about your game world. You can't solve (compute) problem-situation if you don't know anything about it (no input). With all of your major game word elements known, you can make number of "hacks" - cheating to make enemies look intelligent - it doesn't matter if enemies are intelligent or not, as long as they look smart (that is player doesn't notice cheating) - in games it is all about surface (designers of A.I. for Halo noticed that during playtesting faze making enemies little bit harder -more hit points to kill them - cause playtesters to perceive them as smarter). There is lots of little cosmetic things that you can do to make enemies look more "intelligent" (provide the

player with some visual/auditory clues as to what the agent is ?thinking? about: different animation of enemies when player enter enemies' FOV and some audio information- "Aha!", "There you are" - when it exit - "Where is gone"...)

Unknowns:

1) How would you move your enemies - platform movement can be done in many ways in C2( physic, platform, and custom behavior, or even via events). And how would enemy perceive game world (visual and/or audio).

   2) Previous determines possible ways of how would you calculate desired trajectories to satisfy the

        3) Goal - Search, Follow, Attack, Hide... Don't make enemies react instant on single parameter - if Value A then action A. Make group of conditions for single goal - Attack: is in FOV, is in Fire.Range, is Enemy.Energie greater... than on Goal.Atack: move, shoot...And this requires

             4) Logic for switching from one state/goal to another.

oh... i carried away

Your problems:

Question 1

For basic AI "vision senses" you need distance form player, angle(Player, Enemy),is in angle(Player,Enemy) range, and is line between player and enemy overlapping obstacle

Look at this examples:

A) http://www.scirra.com/forum/c2enemy-line-of-sight_topic45095.html

http://www.scirra.com/forum/enemy-ai-los-line-of-sight-engine-c2_topic46730.html

B)http://www.scirra.com/forum/turrets_topic49010.html

Examples A will tell you if is player inside of enemies in line of sight, and example B will tell you how to make "realistic" cone of view. Try to understand them and combine them.

Suggestion: If player is in enemies FOV for short period and then exit it, you can create object LastPosition on that place and make enemy go to LastPosition (otherwise enemy would act as he dont care for Player unles Player is in FOV). You can make some private variables in Enemy - LastPositionX, LastPositionY (when Player leaves FOV set them to Player.X, Player.Y). You can even store Players VelocityX, VelocityY, and Speed at point of exiting enemies FOV and predict possible new position after second or so, and than spawn another object there and tell enemy to go and look is it player there or not. This is all pretty simple but you can get with it decent enemy behavior.

Question 2

It is not clear to me what you exactly think. Do you think intstances of same type (Sprite) - instances dont react all at same time unless you tell them to do so. If you specify conditions for actions and include "for each", then only instance that satisfy those conditions would be picked and perform those actions.

Or you want to make Global.Enemy type object (one logic for all enemies) and then send to him specifics of each type ("different attack times, die, detect player"). For this you need families and families behaviors implemented. Wait and learn what is there.

Thanks for the links.

I intentionally left my post vague, it was not due to lack of knowledge of the basic fundamentals of game design or theory. I did not want to sway my general inquiry by focusing the answers around specific details. I'm strictly prototyping at the moment, I'm not looking for polish. I should have specified that.

As a bit of background, I've actually worked on about two dozen games over the last 6 years, from a design/production standpoint. I'm well aware of the flow of implementing AI into a conventional game. It might surprise you to know that our AI programmers almost never actually launched the game or level environments. Most of their code work was performed in a simple cube environment with very few static meshes. I've never seen AI done at the end of a games lifecycle; although, I imagine each studio has their own approach. I'm only speaking from the perspective of 4 studios I've been involved with.

Minor tweaks to fake intelligence happen throughout the project, it's largely trial and error. You don't implement AI at the end of a project, it is the most time consuming aspect of most projects. You want your design and test team working with functional AI behaviour from the earliest point you can establish. In fact, most of the level design workflow was designed around the functionality of the AI; not the other way around.

I have to emphatically disagree with that Halo example. Making your enemies take more damage will end up making your enemies look dumb, not smarter. It is a horrible attempt to cover up how inadequate your AI is at self-preservation. Smarter AI should be able to survive in scenarios where they could die with a single shot. You should see games like Stalker or Killzone 2 (on hard difficulties), especially their tech demos. Another indicator of covering up bad AI is when you have different enemy types who have limited behaviour; instead of giving AI that can intelligently transfer between multiple behaviours. Quantity doesn't make up for lack of quality.

Most of the rules of traditional games fly out the window in a simplistic platformer, when you are limited to 100 events (I'm evaluating the engine for a personal project). A key reason why I never once used the word AI in my post, was because I'm not concerned with making them appear intelligent at the moment. I hope this post helps clear things up. I'm well aware of the direction of my intended project and have fleshed out exactly how I want my enemies to react in almost absurd detail; most of which is fairly out of the scope for my prototyping.

1) I was more concerned with how you would physically handle the act of having your enemies fire upwards or downwards. Would you pin their torso/arm and have them automatically face towards the player? Is a better solution to have animations for each enemy where they face upwards or downwards? My question was more centered around handling the sprite, not so much the reasoning behind why they are facing the user. Although, I'd gladly take advice behind engine tips for that as well.

2) As for the second question, the "for each" answer was what I was looking to find out about. I didn't know the engine had the ability to specify it that easily.

Thanks again!

I was mislead by "realistic" "visibility" "detection", and when I think of some kind of "A.I." in CC or C2 I don't go beyond simple FSM (that is Quake 2 - single player enemies not bots-, pre 2000 - where in action games AI is something you devote smallest part of production time), but I didn't said is always done at the end, I said that you must know some basic elements of your game world (which you didn't specify and I was thinking that you want to make AI) - that's why "Most of their code work was performed in a simple cube environment with very few static meshes", knowing what inputs they can get and how game logic functions. I leave discussion about A.I. alone.

For realistic aiming I think is better to have separate body parts - legs (animated), torso, hands and head attached and controlled via events depending of angle between target and enemy and/or some other conditions.

There is Lucid's (forum member) amazing tool Spriter, he may implement in Spriter procedural animation - which can be controlled via events, like in this example he made in CC:

try beta: http://brashmonkey.com/

see possible future features: http://www.kickstarter.com/projects/539087245/spriter?ref=live

edit: one more thing I didn't say about question 2. If you use private variable for (attack time, die...) each instance would behave on their on - update according to its actual state (of energie, position...)

Here is one possible way to do what you want...It is character from game Abuse(legs and torso animation), and I made it as Player character but you can figure out from here how to make it enemy (instead of sight it would be player)...also image point from which bullet spawns is not correct....

capx

Thanks for the direction, it definitely will help.

i would like too add something to moving enemies individually. however please keep in mind that i am very new to coding in general and I've never actually stepped outside of construct 2. I'm sure you have a lot more knowledge then me in anything however I've taught myself my own ways around problems and i use this specific solution in almost all of my games in some way or another.

i tend to get around having my enemies all the same coding with statements like "if enemy is withing distance of player then aim and shoot" that way all of my enemies will have the same coding but only the ones that are close (in this example) will shoot.

then i add onto this with instance variables. the enemy might have a "range" variable, which i might set to 200 and then only when the player is under 200 pixels away, will it work. that way i can change specifics between the same objects such as one having a range of 200 and another having a range of 300.

there's also the type of logic like "if a bullet is overlapping enemy, destroy enemy" and although this is a broad statement that targets all sprites named "enemy" it will only target the one sprite that the bullet is overlapping.

now if you want random movements from the same enemy type it would be easiest to set up its movement AI with space for a variable such as speed or direction. so you could say something like "on object created choose initial direction: random(left,right)" of course you would use the actual words left right. a more accurate statement could be:

on object created choose enemy.direction: choose(0,1)

if enemy.direction = 0

enemy simulate control: left

if enemy direction = 1

enemy simulate control: right

[and then although this sets the initial direction, if you run into a wall you could just say]

enemy on collision with wall: add 1 to enemy.direction

if enemy.direction is > 1: set enemy.direction to 0

[this just makes a simple toggle]

I'm positive that this isn't the best way to do things like this (again, not a professional game dev) however I've definitely found good use out of things like this especially because it really helps reduce the amount of lines used in coding which is important with that 100 line cap forever looming overhead.

I'm sure you already knew a lot of these things but maybe you never knew you could do them specifically in construct 2, so things to look out for are the instance variables found in each sprite above the behaviors, and things such as "random(smallest number, largest number)" which will pick a number in between those values and "choose(1,2,3,4,5,etc.)" which will choose one of the specified options