Current Android game status updates

[carlfoxmarten]

Well, 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.

Comments

[thefoxaroo.livejournal.com]

The algorithm for Electrical Connections sounds as difficult as programming a game of chess. I earnestly hope you succeed at both games, as they sound very promising.

Back when I was writing my own graphics-based games they were as simple as possible, not just due to the limits of my skills but the limits of a TI994/A running on interpreter BASIC. I'm surprised at what I was able to achieve now I look back. I had a platform jumper based on a single level of Donkey (Level 3), a vertical scrolling car game where you had to stay on the road, my own version of Load Runner with a very slow regeneration rate for the bricks, and my version of Tutankham which consisted of a fixed screen maze per level, and a single monster that each turn would try to move toward you if it wasn't blocked by a wall.

Not surprisingly I worked on text games far more often.

[carlfoxmarten]

Huh. Thought I'd replied to this already.
Must have been the network going up and down like a rubber ball.

Either that or the stress imparted by doing some more work for the door-to-door property care company I'd been working for a while ago.
(today, Friday, is going to be my last day with them. It's too much of the wrong kind of work for me)

It's actually quite a lot simpler than a chess algorithm, as it doesn't have to look after up to sixteen pieces per player with six different movement strategies.
(no, I haven't tried writing one. Not interested in the game enough to be bothered)

Unfortunately, it's going to take a fair bit of effort to wrap my brain around the problem, as it's going to take a somewhat complicated Shortest-Path algorithm that takes more than one metric into consideration.
And that only fills in values to help with the decision-making process!

You can see that it's not an easy thing to design, eh?

[thefoxaroo.livejournal.com]

carlfoxmarten said:"Huh. Thought I'd replied to this already.
Must have been the network going up and down like a rubber ball."

Been there myself, and you always worry about double posting by accident. I know.

carlfoxmarten said:"Either that or the stress imparted by doing some more work for the door-to-door property care company I'd been working for a while ago.
(today, Friday, is going to be my last day with them. It's too much of the wrong kind of work for me)"

When I was unemployed (which may be any day again now given how little activity there is at the office) one out of every three prospective employers I approached tried to recruit me for sales roles. No way.

carlfoxmarten said:"You can see that it's not an easy thing to design, eh?"

Heh. I think that's the first time you've actually used "eh" casually in a sentence other than demonstrating its use intentionally, when we were both in Vancouver and talking about the perceived Canuck stereotype. :)

In answer to the question, Hell yeah! I know from designing my own game, and the Inform7 games I've been working on, how much additional code is required for any kind of a game. Non-programmers think you just write the bare instructions needed to make an object do what you need it to. They have no grasp of the concept that to keep a game behaving the way it should you need to have every contingency predicted and accounted for.

The Fox Valley church friend of mine who works developing domestic robots at the University of Technology Sydney and I were having such a conversation as this. The laymen have no idea how extensively you need to code just to make an interface. I told him of an experience I had with my father. I'd written my very first text game, and showed him how it would respond with the sentence "There is no way to go in that diretion" any time a player tried to move in an invalid direction. When I showed it to him he replied "I'm sorry Stephan, I don't see what you've accomplished." My Fox Valley friend immediately laughed; he knew exactly where I was coming from.

[carlfoxmarten]

thefoxaroo said:“Heh. I think that's the first time you've actually used "eh" casually in a sentence other than demonstrating its use intentionally, when we were both in Vancouver and talking about the perceived Canuck stereotype. :)”

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.

thefoxaroo said:“In answer to the question, Hell yeah! I know from designing my own game, and the Inform7 games I've been working on, how much additional code is required for any kind of a game. Non-programmers think you just write the bare instructions needed to make an object do what you need it to. They have no grasp of the concept that to keep a game behaving the way it should you need to have every contingency predicted and accounted for.”

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