.:aaron.helton:.
musings.of {'husband', 'father', 'technologist', 'international civil servant', 'humanist', 'skeptic', 'gamer', 'dreamer'}

I’ve been thinking about games lately, so I am taking on the classic Dots and Squares. In doing so, I am not simply proposing a digital translation. Rather, the game needs some tweaking to make the leap to casual social gaming (like on Facebook). This article explores the elements that could make a compelling social board game out of a timeless time-wasting classic. A later follow-up post will detail a particular implementation, including technical specifications that will hopefully lead to an actual game (in which case source code would also be freely available).

Inspiration for this post (and hopefully for the resulting game, if I can ever get off my duff long enough to actually MAKE it) was a product that adds social elements to your existing Flash-based games. That product is Platogo. Enhancements to the game are derived from an Instructables article suggesting ways to spice up the original paper based game.

The Game

The original Dots and Squares game is played on paper (or, as some coworkers and I were doing several years ago, on a white board). An arbitrarily-sized grid, constructed either with dots at the grid intersections or faintly colored grid lines, is placed on the paper. Each player takes turns adding a line, attempting to capture squares by enclosing them. A player who can capture a square usually must do so, but gets to add lines until no more one-move captures remain, then must add one more line. So the original game is all about territory. Whoever has captured the most squares once the entire board has been captured wins (a captured square is denoted by placing the occupier’s initials in it). It is a fabulously simple game, with a simple strategy that lends itself to quick play and zero learning curve. In its original form, it gets boring quickly.

Variations

That’s where some variations have been useful. The most obvious changes one could make to the game are the grid dimensions and the grid shape. Neither of these fundamentally changes the strategy, however. More variation can be achieved by changing the shapes of the enclosures (to triangles, for instance, but then the game wouldn’t be Dots and Squares anymore). This changes the flavor of the game, but does little more (except make the game harder to program). The Instructable gives some other possibilities: different point values for square capture and the introduction of “power-ups,” a term that will include both beneficial and detrimental modifiers. One final possibility presents itself: variable game resolution conditions (resolution occurring by capturing the greatest number of a certain square type, for instance). It is from these last three variations, as well as allowing for random or semi-random grid dimension sizes and grid shapes, that a digital version with a social layer can emerge.

Digital Game

Ignoring for a moment the social aspect, what does the basic digital game look like? It has the same elements that are present on paper: an arbitrary grid with a random shape and size. Additionally, the digital version contains squares with variable capture values and a random distribution of power-ups. From this we can see a good possibility of how a more immersive game could develop. This framework will, however, suffice for a simple game start. It provides the base components for a good game: adaptive strategy mixed with (and largely because of) game of chance mechanics.

Power-Ups

Power-ups will be the generic term for squares whose capture affects the playing field in some way, whether the effect is beneficial or detrimental to one or all players involved. Power-ups can be classified into the following categories, from the capturer’s perspective. Note that these do not define specific implementations.

• Capturer benefactor/malefactor. Whoever captures such a square receives some benefit or suffers some consequence.
• Opponent(s) benefactor/malefactor. Whoever captures such a square causes the player’s opponents to receive some benefit or suffer some consequence.
• All players benefactor/malefactor. Whenever the square is captured, all players receive some benefit or suffer some consequence.
• Collateral benefactor/malefactor. Whenever the square is captured, players who own adjacent squares receive some benefit or suffer some consequence.

Power-ups may:

• Directly manipulate point accumulations, either by adding, subtracting, multiplying, or dividing current point totals.
• Indirectly manipulate point accumulations by adding or removing captured squares.
• Possess turn-based effects such as counters or random effects, including disappearing.
• Be visible or hidden.
• Add or subtract player turns, including undoing previous non-capture moves, randomly or not.
• Be static (always present, even if the square occupied is captured and un/re-captured) or dynamic (i.e., one use resource, used up on initial square capture).

These elements provide additional strategic resources that may be manipulated by the players. It should be noted that benefactor and malefactor power-ups may defy the initial assumptions in certain circumstances, and there are definite reasons one might seek out malefactors, especially if they cause collateral damage. The presence of visible benefactor and malefactor power-ups will allow players to maneuver themselves and their opponents toward or away from such squares, preventing the game from becoming too simple.

Social Elements

How social the game should be depends on its purpose. This question rests on the availability of a single player mode, wherein the opponent is computer controlled. For simplicity of programming, the particular implementation I have in mind will not contain any computer-controlled opponents, which means that the game will rely entirely on the initiating player’s ability to recruit at least one other opponent. Since the social elements will be provided through Platogo, the game will be primarily a Facebook game, leveraging the initiating player’s friends network for opponent recruiting. Thus the game should be programmed to allow recruitment and initiation through Facebook, as well as win/lose/draw boards.

Extending the Game

Even with probabilistic game initialization, the basic framework may lose appeal after several game sessions. While these extensions do not promise to fully mitigate this possibility, they may help.

• Per-game custom rules. The framework provides some flexibility in enforced rules, including minimum and maximum territory values, distribution and types of power-ups, constraints on size and shape of the initial grid, and game resolution conditions. A default ruleset should provide adequate variation and balance, while the game initiator may opt to override the defaults to emphasize different strategy or chance elements. Thus each option should be weighed in terms of its impact on strategy and chance. A third, middle way customization option could include a simple continuum slider that adapts the game rules between an emphasis on strategy (that is, few or no chance elements) and an emphasis on chance (fewer strategic elements). The original game is purely strategic in that there are no chance elements whatsoever. However, no amount of emphasis on chance will eliminate strategy. The default position of the slider will provide the default ruleset.
• Terrain graphics. As a natural extension of variable value squares, each square could represent a terrain type based on that value. For instance, impassably tall mountains may have lower value than plains or foothills. This also opens the possibility of zero value squares, which could include water, but even this may complicate the game too much. This assumes, of course, that some objective measure of land value could be attributed to a terrain type, since every terrain type on the planet has some value to someone (or the plants and animals that live there). With no universally defined terrain values, initial attempts will be arbitrary. The graphics merely attempt a means of visualizing territory.
• Power-up graphics. This would be required even if no specific terrain graphics are included. Since power-ups can take a variety of forms, clever graphics will help differentiate them. For example, a dynamic (one-use) power-up that indirectly manipulates point accumulation by removing adjacent line placements (and thus captured squares) in a given radius (a collateral malefactor) could be represented by a picture of dynamite or a bomb. A static (permanent) power-up that grants the captor one extra move per turn, and that must be used each turn (player benefactor) could be represented by a gold bar or oil well.
• Territory markers. Instead of initials being the only option, players should be able to choose from available marker colors (16 seems right), their profile pic as an avatar, or one of a number of graphic tokens included in the game setup as part of the recruitment. What ultimately becomes available will depend on how well the various options improve the captured territory visibility.

Conclusion

With some creative application of the above descriptions, I believe I can work out a game specification. The questions that remain are 1) can I actually sit down and program it; and 2) will it ultimately be playable? The question of programming comes down to whether I have the time to learn how to make a Flash application. I know the basics already, but I am rusty. The question of playability? You be the judge.