| Posted By
KiCHY
on 2014-09-23
04:52:24
|  Manage tons of enemies theoretically
Hi There,
I'm just thinking on a theoretical problem and its solution. Assume there is a 8-way scrolling game and there are tons of enemies, chasing you or patroling in an area. As the number of enemies raises, the game will unable to handle all the enemies in one frame. Drawing of only visible enemies is fundamental, but have to move the offscreen ones as well. What kind of strategy would you choose? I had some ideas in mind:
- Handle all enemies at all costs, resulting a framerate drop when the code has to draw lots of enemies to the screen. (Like Commando on C64, serious slowdowns in gameplay and in music)
- Try to manage the number of enemies. When a new moster wants to spawn, try to dispose another one which is - for example - offscreen and furthest from the player.
- Don't handle all the enemies in a single frame, only a portion of them (as much as possible in one frame), then the remained in the next frame. This way the game speed is fixed but the enemies will be slower and slower (like ghosts of Gauntlet).
Any other ideas?
|
|
Posted By
Luca
on 2014-09-23
05:12:50
 | Re: Manage tons of enemies theoretically
Must ALL the enemies chase you in the same time? Otherwise I think a good choice is to use an extended area: the moving ones might be all the visible enemies, plus considering the enemies that are present "next to visible area". You decide how far 'next' will be, in other words how much extended would be the additional border to the considered visible area. All the others don't move.
|
|
Posted By
MIK
on 2014-09-23
07:15:55
 | Re: Manage tons of enemies theoretically
I'm not a coder so I can't be taken seriously haha! 
All commando clones are fixed in some way or another to the amount of AI that can be displayed at any given time. The more AI you add the more retarded some games become... which is the normal rule such as Rambo which uses random placement code to make the AI which is for the most part dumb. However this is always fixed to a maximum amount of bad guys that can be displayed at any given time.
Ikari Warriors C64 is all setpiece sequences triggered by markers in the landscape as you walk up the screen which in turn are told to fire in your direction randomly. It also uses what I would call Magnet Code... While the timing of actual shots being fired towards you from the AI is totally random and will only fire when told too, no matter where you are standing they will ways fire towards you like a magnet.
Ikari Warriors C64 uses tricks to add more to the screen that what you think is going on like a line of 6 bad guys are in fact one unit that move together so are not individual enemies until they are standing still. From the standing still mode they turn into nothing more than gun turrets that fire at random.
Don't forget Ikari Warriors C64 also makes current enemies run off the screen when it needs to trigger more setpiece sequences to come into play, limiting at any given time the amount that's really going on. When you start stripping down Ikari Warrors C64 to the bare bones it sounds cheap and very orchestrated, but because it's been so well thought out and timed to perfection type thing it actually makes an awesome game as the end result. I rate C64 Ikari Warriors as the best version ever created, best commando type game of all time ever, better than the arcade machine that goes by the same name too! 
And as Luca said you can make the game area/window smaller to speed things up.
In a nut shell you can do all sorts of tricks to make something seam like more than what it really is while freeing up CPU cycles per second. Moving a team of bad guys as one unit is a good way to make people believe there is more going on... With that in mind, the actual firing that's really going on per second is less that you might think in a Commando clone any way. It's all clever stuff, even a Nintendo Game & Watch can catch you out when they speed up, sort of suggesting it's not how much but what you do with it that counts.
One last thought...
If you put some of the above idea's into the game Lemmings you can sort of understand how they did it, blocks of guys as one unit walking along back and forth. The CPU is then governed by how many units it can process instead of processing 30 Lemmings individually, a human can't control 30 Lemmings per second with activities on an individual bases.
|
|
Posted By
Luca
on 2014-09-23
07:16:47
| Re: Manage tons of enemies theoretically
Waitwaitwait MIK, I didn't say that  The displayed area is not the extended area: the former is the real size where the game moves, the latter is the area the code considers in order to update the enemies'movement. As I suggested, the code would update all the enemies in the extended area (which is: displayed area + an imaginary, undisplayed yet, added slice where enemies are involved tho and from where they can enter the action of the displayed area).
|
|
Posted By
MIK
on 2014-09-23
07:29:34
| Re: Manage tons of enemies theoretically
It sort of came across that game window could be smaller, that was what I was thinking before I posted any way.
|
|
Posted By
KiCHY
on 2014-09-23
07:33:23
| Re: Manage tons of enemies theoretically
Perhaps I confused you, I try to ask other way
I think the main concern is the limited resources of drawing that lots of enemies. We can deal with the offscreen ones (process only the visible and "almost" visible enemies or making groups and handle them as one). The player moves left chased by 8 monsters, and 4 more enemies awaits him/her. There are no 8+4 sprites to display them, no more rastertime to render on bitmap, not enough rastertime to scroll the gamearea when so much monsters have to draw, etc.
So, the question is: what kind of solutions are possible to avoid this situation? Or, do we need to avoid it, let the game slow down to draw all the monsters??
I'd prefer limiting the number of visible monsters somehow.
|
|
Posted By
Luca
on 2014-09-23
07:46:33
| Re: Manage tons of enemies theoretically
Does it mean you're managing more slots for sprites that can be on screen in the same time than you can manage in a frame? Mh, if so, the problem comes from the very beginning of the game design... :/
I remember XeO3, where of course enemies were time distant because you have 10 sprites slots, and attack waves should have been calibrated in order to not being more than that. Walkers on the floor would have been the next step we had to face, and probably if a Walker would enter the game, be sure the next attack wave would be lacking of one sprite by design
So, limiting the visible monsters looks like the best choice to me too.
|
|
Posted By
Epy
on 2014-09-23
07:53:17
| Re: Manage tons of enemies theoretically
I have never made a game at all. What about if you skip every second frame? So you will have 25 frame per second. Or is this a stupid question?
|
|
Posted By
SVS
on 2014-09-23
08:05:17
 | Re: Manage tons of enemies theoretically
You can manage the movements. I mean, assuming that the sprites move one pixel a time, the monsters near the objective (you) can move 1 pixel a time, but the far monsters are updated once every 2 (or 3) steps.
Then you can have a "near zone", where monsters' movement is fine (having more resolution), and the rest of the screen with a movement (sprites updates) a bit more raw. Note that this doesn't mean that sprites near seem slower than sprites far.
In this way you could skip the all-sprites updating 1 time every 2 (or 2 every 3) gaining processing time.
|
|
Posted By
KiCHY
on 2014-09-23
08:12:06
| Re: Manage tons of enemies theoretically
Not a stupid Q at all. Usually this is the first idea from non-programmers. Halving the framerate doubles the number of visible monsters, but doesn't eliminate the problem. There always will be a chance that there will be too many monsters to draw in given time, if you doesn't limit them somehow.
Next question is how to limit the number of visible monsters?
" When a new moster wants to spawn, try to dispose another one which is - for example - offscreen and furthest from the player"? Any other clever ways? There are no fixed paths, no "come in, chase, go away" monsters. They just want to catch you and overhelm with their numbers.
Edit:
@SVS: Lowering the processing priority of distant & not visible monsters (updating their AI in every 2nd or 3rd frame) is also a clever way to save more cpu to display more monsters :)
|
|
Posted By
MIK
on 2014-09-23
08:35:13
| Re: Manage tons of enemies theoretically
I have already said but I'll put it another way.
Think of Gauntlet as nothing more than a multidirectional Space Invaders. You can only ever shoot the enemies in front.
If you have 8 Ghosts chasing you in Gauntlet along a corridor 2 wide, not only are they running on Magnet Code to save processing time but there are only 3 units in total being processed. What's behind the front 2 Ghosts is a unit of 6 being controlled as one in the code.
As soon as a front Ghost is hit one behind takes it's place...
What really happens is that Ghost you just shot pops back up in to play and then the unit is displayed as a team of 5 behind, they can't go any where until the front one's have been shot. It must be quicker to display a unit of 5 Ghosts on screen than it is to make one disappear to then have the remaining Ghosts have minds of there own from that...
I'm sure if you play Gauntlet on C64 it plays out just like I said. Only a handful of Ghosts are ever fully controlled to make contact with the player, the rest following are a unit. In big open spaces all Ghosts turn into a pyramid that follows you with 1 Ghost at the head of the pyramid chasing. While it may look like the whole screen is chasing you it's nothing more than a V shape formation and only the Ghosts in the front of the V shape can be hit. As soon as one Ghost is hit, the animation of that Ghosts disappears but then it redraws it's self only updating the unit sat behind the V shape to display 1 less. The process repeats until all are gone. It's all maths.
EDIT: If you need to see an example of Gauntlet on Plus/4 take a look at the game Spore.
|
|
Posted By
George
on 2014-09-23
15:44:12
 | Re: Manage tons of enemies theoretically
Just a thought...
if you don't have enough time to process 8 +4 enemies per frame, why don't you separete them into groups you can handle? Or move them groupwise, perhaps including a random value for every Bitmap in the array.
|
|
Posted By
MMS
on 2014-09-23
20:00:34
 | Re: Manage tons of enemies theoretically
Limit the enemy moving X position to fit within one byte (0-255 pixels), and design your game around that.
So you may save a lot of processing power calculating the position, hit rate, moving table, etc. especially if you have 8 or 10 enemies, it may make the difference when you have CPU limit.
Maybe that's why Spectrum enemies are always so fast? (256x192 resolution)
|
|
Posted By
MIK
on 2014-09-23
23:55:48
| Re: Manage tons of enemies theoretically
Yeah, Wec Le Mans on Spectrum is AWESOME!
They tried the Spectrum way with Chase HQ on C64 and while it looks sweet, it's slow as hell. Real shame, love that style of driving games on Spectrum.
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
