Win conditions are arguably the single most influential factor in how play should be balanced, so I wanted to work this out before brainstorming on the particulars of combat.

Determining fair win conditions and then balancing combat accordingly is non-trivial, due to the asymmetry of attacker vs. defender. The main exemplary tower defense games I’ve played have been one-player, and some tower defense games continue until the player loses to the computer. It doesn’t need to be equally fair for both sides in that case, but here it does. I expect this part will require a good amount of playtesting before it is balanced enough to be considered actually playable.

Aside from balance/fairness between the players, I also want the game to end at a tense point. Ending at an exciting moment seems helpful in creating a favorable impression of an activity. Also, I want there to be some indication of how far the game has progressed and how close it is to the tense ending, so that there is a gradually greater incentive to keep playing as the game becomes more suspenseful. I’m not sure if all of these things will be accomplished in this roughly two-week prototype, but they are worth considering in this context for educational reasons regardless. Below are some of the win conditions I’ve considered.

Defender: Survive X turns, i.e. keep the attacker’s pieces from reaching the center space.
Attacker: Have a piece reach the center space in X turns.

This idea follows naturally from the general flow of many digital tower defense games, where the player (defender) must keep the attackers away for a fixed amount of time (or a given number of enemies). Having a fixed number of turns also informs the players how close they are to the end of the game.

Defender: Win 3+ out of 5 rounds.
Attacker: Win 3+ out of 5 rounds.

Where a round is an attacker planning out who will go where, possibly inserting some ability for them to tweak their plan in a pre-planned way – and then the defender acting turn by turn to block the ‘wave’ of incoming creatures.  This would mean that the rounds would have to be very fast, so that the attacker remains engaged / invested despite little to no interaction for this period.  The basic difference between this idea with extremely short ‘waves’ and the one above is that this one would wipe the board between ‘waves’/turns, whereas the other one would have persistant board placement.

Defender:  Survive until there is no more mana.
Attacker:  Reach the center of the board before the game runs out of mana.

This system would feature a shared pool of dice; the attacker goes first, and rolls x dice.  The sum is how much mana he has to summon and move creatures.  Then the defender takes the same number x dice and rolls them – this sum is how much mana he has to summon defensive creatures and launch attacks on incoming attackers.

These sets of win conditions are very similar; it is mainly the implied combat and turn-taking mechanic that differentiates them.  I think I prefer the style that the third set would enforce.

I’m moderately accustomed to the limitations of implementing a game design in code, but less so to implementing one physically in the form of a dice and board game.  The two main issues I think need to be addressed are 1. making a board and pieces that are decently attractive (i.e. not so rough as to be distracting from play) and 2. having the physical movements and mental calculations of the player be reasonable.

The board will start off as a hand-drawn version on printer paper; the form will be eight radii emanating from the center.  Spaces will be either along the radii, where they intersect with concentric circles, or be in the outwardly-increasing-in-size spaces that are created by the radii and the concentric circles.  Testing will determine which seems more likely to result in neat, clear representations of the state of the game.  I’d like to have the final board material eventually be icy-looking Lucite or nice dark wood or something equally clean but attractive.  The dice should go reasonably well with the board and art style of the pieces.

The pieces will need to contain a decent amount of individual information, as I do not want players to have to look up the stats of a given piece in a manual during play, even when they are new to the game.  I was initially thinking of clear damage-counters as pieces, with color-coded numbers underneath them to indicate whatever values are needed.  I think colored glass on Lucite is very nice looking.  However, re-printable cards would be more convenient to create and revise, and also allow more art.  This would allow more of a theme, e.g. dragons.

I think some artwork will really help here.  One very important thing I learned at work over the summer was that visuals are still very important for early prototypes.  Interesting concepts can be overlooked if the presentation is poor, and pretty artwork draws people in (and thus can result in more testers / feedback).  I’m planning on using some artwork from highschool, including some of the images I photoshopped for a card game prototype I made over the summer.  Eight pieces of art seems about right…

Concepts that still need to be incorporated into my board game design include the related issues of reward schedules and scaling.  As a game progresses, the subjective magnitude of the game should of course scale by increasing various components – including difficulty of conflict,  the value of rewards, etc. as was discussed in class today.  In my board game, I think this could be implemented mainly through the killing/defending interactions between pieces, which also ties into the reward/incentive schedule.  I would like to keep the game fairly simple and focused on interactions between attacking pieces and defending pieces that are based on placement – with no spell casting , complex terrain effects, or other mechanics external to these central pieces.

It seems that a successful reward/incentive schedule has different types of rewards, of varied magnitude, that generally feel (to the player) like they increase in value, giving a sense of progress throughout the game and constantly encouraging the player with an opportunity at a reward that seems really great relative to what they are accustomed to in the game (the “just a little further and I can get something even greater than I already have” mentality that can keep people up all night).  Asymmetric player roles makes this require a bit more work.  For now, I’m going to assume that the defender will have more durable and fewer defending creatures, and the attacker will have more fragile but more plentiful creatures, as is common in existing tower defense games like Plants vs. Zombies (so the opposite of a lone ‘hero’ or two attacking a fortress sending out many cheap minions).

For the defender, frequent rewards could be killing incoming opponent creatures.  The magnitude/threat of these creatures should scale, thus scaling the relief (reward) the defender feels as they destroy them.  Or, equivalently, there can be greater numbers of attacking creatures, and the defender must take out larger numbers of them each turn.  Setting down increasingly more powerful (and more persistent) creatures as defense can be a less common but greater reward than defeating creatures.  The attacker’s reward system will be the opposite. Being able to place down expendable attacking creatures and advancing them will be a smaller reward (although the rate of adding and/or the strength of them should be increasing).  Larger and less frequent accomplishments are taking down one of the defender’s creatures, which the defender cannot replenish as often as the attacker.

This means that I will also have to work out an interaction system between the attacker’s pieces and the defender’s pieces that 1. allows the defender’s pieces to destroy more of the attacker’s pieces (probably through the use of projectiles/range attacks) and 2. allows pieces on both sides to become stronger as time progresses.  I’m more concerned about the latter need; the simpler solution just being able to have more of the same pieces isn’t as exciting as gaining new abilities (maybe it could be made more interesting by having more attacking creatures, and the defenders having attacks that take out more of them – which effectively stronger attackers and stronger defenders).

There should also be a currency system that enforces the tendency for the attacker’s pieces to be cheaper to create than the defender’s pieces.  I think I may have the currency be based on die rolls, as dice are required to be the central mechanic of this board game assignment.

For another game design assignement, I’m considering creating a board game based on the tower defense genre – loosely inspired by my design for another game to be implemented in code later.  This board game will feature true asymmetry – where one player must defend a central area, and the other has (possibly unlimited) creatures to throw in along the borders.  I’m interested to investigate the challenge of ballancing a game that does not rely on symmetry between the players to create fair play.  I’m hoping to get any given playtester to play the game twice consecutively – once as the defending side, and once as the attacking side.  This will help in balancing the two sides’ abilities, and also determine if they are sufficiently different to provide some replay value.

This game should take advantage of the circular board; the circular form should not merely be an effective skinning of a linear game.  Some of the incoming/attacking pieces should move around in a circle, for example, and possibly be able to destroy pieces from a distance.  My concern with this, however, is that this is a board game and all pieces must be moved manually by the player.  I doubt I’d have time to make any mechanisms to advance attacking pieces an automatic base amount every turn.  There is also the issue of a circle providing a large perimeter that may be difficult to defend.  So I think one of the main challenges in designing this game will be making use the players have enough pieces on the board to create interesting conflicts (this requires pieces from opposing sides to be in close proximity), but few enough that they can make all the moves necessary in a reasonable amount of time.  One solution might be to have only four or five ’sides’ to the ‘circle’ where it can be attacked, and possibly have these four or five radii split into more as they extend outward.

I am reclaiming my senior design blog as a place to post my game design ideas, code projects, and artwork.  Also – summer at Maxis in Emeryville was great!  I’ve reterned to Philadelphia with an even stronger interest in game design, suggestions for a new club at Penn, and the very early beginnngs of a modeling portfolio.  ^^

As the semester is coming to an end, this is the conclusion of my senior design project.  My presentation went well; at 71 slides in 20 minutes it was a bit of a rush, but I think I got the main points across, and I enjoyed the opportunity to talk about what I’ve been learning and implementing.  Also, as an aside, it’s been fun having a blog.  I will probably continue using this blog in future projects for work logs / notes.  Below are links to my non-code final deliverables.

Presentation Slides

Final Report

My program supports two-human-player Go, allows a human to play Go against an AI, and is fully integrated with XNA (with a 2D view for all modes, and an additional 3D view for the AI deathmatches).  It is also designed to allow the user to switch between human / various AI players at will, and it is trivial to add in new AIs.  I have not actually downloaded my game onto an XBox360 (I do not own the console or a T.V.), but plan to find one I can use in the near future.  I do have the game taking input from XBox360 game pads.  Overall, there is much more I would like to do if I had more time to work on this project, but I certainly accomplished the goals I set for myself. I enjoyed this project, and also learned a lot about this field.

I added in UCT/Monte-Carlo AI from the MoGo paper algorithm.  The idea is to view the problem of deciding which move to take next as a multi-armed bandit situation.  The analogy here is that of a gambler with many machine arms to choose from – each with different playout rates.  His problem is to balance exploiting promising-looking arm(s) he has found to have the best empirical playout so far (exploitation) vs. exploring new arms to try to find one with a better empirical payout (exploration).  This exploration vs. exploitation issue is seen in deciding the next move to take in a Go game as well, when using Monte-Carlo methods.  Namely, the AI should find a good balance between finding out more about the moves that look best thus far (exploitation) vs. exploring new moves to try and find a better one.

The UCT/Monte-Carlo technique described in a MoGo paper by Gelly et. al. in escence seeks to balance these aspects in the way it creates a random graph.  It is based on calling as many simulations as it has time to complete; the process can be stopped and the graph (tree) evaluated at any point.  A single simulation consists of going down the existing tree depth wise, selecting transitions and therefore nodes (which represents board states / moves) .  Selection is made via upper confidence bounds (UCB), to favor both unexplored moves, and existing ones that look promising based on previous simulations.  When the UCB move-selector picks a move that hasn’t been explored yet (i.e. doesn’t have a node yet), a new leaf is created for it.  Then one random Monte-Carlo simulation is played out from this node to the end of the game.  The wins and visits counts of the new leaf node and all its friendly ancestors (all those that represent moves executed by this AI, so every-other node) are updated based on whether the one Monte-Carlo evaluation is a win or a loss.  There is a possibility of reaching the end of the game while in the process of using UCB to find already-explored nodes (e.g. the move within the one leaf we add ends the game).  In this case, I simply update the leaf and friendly ancestors with whether it won or not (even if the leaf was an enemy move).  Some aspects of this algorithm may be slightly different from the approach taken in the MoGo paper, but is very closely based on the UCT pseudocode found within it.

Digram of the random tree built by this UCT / Monte-Carlo process, from the paper “Modification of UCT with Patterns in Monte-Carlo Go” by Gelly, Wang, Munos, and Teytaud:

From the paper by Gelly, Wang, Munos, and Teytaud.

This approach performs well; it seems to have many advantages of the Naive Monte-Carlo AI, but is much much faster in evaluating the board.  I’m not entirely sure yet what would be a reasonable amount of time to allow it to search for (or what reasonable constant number of searches that would work well for large boards), but at least I was “feature-complete” for my presentation on May 1st.

I thought I’d also mention another of the weaker AIs added in.  Novice AI was an experiment similar to Greedy AI, that uses a novice’s heuristics in placing the next stone – such as trying to maximize its total number of liberties.  However, this is an example of what a difference is cause by variations in the particular huristics used.  Novice AI did not even create clusters, like Greedy Score AI; its priority for creating liberties was strong enough that it just placed stones on the board at spaced out intervals.  Of course these stones were left undefended, and this heuristic, which sounds useful, actually was extremely detrimental and prevented it from even forming groups.  I just included this toy AI as an illustrative example to use in my presentation.

Another AI variant I added prior to my presentation is Heavy Monte-Carlo AI, which is similar to Naive Monte-Carlo AI, but has heavy playouts.  Heavy playouts refers to the usage of some heuristics/patterns/”AI” to select the stone placements, instead of having completely random playouts.  I used the Greedy Randomized AI as the selector.  However, this approach made the AI very very slow; I would argue that Naive Monte-Carlo is better because of its speed (which allows it to compute statistics from a greater number of simulations performed in the same amount of time).  Also, I think one must be very careful in choosing how to bias heavy playouts.  Biasing them in a way that is far from the way moves will actually be made may confine the program to a more narrow strategy, whereas randomized playouts allow patterns to emerge on their own.  The MoGo paper does describe making use of patterns in the random playouts, which improves them by making each playout more representative of reality.  However, without carefully selected and tweaked patterns, I think AIs in this project are better off with fast, randomized playouts when playouts are needed.

One of the AI variants I added prior to my presentation was Greedy Score AI.  This approach was similar to Greedy Randomized AI, except it made its greedy choice based solely on the score of the board that would result if a given move were taken.  It simply simulates each legal move it could choose from, scores the resulting board, and finds the move(s) with the highest values.  If there is more than one tied, it selects one of them randomly.  This AI tended to build clusters, but was far weaker than Greedy AI / Greedy Randomized AI.  This was because it lacked the “boxing in” behavior that arose (somewhat indirectly) from the simple, novice-like heuristics that are in the other greedy AIs.  So it seems that simple, reasonable heuristics are more effective that attempting to determine the “goodness” of a board state, such as by scoring.  This may be sound reasoning for why Distance AI is struggling so much.