Current Android game status updates
Jun. 3rd, 2013 02:09 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
carlfoxmartenWell, it's been a while since I used this journal to post about the status of my Android games, so it's probably about time now.
I have two of these on the go right now.
The first is called “Dig Site&rdqou; and is a connect-three matching game where you slide the lines of objects around instead of swapping them.
The second doesn't really have a name just yet, so the working title is “Electrical Connections’. In this one, you work against the computer, trying to connect two electrical bars to each other by putting smaller bars between posts, while the computer tries to block you after each of your moves.
Dig Site work has stalled due to the extremely high amount of graphical code that needs to get massaged to have things working well.
Currently, it's playable, automatically stores your game, has four levels of difficulty, and needs far better graphics than it has right now.
Electrical Connections is currently only a Java prototype, but has passable graphics (for a prototype) and will detect when the current game is over, who won, and will start a new one on the next mouse click.
Currently I'm somewhat stuck on the computer's AI algorithm.
The game has to choose the best place to put a blocking piece based on the grid as it stands after each move the player makes.
This is in no way a trivial operation, as I have to take into account both the best move the player can make as well as the best move the computer can make.
If the best plan of action the computer can make requires more moves to complete than the player's best plan of action, then the computer needs to block the player's next perceived move instead of its own best move.
Despite the fact that I was able to articulate the above, it still hasn't gelled in my head in such a way that I can put it in code.
I think I need more time in front of a whiteboard so I can closely examine what makes this algorithm tick and how it needs to work.
This is particularly important due to the fact that it's this algorithm that will make or break the entire game.
It won't matter if the graphics are awesome, the sound effects perfect, and the music (if any) fit together well.
If the algorithm is too hard or too easy, the game won't be much fun.
I have two of these on the go right now.
The first is called “Dig Site&rdqou; and is a connect-three matching game where you slide the lines of objects around instead of swapping them.
The second doesn't really have a name just yet, so the working title is “Electrical Connections’. In this one, you work against the computer, trying to connect two electrical bars to each other by putting smaller bars between posts, while the computer tries to block you after each of your moves.
Dig Site work has stalled due to the extremely high amount of graphical code that needs to get massaged to have things working well.
Currently, it's playable, automatically stores your game, has four levels of difficulty, and needs far better graphics than it has right now.
Electrical Connections is currently only a Java prototype, but has passable graphics (for a prototype) and will detect when the current game is over, who won, and will start a new one on the next mouse click.
Currently I'm somewhat stuck on the computer's AI algorithm.
The game has to choose the best place to put a blocking piece based on the grid as it stands after each move the player makes.
This is in no way a trivial operation, as I have to take into account both the best move the player can make as well as the best move the computer can make.
If the best plan of action the computer can make requires more moves to complete than the player's best plan of action, then the computer needs to block the player's next perceived move instead of its own best move.
Despite the fact that I was able to articulate the above, it still hasn't gelled in my head in such a way that I can put it in code.
I think I need more time in front of a whiteboard so I can closely examine what makes this algorithm tick and how it needs to work.
This is particularly important due to the fact that it's this algorithm that will make or break the entire game.
It won't matter if the graphics are awesome, the sound effects perfect, and the music (if any) fit together well.
If the algorithm is too hard or too easy, the game won't be much fun.
no subject
Date: 2013-06-08 10:50 am (UTC)In actual speech I do say it moderately often, especially when I'm trying convey something to the person I'm talking to.
When writing, however, I don't use it quite as often.
Yeah, writing code is far more difficult that non-coders comprehend.
Once it's done, they have no concept of how much work went into it.
“Oh, it looks cool!”...
And I'm thinking, ten thousand lines of code and counting, and it's got five more features to add and thirty known bugs that could cause problems. =>.<=