Shooting game question

[Squinky]

Howdy folks,

I've done something like this years ago, back in the DOS editor days, but I am looking to have a setup where many enemies enter over and over on a screen, and are destroyed by being shot.
I'd love for them to have hit points as well.
So, do I need to make like 300 characters all with their own stats, or is there some simpler way to go about this?

Thanks for any advice.

[Ryan Timothy B]

I believe with characters you're limited to something around 20-40 on screen at once (unless Crimson has lifted this limit in the newer versions).

The question really depends on the graphical view of the scene. If it was more of an arcade sequence or background animations (behind anything like the Player character, etc) I personally would just go with drawing surfaces and not even use a single AGS character.

[Squinky]

Thanks!

So, you mean like in a shooting gallery set up. I could have zones and change the image and variable to to be "Shootable". Or am I missing more to this concept?

What I am looking for is the classical zombie defense. They enter and walk from the left screen, and a barricade or house is on the right. So they need to move across the screen. Is this doable somehow with Surfaces like you say? Is this a newer AGS feature?

[Ryan Timothy B]

Note: I apologize in advance if you already have a firm grasp of these elements.

AGS's dynamic sprites and drawing surfaces gives you the ability to create your own X by Y sized sprite and then to draw to it or alter it. Imagine it like a canvas in MS Paint. You make the dynamic sprite 100 x 100 pixels. Then you can draw images to it, which would be similar to pasting images to your 100x100 MS Paint canvas. The order you draw the images will be the order they appear; first drawn means it'll be behind all subsequent images drawn.

In this case you'd likely just use the drawing surface on the room background, which allows you to alter the room's background, but I believe only while you're in that room (I may be mistaken on this - I remember that it resets to default background image when you reload the room).

Using drawing surface would mean you'd have to control everything. You'd have to store the X and Y coordinates of each enemy along with their current sprite (or frame, including the view and loop). Then before drawing, you'd have to manually sort the drawing order of these enemies, likely by the Y position.

I don't recommend this route if you aren't a capable programmer because everything would rely on your scripting with a tiny bit of help from AGS.

[Squinky]

Wow, thank you for the response! That looks a little out of my league though.

I wish I could dig my old "AGS shooter" and look at the code, but thats way too old. I just can't remember how I managed the random targets.

[Khris]

I'd actually use characters. I don't think there's a limit to how many characters can appear on screen at the same time.

You need a pool of dummy AGS characters, 20 or 30 or so, whatever you want the limit to be to not overwhelm the player.
Then you'd use a struct to create your 300 character data objects (cda), which store all the info (like alive/dead, hit points, currently active or not).

In your main game loop, if you want to add a zombie, take a free dummy character and assign it the index of a not yet used cda. Then send it on its way. When the character is shot, use the index to find out which cda it represents, and subtract from its hit points. If they die, mark the cda as dead, remove the character, and mark it as free. Rinse, repeat.

To add properties to AGS characters, use a simple array. Say character #1 is the player and you're using characters #2 to #21. Create an array like this:

Code: ags

int cda_index[20];

  // Character c is hit:
  index = cda_index[c.ID - 2];
  cda[index].hp -= 10; // subtract 10 hp from actual character

[Ryan Timothy B]

I don't think there's a limit to how many characters can appear on screen at the same time.

Yes, I'm right. I was way off on my initial guess. It's 75, but that also includes objects.

Error Message:
An internal error has occurred. Please note down the following information.
If the problem persists, post the details on the AGS Technical Forum.
(ACI version 3.21.1115)

Error: Too many sprites have been added to the sprite list. There is a limit of 75 objects and characters being visible at the same time. You may want to reconsider your design since you have over 75 objects/characters visible at once.

[elentgirl]

I'd actually use characters. I don't think there's a limit to how many characters can appear on screen at the same time.

You need a pool of dummy AGS characters, 20 or 30 or so, whatever you want the limit to be to not overwhelm the player.
Then you'd use a struct to create your 300 character data objects (cda), which store all the info (like alive/dead, hit points, currently active or not).

I'd so it the same way as Khris, using characters.  Their movement on screen is easier to control and can include an element of randomness with a little programming.  If you want lots of different looking zombies, then you can create a number of different views and assign a different view to each character before putting it on screen (you would only need to create animations for the direction in which they were walking).  I hope this helps.

[Khris]

Ryan:
That's good to know, it's not in the manual section about System limits though and I never ran into it.

elentgirl:
Yes, and one can easily determine pixel-perfectly which character/zombie was clicked/shot, which is very complicated if not impossible with drawn ones.

[Squinky]

I decided on Characters. Today has me doing some testing and getting re-acquainted with AGS. Here is where I am script wise, cEgo being the Zombie.
// room script file
function room_RepExec()
{
    if (IsTimerExpired(1)) {
   cEgo.ChangeRoom (1, 620, 420);   
  Display("Timer 1 expired");
  Display ("Reset Zombie 1");
}
if (cEgo.Room==1){
   cEgo.FollowCharacter (cChar1);
}

}//Zombie scripts
function cEgo_AnyClick()
{
Display ("Zombie destroyed");
cEgo.StopMoving ();
cEgo.ChangeRoom (2);
SetTimer(1,200);
}

So, I'm sending the character to another room until a timer ends. But I am getting a weird bug:
The character appears for a split second on top of the character it is following before it is reset. Weird huh?

Now, this all may be moot, because on re-evaluation of this issue, I am wondering if instead of resetting the Zombies after they are killed, I would be better suited to have a grunch of zombie characters stabled up, and just call them at the start of each event, and set hit points at that stage. As long as I keep the number under 75 ( no problem) it seems like it may be fine.

So is there a limit of created characters in the editor? Will this route just bog everything down?

Thanks as always for the advice guys. It has helped a ton.

[Andail]

Hi, Squinky!
You can display your code properly by using the [ code=ags ] tag. Also remember indentation!

Code: ags

// room script file
function room_RepExec()
{
  if (IsTimerExpired(1)) {
    cEgo.ChangeRoom (1, 620, 420);    
    Display("Timer 1 expired");
    Display ("Reset Zombie 1");
  }
  if (cEgo.Room==1){
    cEgo.FollowCharacter (cChar1);
  }
}
//Zombie scripts
function cEgo_AnyClick()
{
  Display ("Zombie destroyed");
  cEgo.StopMoving ();
  cEgo.ChangeRoom (2);
  SetTimer(1,200); 
}

I don't know why the zombie jumps on top of the character it's following. Maybe try cEgo.FollowCharacter (null); to cancel the following around while it's disabled. I would also recommend naming the characters better to avoid confusion - like cZombie, cEgo traditionally being the protagonist

[Squinky]

Hey Andail
I tried the old "Spoiler" tags and met up with failure....so thanks for the info. I'm living in the past on most of this stuff. Like all the scripting, it was different when I was digging into it back in the day. But it is so much better I can tell already.
Also, cEgo.FollowCharacter (null) did the trick. Thank you sir!