AIS Field Headquarters Alpha

BGC still lives... in code

Sat, 26 Sep 2009 03:25:09 GMT

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.

A bit of work on more gameboards

Fri, 21 Aug 2009 12:12:14 GMT

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

BGC sees a third game

Wed, 19 Aug 2009 17:00:16 GMT

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.

Chess finished

Mon, 17 Aug 2009 05:32:32 GMT

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.

When a problem comes along...

Sat, 15 Aug 2009 08:08:04 GMT

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:

Wheels are still turnin'

Thu, 13 Aug 2009 07:48:10 GMT

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.

Nearing the finish line.

Wed, 12 Aug 2009 07:44:50 GMT

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.

Tightening up some screws

Tue, 11 Aug 2009 06:11:19 GMT

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.

Projects evolve so fast.

Mon, 10 Aug 2009 07:24:58 GMT

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

The endeavour continues

Sun, 09 Aug 2009 05:53:36 GMT

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