Game logic: self perpetuation
I am writing a simple game called 'Bombs'. Each player clicks on a 6 x 7 grid to add a bomb. When a square reaches its maximum it explodes and only adjacent squares increment a bomb. Such that corner squares max is two, the edge squares (other than corners) are three and the central ones are four. Once a square reaches its maximum that square's bomb count is zeroed. Eventually the program enters self perpetuation.
I have made a recursive internal stack arrray with a pointer and have had to set upper bounds of the aray well into the hundreds (999). Being that the number of total bombs keeps going, up I can't think of a way to prevent this self perpetuation.
Do you agree with this logic?
Cadman
Re: Game logic: self perpetuation
I'm vaguely aware of that game, and it seems to be the same as this one.
I just had a quick play and can see the issue of self perpetuation.. but also noticed that there is a very definite limit to it - the amount of squares that are currently 'exploding' can only ever go up to the total number of squares, which in your case is 6*7 = 42
There is however the issue that you need to keep track of how many extra bombs there are per square that is currently waiting its turn to explode (assuming that the neighbouring squares have exploded during this round), and then explode with that extra amount when the time comes. The game I linked to does that by keeping the extra amount in the square - and if needed exploding again afterwards.
Re: Game logic: self perpetuation
Yes, that link is quite a similar game. (I only played it a short time) I don't agree that the number of explosions can only be the number of squares X x Y because the number of bombs is never reduced, they simply jump to adjacent squares. What I can do is if a square blows up do not allow any new bombs into it until the recursion stops. I wrote this game in character mode (25 x 80) in the mid 80's and that may be what I had done then. That should definately reduce the total number of bombs.
As to more bombs than the max, I limit (also for graphic reasons) the max ie: if bombs added>max bombs then = max bombs.
You know, that is what is great about feed back like yours. It helps to bounce ideas around (and remember some old ones) to solve a problem. I'm going to force exploded squares to stay empty until the recursion ends.
Thanks, Si
Cadman
Re: Game logic: self perpetuation
The number of explosions can get very high, but the number of squares that need to explode can only ever go up to the number of squares.
For example, imagine this is the top corner of the board, and a bomb is placed on the highlighted square:
Code:
1 2 ..
2 3 ..
.. .. ..
- That square will then have too many bombs, and thus explode (currently one square).
- When it explodes (assuming your explosions are the same as the link), the one below it and the one to the right will then have too many, and thus explode (currently two squares).
At this point we have differing opinions.. I think the link has it correct, and lets those squares explode back into the first square (and as there are now two bombs in it, it will explode again later in this cycle).
As to the number of bombs, I don't see the need to limit it (but I could be missing something, as the game I linked to only gives you a certain number of turns). The way I see it, once all squares are at their maximum (or even before), the entire board will be taken over by one of the players - and the other player will not be able to take another turn, so the game is won.
Re: Game logic: self perpetuation
OK, I played that flash game a little longer this time. One diff, in mine you can steal the other's square (adding 1) if it is not their last plaement. I assume that the numbers in your example grid are the current number of bombs. If I understand your logic of allowing an exploded square to reclaim bombs from adjacent squares and explode again you never really get rid of any bombs and the sequence could go on for quite some time. In my game, possibly due to my explode ordering, which is ascending ie: '040612' it may cause it to replay the same xx squares over and over again as I have experienced in my code testing.
ExpOrder(1) = "0208" (Had to use 2 digits to get to 42)
ExpOrder(2) = "010309"
ExpOrder(3) = "020410"
ExpOrder(4) = "030511"
ExpOrder(5) = "040612".... to ExpOrder(42)
I have changed the code to disallow exploding more than once in any recursion sequence by setting a boolean and that has considerably reduced the number of explosions due to reducing the total bomb count. I have added AI to allow the computer to play. Man, a FOR 1 to 10 loop random looking for a max-1 square or a random choice (except cannot pick my last pick) and it is hard to beat! With this technique I believe I don't need a stack larger than 42.
Cadman
Re: Game logic: self perpetuation
My next step is to add a short explosion sound (API) and keep a running tally of games won.
I have done lots of little easy games in VB. They're not much in graphics but mostly the classic ones like pong, breakout, snake, etc. I did one from the old TI99-4A 'Wumpus' that plays well and requires a little thought to locate the wumpus (blood spots wrap the grid). I made my own deck of cards for draw poker, found a bug in the shuffle routine but I think I lost my source code, DANG!
Cadman
Re: Game logic: self perpetuation
Quote:
Originally Posted by CADman
One diff, in mine you can steal the other's square (adding 1) if it is not their last plaement.
I can see how that would change the gameplay, but in terms of code it seems like it would really only change how the game is won or lost - assuming you have different conditions for it (the flash game ends after a certain number of turns [which I don't like much], or when one of the players has no squares left).
