Well, sometime last week I finished programming the first actual phase of the Forge War – placing overseers in the mine and moving them around. Each piece of this code puzzle has its own challenges, and I don’t think moving overseers around is the hardest part, but it did have its kinks. Plus it’s the third of 6 milestones I’ve sort of mapped out for the project, so I’m half-way done I guess?

Anyway, the first of the kinks is just the idea of moving around on a hex grid. From any space, you can move in 6 different directions – not exactly Cartesian. I didn’t research the best way to do this at all, but just came up with my own (probably inefficient) system of using 3 coordinates, and any movement changes 2 of the 3 coordinates. I probably could have gotten away with just 2, since that is sufficient to define any point, but then movement would either change 1 or both of the coordinates. I think my way is more consistent and consistency helped with the coding.

So then of course movement is stopped by the edge of the mine or an overseer or after jumping over a series of workers, which was easy. Then came the matter of flipping over workers jumped, which was also easy, except in the situation where you jump over your own worker, in which case it goes to the guy who has the fewest workers on the board. This is essentially a player order calculation, since fewest number of workers also determines who goes first. I would have to program this at some point anyway, so you just go over every hex in the mine and count up everyone’s workers. If there’s a tie, look at money, etc.

The annoying thing is that everything has to be programmed for 2, 3 and 4 players. Often times this can be accomplished using the player count in a calculation, but more often it’s just a lot of if statements.

The MORE annoying thing is that most of the code has to be written both player-side and server side, which are in different languages, which totally suuuuuucks. All calculations have to be written server side, since Rule #1 of multiplayer programming is to never trust the information a player is sending you. Really, it’s just about getting the most basic information about what the player wants to do – like, say, move from hex 555 to hex 577 – check if it is actually that player’s turn, check if the move is valid, then perform all calculations for that move – like, how did that move affect the board and how did that move affect each players’ inventory – and finally send those calculations back to the players so that their seen information can be updated.

And that’s all well and good, except I want the player to be able to see how his move affects the board and the inventories before he confirms it, and to actually be able to cancel the move if it doesn’t do what he thought it would do. This is very helpful for learning the game, which is the ultimate goal of programming an online version of a board game in the first place. So that means all the calculations the server will make have to be made by the client before communicating with the server.

The final problem was looking for worker unions after a move has been made. Groups of contiguous same-colored workers of a specific population are removed from the board. Luckily I had been doing very similar calculations in Lazy Robots for shift-clicking a group of contiguous boxes, so I just had to translate that thinking to three coordinates and it worked out just fine…both times.

So, yeah, pretty dry post, but that’s what’s going on. Of course, another idea for a game came to me while I was waiting in the car while my hot wife picked up some flowers for her mother’s birthday. It’s just a very simple 2-player card game that could be really cool and really easy to produce, but is going to take a significant amount of balancing to get it just right. I’m sure I’ll get around to talking about it more later.

I read recently that video game developers have far more ideas for games floating around in their head than they could ever produce in their and I guess it’s the same with board games.