AIS Field Headquarters Alpha

As mentioned in previous comments, I'm frightened of getting into imposition and pinning again because I never mastered it the first time around. So, in an effort to avoid getting to it for as long as possible, I started with castling.



As we can see here, the king's castling moves are highlighted as legal when the (numerous) conditions are met to allow the move. Originally, I was going to mark the rook as the movement target as I did in the previous version, but this would have required working around code I had already established long ago that only allowed a piece to occupy the same space as another if it was capturing it. I figured this worked better in the long run, since the destination squares of the castle move are highlighted instead of the rook pieces and may end up conveying a clearer message of "hey, you can legally castle".

In this next shot, we see the kingside rook has abandoned h1:



...and we see that the king can no longer castle kingside. Then, just as our dashing protagonist is about to castle queenside, the evil queen from yesterday appears!



The evil queen has effectively prevented the king from castling, since he's too chicken to pass through her line of sight. Fortunately, the queen occupies herself elsewhere and allows our hero to castle again:



Without hesitation, the nervous king castles with his queenside rook and retreats behind it:



Now that the king is safe, two pawns appear on the board. The white pawn rushes to c5, as if moving out of turn like he had something to demonstrate:



Using our square highlight-o-vision, we can see that the black pawn indeed has his two-square hop available to him:



And he decided to make the leap, landing on the safety of b5. He snickered to himself, looking upon the white pawn he had just avoided capture from. Little did he know, though, that this pawn was well versed in French:



The black pawn cowered in fear and attempted to beg for his life, but the vindictive white pawn would have his revenge, marching to b6 and spearing his foe along the way. He came to a stop, wiping his weapon in the grass and smirking. "En passant."



The very same pawn progressed to b7 without hesitation, somehow not having to wait like a piece on a chessboard with its' turn-taking rules disabled:



And he stepped upon the wonders of the eighth rank, feeling strange. He felt himself transform, his movements freer, his capturing rules simpler, his mortal coil being shucked away as his essence was deposited into another shell... a female shell. "I like where this is going."



She was no longer a mere pawn, oh no. She was now queen of the white kingdom! She cackled evilly, all remaining black pieces shivering in fear.

...

Random storytelling aside, the player is allowed to choose which piece he wants to promote to, I had just happened to select a queen for the screenshot. I also managed to fit in one more feature before I quit for the day, and that is the highlight of the enemy's last moved piece.



The highlight persists even if disabled in the options, so you could turn it off and back on and still see the proper piece highlighted. It's just a little bit of extra help for the novices like myself. Oh yeah, that larger knight in the corner is the turn indicator. It turns black when it's black's turn.

All in all, I'd call today productive.

Focus shifted from presentation elements to the king's involvement in gameplay today. It goes without saying that the entire focus of a chess game is the royal piece (the king in orthodox chess), but that also makes it a royal pain in the wazoo.

I created a tile-based "threat" system that was ostensibly detached from the actual pieces' movements; while the pieces contain a list of the turfs they're able to move to legally, each turf contains a list of pieces that would threaten a royal piece at its' location. This ends up working slightly slightly better than the last iteration, where each individual piece held a list of its' legal movements and of the tiles it threatened, so ascertaining the threats to a royal piece involved a loop through every enemy piece on the board. This time, the turf holds a list of threats, and can easily be consulted at the time of the king's movement collections.

Here, we have a black king minding his own business with his full legal movement set.


Oh noes! An evil white queen appears!


And the king loses a lot of his movement squares.

Now somehow, between inevitable bugs and setbacks, this seemingly simple system took most of the day to concoct, test, refine, and deploy. Keep in mind that the only part of the entire display that actually resides on the map are the white and black squares, though I'm not entirely pleased that I spent a whole day on this. Tomorrow I'll have to get to work on imposition and pinning, and beyond that, I don't see too much more that has to be done. I think after the royal considerations are finished, all that's lacking is the process of generating and exporting game movement logs to the Tibbius server.

Day five starting from a blank DM window and I'm almost finished. Scary and sad at the same time.

Today I took a bit more of a relaxed approach and just did some light work on the presentation aspects.

Audeuro had suggested that, instead of making a piece disappear entirely when dragged around to move it, that it leave a translucent "ghost" piece behind to mark its' original location. This seemed like a pretty good idea, so a short modification to my resource preloader and I end up with something like this (again, I'm only using print screen so the piece graphic being set to the mouse pointer isn't shown):



You'll also notice that I've dropped a board border in there since yesterday, and also the rank/file marker images. I'm not sure how I'm going to allow it to be done properly on the finished product, but the "blar" verb that appeared since yesterday rotates the board 90 degrees clockwise and modifies the rank and file characters along the top and right side to match the board orientation:



The border and rank/file characters are all screen objects, since those all stay in a static location while the remainder of the map rotates with client.dir.

You'll probably also notice the new Chess Options tab which contains... well, chess game options. Presently only the "legal moves" highlight and right-click piece info options actually do anything, but the remainder isn't really that difficult.

What I'm fearing getting into again is the complexities of the king piece. Even though I did it once and have a few ideas on how to avoid some speed bumps, I'm not particularly looking forward to all the game considerations that have to be made involving the king piece. One of my least favorite areas is maintaining a record of every "threatened" tile that a king cannot occupy, which I used a second list for in the last incarnation of chess; one list of "legal movement" turfs, and a list of "king threat" turfs. Consider things like a rook one file away from a king blocking off its escape route, or an enemy queen preventing the capture of an enemy pawn. The reverse is also loads of fun, such as an enemy rook pinning a friendly bishop to the king (making the bishop unable to move due to putting themself in check). On the bright side, bitwise operations are going to make a little bit of the process easier, considering I can just take an enemy rider's (queen, bishop, rook) movement cells, all friendly pieces' legal movements, and & them together to gather which pieces can make an imposition move, which was an arduous process in the previous incarnation without that huge timesaver.

I can only hope what I've picked up since the previous incarnation of chess can help me out when I get to that point, since I'm not looking forward to the royal piece considerations in the least. ANy insights anyone has on the subject are welcome, considering the only way I know how to do it is making a secondary list of turfs for each piece containing areas they can't actually move to but would illegally cause check if the enemy moved a king there.

Today's work was mostly on the superficial display system made entirely of images that I concocted about 24 hours before making a working model. My plan involved having only one of each game board in the map file (such as one checkerboard) and using a slew of channel-specific /image objects to represent the gameplay. This way, resources are constrained to a tiny amount (by having only one game board and one pool of icon resources) while allowing as many simultaneous games as a host machine can support. Through a lot of headaches caused by myself having forgotten I left a bunch of testing elements in the code while the actual intended interface was being built, I managed to create a working model as described above. Each channel is allowed one game (so far, chess or checkers) and the gameboard layout is unique to that channel, complete with realtime updates.

This is pretty much a glimpse of what I intend the window to look like once finished (sans the info control that I'm only using as a quick and lazy way of accessing testing verbs):



All of the pieces displayed on the map there are /images, as described above.

After I switch channels:



Don't be deceived by appearances, that's some high tech trickery, right there -- the "graphics" set was swapped out upon my entrance into this new room.

This comes to one of the things I struggled with avoiding the most: determining what piece the client was presently holding. I was doing my best to avoid having a variable attached to the client that had any sort of info about that, since I wanted to keep the clients as detached from the game processes as possible, I ended up taking the MouseDrag/MouseDrop approach, which allows me to know which client is involved in the process the entire time without ever having to find them. This is what happens when you want to move a piece (the piece "disappeared" because the mouse pointer is set to the piece's graphic during this process, and print screen doesn't capture the mouse):



Those (toggle-able) "legal movement" highlights are only visible to the client repositioning the piece, complete with the piece existing on the game board disappearing during the process for full effect.

All of the pieces have been tested to have accurate "legal movement" collectors, so essentially all that's missing is the structure of the game (since presently anyone can move any piece they can see).

Following suggestions by others, I went back to things I already established and opened up the actual "game" end of the project to accept multiple types of board games, the two in mind so far being chess and checkers. Some things had to be defined a lot wider such as the occupied var on clients now, which serves as the generic "this player is currently participating in a game" flag.

Today was mostly more work on the chatting aspects. The room owner can now assign operators who can do everything he can, sans creating more operators. Essentially, I think the frame of the chatting segments are finished and is just lacking the input control and "say" verb.

The game's verb list is a custom list of buttons, since I wasn't too fond of the redundancy of having a tab of verbs inside the verbs tab. This is what it currently looks like without the operator section:



And hey, lookie what happens when I create a channel:



I think ultimately that's going to look better than a verb list in an info control, though I'm certain it'll cause me much more work later.

I've also managed to create a couple of options panes:





The only thing I'm not particularly happy with here is the fact that checkbox and radio button text is centered, so I can't really line up the labels on those controls nicely.

I've also put the pieces through a pair of colour filters and generated all of the "selected" and "last moved" icon states I need:



All in all, no particularly heavy work today. I'm planning on starting on the actual chess game part tomorrow (or more accurately, whenever I happen to wake up).