The closer I get to thinking that my Artifex Chess plugin is releasable, the more things I feel are necessary to complete before finishing it. Some of this is testing. I tried to import a different PGN and it failed on something silly. That does need to be fixed. When a project’s phase gets this close to the finish line, bug fixing must take priority to feature improvements.

There are other nagging things, though. The ChessECO piece is going to take quite a bit of time to complete. Some of the openings are many moves deep and I have a hard time writing FEN codes for board positions in my head. I’ll need to break out my chessboard and pieces in order to finish. Things is, the ECO detector is such a minor feature overall. Is it worth taking the time to pursue this now when I could add it as a 1.1 release?

I want to allow the plugin to be configurable. While I like the large board, each chessboard position image is roughly 15K and can appear sluggish. I could preload the images, but that’s another refinement. I could support smaller chessboards, but that’s another refinement. I could support a variety of thematic chessboard sets that are blogger-selectable. That’s another refinement. I should allow some kind of stylesheet support so that the plugin would look nice with anyone’s theme. Again, refinement. All of these things could be a 1.0.1 release.

Meanwhile, I did have to add some basic code. I wrote a check detector so that moves like Bb4+ do actually result in a check. I also use the check detector so that a move does not put or keep the moving player in check. I then abstracted the check detector to a “square being attacked” function so that intervening squares can be checked for attackers during an attempt to castle; the check detector is now an “is the king’s square being attacked” function. This has been added and tested.

I now have two final pieces to code. The first is a checkmate detector. This is a bit more involved than a simple check detector as it now has to determine if a checking condition can be moved out of, blocked, or if a capture of the checking piece is possible. The second is a refinement to the castling state logic. If the king moves, then castling is no longer possible. If a rook moves, then castling to that side is no longer possible. I do not detect or mark these conditions yet.

Once these pieces are in place, and tested, then I believe I can release Artifex Chess into the wild.

Position after 1. e4 e6 2. d4 d5

ChessWorld, where I play most of my on-line chess, does not name the openings in their game’s PGN data. Instead, it is left to an annotator to make that determination. For my plugin, I decided to embed the defining FEN data for 500 or so chess openings into a ChessECO class. This class will return the opening code and name by trying to index the game’s list of FEN notations and going as deeply into the database as possible; some openings have numerous uniquely named variations that go 25 moves deep.

I currently have over 230 openings defined in the class without even touching the queen pawn openings yet.

Correction: ChessWorld does embed ECO data in their PGNs. However, they simply embed the code, not the name. Since some individual codes cover several rarely used openings, I’m deciding to enhance the capability beyond simply doing a code -> generic name look-up.

I now have 271 openings/variations coded.

Currently, besides graphics files, the plugin is composed of four PHP source files: artifex-chess.php, chessfen.php, chessboard.php and chessgame.php. The first file is the plugin’s “main” code. It includes the other three PHP files, the fen and pgn tag filters and the filter registration code. The other three source files contain class definition and implementation code for ChessFEN, ChessBoard and ChessGame classes.

ChessFEN is a class that manages the game state information found in Forsyth-Edwards Notation. It includes fields to manage each individual game property, setter/getter functions, castling status and move clock management functions and an emitter function to convert the property fields into a full FEN string.

ChessGame is a class that is used solely for pgn support. It is the primary interface for the pgn tag filter function. It contains the high-level pgn parsing algorithm and code emitter logic. The emitter will substitute the pgn tag with HTML and Javascript logic to display and manage the user interactions with the game’s playback.

ChessBoard does most of the dirty work. It is the primary interface for the fen tag filter function and is used by the ChessGame pgn parsing algorithm. It manages the chessboard and determines move legality. Its interface with ChessGame is via its try_move() function, which in turn relies on its private sniff_move() function. If the attempted move passes the “sniff test”, then the move is allowed. sniff_move() also relies heavily on two other functions: can_move_to() and is_lane_clear(). As of this writing, chessboard.php contains 689 lines of code/comments. These four functions take up 396 lines of code/comments, or over half. And there’s more work to be done as I am not currently handling castling and disambiguative moves (a la Nbd7) and the code is not checking check or checkmate pre- and post-move states.

The implementation of both tag filters will operate using a compile -> object paradigm. The resulting objects are stored in a “cache” subdirectory under the Artifex Chess’s plugins home directory in the WordPress file system tree. The fen tag’s object is a GIF image constructed using the ChessBoard->make_gif() function. The name of the GIF image corresponds to the “shortened” FEN string with ‘/’ characters replaced with ‘_’. When make_gif() is called, if the image already exists in the cache, then a new image it not recreated and the image filename is returned.

PGN’s cached object is still under development. Initial designed were going to be raw Javascript, but I don’t want to have code read in and eval’d for security reasons. It would be fast, but it’s also a dangerous thing to do. Instead, the cached object will consist of a YAML file representation of a hashed PHP array. The array in question is a collection of game state data collected by the pgn compiler.

A nice side effect of the pgn compilation is that GIFs will be created for each board position in a successfully processed game. These GIFs will named according to the same convention as the fen GIFs and the same cache will contain
them.

In either case, cached objects will only be created upon a fully successful compilation step. Failed compilations will translate the fen/pgn tags with error messages. This will allow the user to use the Preview feature to determine if the compilation was successful prior to publication.

Update:
Disambiguous moves and castling now supported. All moves in the test pgn post now compile fully. On to the next phase.

Update 2:
Chessboard GIFs created upon successful compilation. Time to add game navigation / Javascript logic.

Update 3:
Basic game navigation is now fully enabled. The plugin is at the V0.9 stage.

Artifex Prime was inspired (or stolen outright) from Neal Stephenson’s book, The Diamond Age.

As of this post, the original FEN & PGN plugins have been deactivated and both FEN & PGN tags are now being handled with the Artifex Chess plugin via its ChessBoard and ChessGame classes.

PGN is a way to record chess games, whether finished or in progress. It is not used to play games interactively, but to follow the course of a game and understand how the game unfolded move by move. It is used for learning and analysis. A PGN player will contain a record of all the moves of the game, its result, who played and will allow the user to watch the game unfold, whether automatically or by clicking on next/previous buttons or on individual moves in the record.

Whereas the FEN tag simply converted a coded character string into an image, the PGN player is more involved and will allow user interaction with the game. This means Javascript, to handle the interaction of user events and board position.

The biggest difficulty is that a post may contain multiple games, and that the main page may contain multiple posts with multiple games. Managing all of that will be a challenge.

First things first, though. Let’s start with one PGN tag in one post. The following game resulted in the FEN position in my last post. (And in case you couldn’t tell, on ChessWorld, I’m the Feldmarschal.)

Event: www.ChessWorld.net server game
Date: 2008.8.26
White: Capstone (1697)
Black: Feldmarschal (1959)
Result: 0-1


«««»»»

French Defense (C01)
1. e4 e6 2. d4 d5 3. c4 Bb4+ 4. Bd2 Nc6 5. Qg4 Qf6 6. e5 Bxd2+ 7. Nxd2 Nxe5 8. dxe5 Qxe5+ 9. Be2 Qxb2 10. Rb1 Qf6 11. cxd5 exd5 12. Qb4 Ne7 13. Ngf3 O-O 14. O-O b6 15. Bd3 c5 16. Qa4 Bf5 17. Bxf5 Qxf5 18. Nh4 Qf6 19. Qg4 Ng6 20. Nxg6 Qxg6 21. Qd7 Rfd8 22. Qh3 d4 23. a4 Qc2 24. Nf3 Qxa4 25. Qf5 Qd7 26. Qd3 Qc6 27. Rfe1 c4 28. Qf5 d3 29. Ng5 Qg6 30. Qf4 d2 31. Red1 Qxb1 32. Qf3 Qxd1+ 33. Qxd1 c3

From ChessWorld.net:
White: capstone (1697)
Black: Feldmarschal (1953)
Result: 0-1

Position after 33. … c3

This plug-in uses ‘fen’ tags with the FEN notation string embedded within. The plug-in filter finds all of the embedded FEN strings within the post and processes each one. If the string is not valid, it will replace the fen tags and embedded string with an error message. This will help the blogger when previewing his/her post.

If the FEN string is valid, it will build a GIF image file based on the contents of the FEN string. The image file will be placed in a cache directory off the plug-in’s installed directory. The cache will be checked first so that heavy traffic to the blog won’t bog the server down with repetitive processing.

As the available number of chess positions is quite large, it is possible that the cache’s entries may fill the server. At roughly 20K per image, that may not be a problem. That said, the plug-in should probably cull old entries after some threshold is reached. Or a technically savvy blogger could set up a cron job to do this, which is how I handled the situation with the Barscape forum.

For example, there’s a plug-in called Embedded Chess which allows completed games to be replayed and analyzed. I tried to use it, but I thought the board and pieces were too small. The background was also white, which was jarring compared to the overall site theme. I’m sure there were options in there so that I could tailor it to my site, but I couldn’t find them after cursory look.

The chess plug-in bothers me somewhat. I had written a chess game replayer, but I may have deleted it during a recent file housecleaning spurt on my web server. I can probably rewrite it, but that would be another thing on my ever-present to-do list.

So, random ruminations aside, here are two plug-ins I’m going to write in the short-term, in between site design work:

• FEN Display
• List

FEN stands for Forsyth-Edwards Notation and is a way to record a chess board position using letters and numbers. I had written some FEN support code for the Barscape forum and I think it would make a great project with which to learn WordPress plug-ins.

The List plug-ins is just a way to keep track of stuff that you would have in a simple spreadsheet. Rows and columns with headers with possible color coding. Yeah, I know. It’s an HTML table. Big whoop. The heart of the issue is that I want to import/export the list from somewhere and/or have an easy way of editing it. Ever hand edit an HTML table with more than 48 entries, like say… a NH 48 4000′er peakbagging list?

Otoh, maybe I’m just reinventing the wheel here. I could just manage the list in Apple Numbers (or M$ Excel), and simply export it. One possible issue would be the color coding of cells. I would have to couple the raw spreadsheet data (a la CSV) to a stylesheet. And maybe that’s what the plug-in works with. I certainly don’t want to roll-my-own spreadsheet.

First up: the FEN plug-in.

I don’t like the basic Choatic Soul theme I picked for Effluency 2.0. Well, I do; I did select it over others. But there are things I don’t like about it, like its 760 pixel hard-coded fixed with. On my 1440 pixel wide Mac laptop screen, that means that the blog content only fills 53% of the available width of my monitor. (I tend to run my browser full-screen.) On my 28″ 1920 pixel wide HD monitor, it’s even worse.

The narrow width and small font size bothers me enough that I feel that I need to tweak it. I had modified a theme with the original Effluency blog, but in order to make that old blog’s theme work, I modified the original theme files. The effect of this was that I did not install WordPress upgrades in order to prevent redoing the difficult chore of fixing the theme. The WordPress documentation at the time was dreadful. The net effect of not doing upgrades, however, lead to the malware attack that brought the original Effluency down and led me to begin work on a secure framework.

In the year(s) since, though, WordPress has made much-needed improvements to both their design and their documentation. WordPress now supports “child themes”, theme behavior overrides that a developer can create without modifying the original theme specification files. With this capability, I should be able to tweak Chaotic Soul for my own purposes.

Update: I’ve decided to switch the theme to Chaos Theory and work from there. It’s a minimalist theme with post titles on the left and the sidebar/admin stuff on the bottom.

Update: After creating a child theme and getting most of the elements to be variable-sized, I decided that I didn’t like the Chaos Theory theme all that much. Too minimalist. I’m going to start from scratch.

The delays in bringing this blog back were many. Apart from the usual suspects of a busy work and home life, my problem is that I can’t stop designing things. Coupled with that is the fact that I don’t trust anyone else’s software, whether it be their intent (aka: ads & data mining) or their skill (aka: bugs & security vulnerabilities).

I’ve been administering the Barscape forum for many years now. When I joined, it was being hosted on a “free” forum-hosting server. I say “free” because the forum software had Google Ads coded within it and the ads were being displayed based on people’s posts. This annoyed me. The liberal socialist in me did not like this crass form of capitalism sprinkled throughout our conversations. So the hard-working conservative DIYer in me took the next step. I purchased a web hosting account, registered the barscape.net domain, installed the phpBB forum software onto the account, wrote scripts to scour the Barscape site for all posts and user information (since I didn’t have admin privileges) and ported the entire thing, topics and conversation threads all, onto the new system. It took about 3 weeks, but I did it.

The process wasn’t complete though. The old forum had some features that the new forum didn’t have. So I hacked around in the guts of the phpBB software and added many new features.

Knowledge is a Pandora’s Box. Now that I knew how to do web coding, I began to experiment with different communication paradigms on my own. Forums are great for keeping long-term comms available. However, as we’ve seen with Facebook and Twitter, some people just want to say Hello. Those conversations do not need to be kept around.

In my previous blog, I mentioned that I was working on a project called Crucible. Crucible was going to be the software framework for my next blog/forum/gallery system. It was going to provide both a server-based API for site coding and export services so that desktop apps and/or portable devices could access these services remotely. For example, a service called RandomService:RollDice could be accessed via direct function call on the server via PHP and/or Ruby, via browser-side Javascript, and via C and/or Java service access libraries/classes. And baked within it all from the start, the protocols used were going to be secure.

As you might imagine, Crucible was an ambitious project and the amount of free time that I had available for it kept dwindling. It finally reached a point where I would have to decide if I wanted to spend the time writing code or spend time interacting with people. In spite of my self-claimed title of ÜberGeek, I opted to spend time with people.

So after much internal debate on whether I should return to WordPress or brush the dust off Crucible and roll-my-own blog, I decided to return to WordPress. While reinventing the wheel can be an enjoyable process with a lot of reward, I have many other interests to keep me busy.

As I recently remarked to Claire, my partner, it’s times like this where I wish I was immortal. There is so much in life to admire and investigate and just experience, I would never be bored.

While I wait for Michael Resch’s treatment of the Western Front of 1914 to be published, I decided, after spending a recent weekend playtesting a Napoleonic game and discussing aspects of game design with Michael Resch, Mark Hinkle and Milton Janosky at the latter’s house, to take the various components of several WWI games that I had and roll my own. This blog, over time, will describe that attempt.

Before I get started with this Frankengame, I should describe the goal. After reading Holger Herwig’s The Marne, 1914 recently, and having read Barbara Tuchman’s The Guns of August quite a few times in the past, I want to figure out a way to recreate the tensions and maneuvers of Aug-Nov 1914 (and beyond) in a way that is plausible. I do not want to straightjacket the opponents, but I do want the actual events of 1914 to be recreatable w/o resorting to “idiot rules”, at least my definition thereof. So far, none of the games in my possession do a good job of that, in my humble opinion. This is not meant to be a criticism of the games or their designers. For me, they just fell short in one way or another.

These are the Western Front WWI games that I will be borrowing ideas from:

• Home Before the Leaves Fall (HBtLF)
• Drive on Paris (DoP)
• Schlieffen Plan / Western Front (WF)
• March to Victory / Over There (MtV)

Additionally, I will be borrowing quite a few ideas from other games in my possession:

• Twilight in the East (TitE)
• Proud Monster Deluxe (PMD)
• June 6 (J6)

And, finally, I will be creating (or inadvertently borrowing) some ideas and rules of my own as I see fit. That said, the above games are not an exhaustive list of inspiration. I have many, many more games than that in my game closet and I’m sure that various ideas and constructs have burrowed their way into my consciousness.

Getting Started

For ASoC, I will be using the HBtLF map of the Western Front, which is quite nice and fits the level of granularity I’m looking for. For the Order of Battle, I’m going to use MtV’s orbat and counters. MtV’s orbat, with its Europa roots, has a very nice detail to it. In addition to the usual divisions and other suspects, it contains references to several artillery units which were probably factored into other games’ HQ units or barrage factors. Where the WWII Europa system sought to focus on combined arms / armor tactics by applying die roll mods to combats where armor was involved, the MtV/OT system focuses on WWI’s queen of the battlefield: artillery. As such, I’m going to use their artillery-heavy orbat with its individual artillery components.

Big Bertha: German 420mm howitzer

Right off the bat, I need to decide how the sequence of play is going to go. Mixing counters, with their explicit movement rates, onto a map not designed for such will create huge problems if not done properly.

Turns & Impulses

After playing a solitaire game of June 6 recently, I was struck by the effects of its chit-pull mechanism on the battlefield vs. the usual igo/ugo method. Each formation was an entity unto itself and one formation may move/fight twice in a turn before its immediately opposite enemy formation. The ability to steal a march or grab the initiative struck me as being a huge plus in that particular game, and it struck me that there were great similarities in how June 6 treated formation initiative and how the Western Front armies took advantage (or squandered) their situations as well.

With that in mind, armies in ASoC will move and fight individually, for the most part. There will be situations where adjacent armies can and will move and fight in a coordinated manner, but that capability is not automatic nor without risk.

An Aside: Competitive Probabilities

Many years ago, my brother and I designed a dice-based baseball game based on Hall of Fame players and their career statistics. After several tweaks, I switched from a single roll LUT (Look Up Table) method of generating game events to a competitive dice roll method. In the latter case, both players roll and the winner of the roll generates the event, mostly, but not always, in their favor.

For example, Team A’s pitcher goes against Team B’s batter. As both Team’s players are Hall of Fame players, the event generation data on their player cards will mostly benefit the owning Team. To determine which card will generate the event, both players roll 2d6 and the Team with the highest sum wins the roll and his/her player card will be used to determine the game event.

There are many interesting side effects with using competitive probabilities, which I won’t go into here immediately. Suffice it to say, that ASoC will be using competitive probabilities using d10 rolls (per player) to generate game events where both player’s units are involved, namely combat.

Setting Priorities

Whereas June 6’s chit-pull system is very random and completely outside the control of the players involved, aside from purchase/placement into the available pool, I wanted ASoC to give each player, in their role as C-in-C, the ability to influence which formations get selected if they get initiative (win the initiative rolls).

Foregoing, for now, the detail as to how formation chits are purchased each turn, a la June 6, each player will have the capability to purchase 2 chits for each offensive army HQ. (Army HQs can be either offensive-capable or merely logistical/organizational HQs. Consider the difference between French 5th Army and Groupe D’Amade.) These chits will be placed face down on a 9-space track numbered: “0/1” and 2 through 9. More than one chit may be placed on a track space, but not until all other spaces on the track have a chit placed there. More than two may be placed on a track space, but not until all other spaces have two chits placed there, and so on.

During the turn, formations are selected for movement/combat by having each player roll a d10 for initiative. (Some modifiers may apply: such as giving Moltke a negative modifier during late August / early September.) The winner of the roll gets initiative. The formation which gets to move is picked from the numbered space on the track which is equal to the winning player’s die roll. For example, if France won initiative with an 8 roll (vs. a 7 roll), the topmost chit on the space labelled 8 is activated for movement/combat.

Due to competitive probability odds, 9 will be the winning roll more often than 8, and so forth. Therefore, if a player wants a particular unit to (possibly) move first, they should place that formation’s chit in the 9 space. (There are lots of interesting ways to game this system, which I won’t go into detail with yet.)

If, as will happen later in the turn, the winning roll’s space on the track is empty, add 4 to the roll to determine the next space, wrapping numbers past 9 around to the 0/1 space, treating that latter space as one space. For example, if the winning roll was 8 and the 8 space was empty, the next space to check would be 3: 8 -> 9 -> 0/1 -> 2 -> 3, or 8 + 4 = 12 – 9 = 3 for you math wizards out there. The +4 mod simulates the activation of a secondary theater while the primary theater’s activity is ongoing.

Formation Coordination

When a formation is selected via a winning initiative roll, the player may activate (move/fight) that unit immediately or they may put it in reserve, hoping for another winning initiative roll and the selection of an adjacent formation. If an adjacent formation is selected, then the two armies may move/fight in the same impulse in a coordinated manner. If a non-adjacent formation is selected, the player may do one of the following:
activate the 1st reserved formation and place the 2nd selected formation chit in reserve
keep the 1st reserved formation in reserve and activate the 2nd selected formation

Before any initiative roll, a player with an army in reserve may announce that that army is coming out of reserve. Once announced, that army will become activated on the next winning initiative roll by that player.

Fog of War

Note that chits are placed on the track upside-down to hide their identities. When these chits are placed in reserve, they are kept upside down. Chits are only revealed when they become active.

Last Moves

When one player has no more offensive formations to move, the remaining player with formation chits on the initiative track moves the rest of their formations. However, they still roll to select these formations. In this case, 2xd10 are rolled with the highest number determining which formation is selected.

When no more offensive formations are left to move, another final initiative roll is rolled and each player takes turns moving their logistical formations with the winner of the initiative roll determining the order.

(to be cont’d…)