Using tables to keep track of enemies alive: stuck on part of the logic?
Hello -
I've been tinkering around with the Alien Conquerors template, messing with the actors' movements and behaviors. That got me to think about how the enemies fire back at the player.
The easy solution would be to simply have a timer that would, every second, have a random actor (say, from 1 to 32) fire. But what if you've killed 17 aliens? That could be a long time between enemy shots if the randomizer keeps picking the dead ones.
I thought it would be more logical to have a table keep track of the live enemies, but I'm stuck on certain items.
- I have to create a table for x amount of characters. Let's use 32. One column, 32 rows, in each cell the value will be from 1 to 32.
- I have to have an event handler actor pick a random number from 1 to "tableRowCount", as a row will be eliminated when an enemy is killed.
- I have to read the tableCellValue from the row, which will not necessarily be the same as the row number. If I kill enemy #17, then there will be 31 rows left, but row #17 will now have as tableCellValue 18 (the next surviving enemy in the table).
- I have to create a rule within each enemy actor so that when the chosen tableCellValue is equal to its self-value (unique identifier), then that actor fires a bullet.
- I have to create a rule within each enemy actor that when it is hit by a bullet, it must be destroyed, but it must also eliminate its corresponding row in the table based on its value, not its row number (see #3 above).
I believe I am missing something related to the enemy itself, but at this moment am uncertain what it is - read the updated table? Other? Any ideas?
EDIT: I believe that the problem is that the enemy needs to read it value in the table before actually firing or getting destroyed. This is where I am stuck.
Comments
BTW: I've never built such a game.
But for me, does the logic sound good.
Where is here your problem?
I would create an "initialized ruleset", where before initializing all parameters are read from the table.
Bump - any ideas before I start rewriting everything? Sorry for the trouble, regards.
Wait a minute, I just thought of the following:
Going back to alien #17 above, let's say I hit it with my laser. Here's what I think must be done:
So how do I perform #1 and #2? I know that the behavior for #3 is Remove Row.
Thanks, regards.
You don't need tables for this. Give me a sec and I'll whip up a demo. I can't promise it'll be more efficient than using tables, but it'll be more interesting
@mhedges
1# use tableSearch
2# tableSearch gives you the index number
But I want to see @Armelline 's solution.
@Armelline, @Hopscotch,
tableSearch it was! Working like a champ now. Thanks for the input nonetheless.
BTW - there's a tutorial from @Braydon_SFX somewhere which helped me with the tableSearch syntax.
I still want to see @Armelline 's solution!
[Waits for Armelline's demo, plans to release it as is]
Certainly! It should prove interesting if another approach is feasible.
Here you go.
I tried something with the commenting but I think it ultimately didn't work. (The thing I tried with the commenting, that is. The demo works fine.)
It won't fire when there's only 1 actor left but that's easily enough accounted for, I just couldn't be bothered.
You can also make the logic easier to follow if you're willing to add a couple of extra attributes, but I'm a glutton for punishment.
Edit: Only after posting do I notice the bullet fire from over the aliens not under. They, erm, have cannons mounted on top. Yeah, that's what it is.
That is cheating @Armelline!
Skipping out of hard work by taking the easy route of programming swarm awareness into the enemies! I call foul!
Nice Demo by the way!
I don't like tables very much
Well, you are doing with the enemies exactly what I would have done in a table, since I don't like to remove rows during gameplay. @Armelline
The rows are being removed from a table copy; at the end of the wave, the original table gets copied (again), and a new wave begins.
@Armelline -- nice solution!
@mhedges, sure, I am aware of that.
Don't put too much weight on my statement of not liking the removal of rows during gameplay. If there are ways of achieving the same effect, then I do prefer not to mess about with things that can cause memory reshuffling due to expanding or decreasing rows. That said, in 99% of all implementations it is just fine removing rows and will not have any detrimental effect on performance.