Xerra's Blog

Drunken coder ramblings

Putting it all on screen —

With a mocked up game board in place it’s straight onto probably the hardest part of the project, which is handling all the objects needed for the game. There are 14 holes to keep track of on the board, and 48 pegs. We need to know the hole location of each of those pegs, the x and y positions of them on screen, the status of these pegs (as they could be moving between holes) and what kind of pegs they actually are.

I’m using some basic gem graphics for the players view and they’re going to need to be shuffled around within the hole they are in so it looks like there are however many gems in that hole, even if I have a counter displayed as well. Sticking them all on one central spot is useless as it’s going to look like each hole only has one gem when it could have loads.

So my problem at present is getting a structure in space probably for the board, where it keeps track of how many pegs are in each location, a total counter, which can update dynamically as pegs hit the stash, and the actual data for each peg itself, as there is several bits of information for each object there, too.

I approached this with pseudo code first. Just writing on paper how it should work and putting it into actual code on the page as far as I could remember the syntax at the time. Naturally, with the worlds worst memory for remembering stuff like this, it wasn’t brilliant, so I dumped what I have into the editor and have to tinker around with that to display some counters and feed it some dummy move data to make sure it’s all going to work correctly as actual player movements.

The board object itself, with holes in place is also going to be needed for an AI to work out how many pegs are in each hole when it’s their move so they can react accordingly. It can be programmed to do different things depending on some kind of a user setting but , in most AI, it would be logical to almost always go for a move where you can capture five or more pegs in one go, even if the player is setting them up to get an even greater return. Only a very sharp AI should be able to work this out as most players would play that way, too.

I’ve mapped out the areas where player is going to click to choose a hole to move from as that’s going to be needed for input before I can do any of this. Some kind of visual feedback will need to go in there so player can know they have clicked and the move is taking place. Not sure how I’ll handle that from the computer playing his move as I can’t imagine any kind of AI needed being so time insensitive that there will be a delay.

Onwards…


Categorised as: Blitz | Development | Mancala



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.