Using tables to keep track of enemies alive: stuck on part of the logic?

mhedges

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.

1. 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.
2. 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.
3. 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).
4. 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.
5. 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.

ThoPel

BTW: I've never built such a game.

But for me, does the logic sound good.

@mhedges said:
EDIT: I believe that the problem is that the enemy needs to read it value in the table before actually firing or getting destroyed.

Where is here your problem?

I would create an "initialized ruleset", where before initializing all parameters are read from the table.

mhedges

Bump - any ideas before I start rewriting everything? Sorry for the trouble, regards.

mhedges

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:

1. Search the table for the row which has the cell value of the Alien Number.
2. Obtain the index number of that row (if it's the first kill, then the index will be the same as the cell value of the aline number, but if I've already killed another alien, then the index number may be different from the cell value of the alien number).
3. Remove that row.

So how do I perform #1 and #2? I know that the behavior for #3 is Remove Row.

Thanks, regards.

Armelline

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

Hopscotch

@mhedges

1# use tableSearch
2# tableSearch gives you the index number

But I want to see @Armelline 's solution.

mhedges

@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.

Hopscotch

I still want to see @Armelline 's solution!

Socks

@Armelline said:
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

[Waits for Armelline's demo, plans to release it as is]

mhedges

Certainly! It should prove interesting if another approach is feasible.

Hopscotch

No pressure @Armelline, nooo pressure.

Armelline

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.

Hopscotch

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!

Armelline

@Hopscotch said:
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

Hopscotch

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

mhedges

@Hopscotch said:
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.

RThurman

@Armelline -- nice solution!

Hopscotch

@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.