AIS Field Headquarters Alpha

I started college again about two days after my last post, and it's not hard to tell that's sucking up a lot of my time. I only have fourteen credits of basic webdev stuff and it still only leaves a couple of days a week, days I've mostly been occupying with GameFly rentals.

That said, the bare basics of both the proposed Go and Backgammon games are finished; clicking a spire in backgammon or an intersection in Go will place a stone there, but where this really starts to cause an issue is that the piece tracking matrix was only designed to hold one /piece datum per game. Obviously, this concept needs to be reworked given Go will have to up four pieces per tile and backgammon could have two. I'll have to set aside a few complete free days to rework the system to function with these games properly.

This is probably not going to be the final scheme of the backgammon board, but it will be pretty similar; border, dark spires, light spires, background in order of darkest to lightest features.



Hmm, I wonder what this is for? It's a mystery =o

The only experience I'd ever had with Reversi is playing the NES game Othello when I was 6-10 years old, and obviously I never really took the time to learn the game and just started playing Super Mario Brothers again. When one of my playtesters stated that they wanted to play Reversi in the midst of a checkers game, I investigated the Wikipedia article regarding it and found the mechanics were rather simple. Aside from the piece placement requiring a different dynamic for the sake of intuitiveness, I was surprised to find that Reversi is played on an 8x8 board. This meant the gameboard was just as easy as checkers and chess to create, but the differing piece placement took me a little while to master.

Using Pressman's Othello rules, the gameboard starts with two pieces of opposing colours arranged as such:



Legally available moves are denoted by a semi-transparent piece appearing when you mouse over a square.



Then you just click the square to make the move.



Now I'm far from being any good at Reversi, but I still took a few more shots of the board for no particular reason.







Next on the agenda is backgammon.

Alright, so I finally just went ahead and faced the demon, and I must say that while it seems to work rather reliably, I'm not particularly pleased with the amount of code it required. Imposition and pinning sounds simple on paper, but once you delve into it trying to program the rule into a game setting, you find out just how irritating it is.

These two (game essential) items were entirely hit or miss in the last version of chess because of the way I decided to keep the map display free of references to anything else. This meant that there was no immediate concept of threat to the king, and at the end of every turn, I had to consult every enemy piece of the current player's to gather a list of threats to the square, and then I could start working backward forming imposition paths and the like. This time, the gameboard turf contains a matrix of pieces threatening any hapless royal piece of the opposing colour, and the process of determining check actually *starts* with a direct datum reference to the threatening piece(s). In short: the unique system BGC uses to support multiple games on the same board simplified the process immensely.

The server running on Tibbius has been updated with the chess-available version and is in need of testing. I imagine the bulk of any problems would be in the play structure (E.G., only allowing a player to select his own pieces in turn), but anyone checking it out should be on the lookout for any game-related issues as well.

It should also be noted that for now, the chess movelog is not being recorded, and is actually unreliable at present. Once the game's been determined to be working nicely, I'll get back to that and start sending the game records to the cataloguing script again.

In addition to not getting on the PC until after 6 AM yesterday (when I usually get on around 9-11 PM) I experienced an entire day's worth of delay after a seemingly simple problem arose after adding a checkerboard alongside the chessboard.

Anyone who's dealt with client.dir knows that, by its' lonesome, it will not properly handle a non-square map, in addition to seeming to do all manner of wacky things when the size of the map exceeds client.view. For over a day I tried silly modifications to things like client.pixel_x and pixel_y to no avail, until after about ten hours of programming the checkers game I decide to take a look-see at the variables the client has available, thinking to myself "there *has* to be something I can do about this issue". Turns out, there is -- simple use of client.edge_perspective, and enabling the EDGE_PERSPECTIVE flag on client.view.

In short, I lost a day's development simply by stumbling over something I've not used or researched extensively in the past. This sort of thing is what irritates me about BYOND as a whole, where simple items like what I was attempting has a simple solution, but is never presented as such. Sure, I knew about edge_limit and even read the reference entry for it before, but until I had a situation where its' application is essential I had no idea what its' purpose was.

Minirant aside, I'm more or less back on track. I think my immediate plans will involve finishing checkers and hosting this beasty for a public test of just how well the channel system functions while I finish chess. It may even be today yet, but sans any unforeseeable hangups like mentioned above, definitely by tomorrow evening.

Oh yeah, a peek at checkers: