Saturday, March 10, 2012

The Components and Systems of Morgan's Raid

I've written before about the entity system architecture of Morgan's Raid. I am just now polishing a paper on the topic which I will present at the FDG conference in May. I contacted Adam Martin to get his feedback on the paper, and he was very helpful. He made a few suggestions that I simply did not have space to address in the eight-page conference paper, but since Blogger has no page limit, I would like to address one of them here: what are the actual components and systems of Morgan's Raid?

By way of simple introduction, an entity system architecture is a software architecture in which game object data is stored in simple objects called "components" and these are processed by "systems." Game objects then are simply unique identifiers that aggregate components. This approach favors delegation over inheritance. It proves useful in game development due to the highly experimental nature of such systems: the domain model itself is subject to dramatic change during practically every stage of development. For further discussion, check out the entity systems project wiki.
Numbers of components and systems during development
The figure above shows the growth of the number of systems and components during the development of Morgan's Raid. This figure appears in the paper with a brief interpretation. I provided the small initial set to help bootstrap the students, but most of the rest were written by them—the 25 developers who worked in Fall 2010 and eight who worked in the Spring 2011. I am very proud of the team, don't confuse my pride in their achievement with any claims of elegance and beauty. Indeed, there are quite a few smells in our implementation.

Without further ado, tearing into the source code of Morgan's Raid, we can see how the systems and components are related. (It appears that Blogger automatically scales large images down. You can grab a full-size PDF here.)
System-Component Dependencies
The systems are on the left and components on the right, with edges showing system-component dependencies. As evidenced by the diagram, there are a few components which are heavily used throughout the implementation. OnScreenBoundingBox, for example, is used by anything that involves bounding boxes. (This was originally called Position, but that caused serious confusion when dealing with world vs. screen coordinates. After refactoring, we ended up with OnScreenBoundingBox and GPSPosition, the latter because world coordinates were actual GPS coordinates.) There are a few systems that have no out-edges because they use no components at all. For example, FadingSystem handles the fading of the screen based on time of day, but it does not deal with a component explicitly: it is passed a long integer that represents the current time of day and performs its computation from that.

Several of the components have no in-edges. A handful of them are, sadly, rotten code that was never removed. In fact, some are added to game objects and never accessed by anything else. Others of these disconnected nodes are used directly by the non-system game code. The Morgan's Raid implementation reifies the state design pattern, and there are many places where critical game logic was done directly within these classes rather than delegating to explicitly named and tested systems. This is not ideal, and I ascribe it to the novice level of many of the developers. Ask anyone on the team what they think about the 1700-line behemoth InGameState and they will cringe and tell you it should have been done better, but at the time, they did not know how to actually make it better.

In the diagram above, I have hidden the inter-system and inter-component dependencies for one very good reason. When they are shown, the diagram becomes a bit of a mess. Check it out (or full-size PDF here).
System-System, System-Component, and Component-Component Dependencies in Morgan's Raid

Ignoring for the moment the fact that you cannot discern the system-component dependencies, this diagram does show that the number of system-system and component-component dependencies is relatively low. However, if I were to throw InGameState into the mix, it would have its fingers in practically everything.

The diagrams were generated with dot, and you can download the graph file here. (Note that Google Docs thinks this is some kind of Microsoft file due to naive handling of file extensions. Just download the original and open in your favorite plain-text editor.) I created that file manually by inspecting the Morgan's Raid source code, and so it may contain minor errors.

For your reading convenience, here's a simple tabular view of the systems and components as well.


SystemsComponents
BackgroundTileSystem
CityNameSystem
DestinationSystem
FadingSystem
GPSToScreenSystem
HoverableSystem
ImageRenderingSystem
IntInterpolationSystem
MinimumSleepTimeSystem
MorganLocationSystem
NightRenderingSystem
OnClickMoveHereSystem
OnScreenBoundingBoxSystem
RaidSoundSystem
RailwaySystem
ReputationSystem
RevealingTextSystem
SpeedSystem
StepwisePositionInterpolationSystem
SunSystem
TimePassingSystem
TimeTriggeredSystem
TownArrivalSystem
TownArrowSystem
TownUnderSiegeSystem
AnimationRenderable
ArrivesAtTownIndex
BackgroundTile
BeenRaided
CentersOnGPS
CityData
CityImages
CityName
CityPopulation
CityTargets
CommandPoint
Destination
DoesCityHaveMilitia
DoesCityLoseGame
DoesCityWinGame
GPSPosition
GPSPositionList
HasMorganGPS
Hoverable
ImageRenderable
ImageRenderLayer
InGameTime
IntInterpolated
MinimumSleepTimeOverride
Morgan
MorganLocation
MovesOnClick
OnClickMoveHere
OnScreenBoundingBox
OnScreenBoundingBoxList
PositionInterpolated
Raidable
Raider
Railway
Reputation
ReputationValue
RevealingText
Road
RoadsToCity
RouteTaken
Speed
Sun
Terrain
TimeToRaid
TimeTriggeredEvent
TownAdjacency
TownArrow
TownUnderSeige

Thursday, March 8, 2012

Family Gaming Retrospective: Shadows Over Camelot and Inching Along

My son, Alex, is five years old, and he loves to play board games with us. I have written before about some of the games we like to play together, his memory for box art, and how games revealed his ability to subtract. I want to take a moment now to share an odd juxtaposition of gameplay experiences: playing Shadows Over Camelot followed a few days later by Inching Along.

The Games

Shadows Over Camelot

Shadows Over Camelot is a cooperative board game, famous for its use of a traitor mechanic within an Arthurian setting. It was released in 2005 by Days of Wonder and designed by Bruno Cathala and Serge Laget. I bought a copy for my VBC seminar, specifically for the traitor mechanic. Some of the students tried it, but I had not played it at all until bringing it home over Spring break this week. It supports 3–7 players, and I was hesitant to suggest it for family play with Alex given the publisher's minimum recommended age of 10 (also 10 at BGG). However, once Alex saw the box, he asked if it was something he could try. The boy does love swords and shields. Having reviewed the rulebook, I figured there'd be little harm in it, so the next day we set it up to play—Alex, my wife, and I.

The main gameplay of Shadows Over Camelot involves collecting Fight cards, which range in numeric value from one to five. Different quests require different combinations of cards: two pair, a five-card straight, full house, etc. To prepare Alex to play the game, I asked if he knew what a "pair" or "three-of-a-kind" meant. He was unsure, so I taught him a simplified version of five-card draw. A few days later—after having tried Shadows Over Camelot—he suggested we play poker again, so it seems that also caught his interest.

Alex is just learning to read, and so he needs help interpreting many of the special, non-Fight cards. After three games, he was able to recognize a few words, such as "Pict" and "Mercenaries." These are good words to know in any context, to be sure.

Moving between quests is an expensive proposition in Shadows Over Camelot since it requires spending a whole turn, and that's a turn during which the knights are not making measurable progress towards victory. As a result, at least with our three-player games, we found that it was often more advantageous for an individual with the right cards to jump on a quest opportunity rather than go in squads. Alex picked up on this rather quickly. We had a few disagreements about what strategies were best, and sometimes he listened to our advice, while other times he went his own way. This was a strength of the game, that the rules of the game encourage discussion while each player retains agency.

Our third game of Shadows Over Camelot
We won our first game, though we had accidentally bent the rules in our favor. The second game was a rather quick loss, as our early acquisition of the Holy Grail, Lancelot's Armor, and Excalibur led to the accumulation of twelve siege engines outside Camelot—a loss condition. The third game was very close, and it looked like we were heading to loss even after sacrificing Excalibur. Then we realized that we had one chance at victory, and that was for Sir Percival (Alex) to sacrifice himself, dropping his health to zero to prevent loss by siege engines, after which I, as Sir Gawain, could play the final Fight card to complete a quest and win the game. We explained this to Alex, and he was happy to do so. We congratulated him on his self-sacrifice that allowed our side to collectively win the game. Indeed, the rules clearly state that everyone shared the victory, even the departed knights. At this point, my younger son awoke, and Alex ran upstairs, nearly shouting to his brother, "Guess what? We won the game, because my guy defeated himself! Isn't that strange? How can a guy defeat himself?" So, I am not completely sure what he learned from the experience, but he definitely seemed to grasp that he had given his side a chance to win by making a difficult decision.

Inching Along

That leads us to Inching Along, a board game by Kathy Harding published by Educational Insights. Since the game has no entry on Board Game Geek, I will take a moment to explain it. It is a competitive board game in which each player has a character that is moved along a track that is numbered 1 to 75. There are also eight straight lines scattered across the board, labeled "A" through "H". On your turn, you flip over a card, which will tell you how far to move forward or backward. These are expressed in terms of the lengths of the lines, so if you flipped over "Move Ahead A + D", then you would measure line "A" and line "D", add those values together, and move forward that many spaces.

Inching Along
Playing this game involves no decision-making. It plays very much like Candy Land except with a ruler and arithmetic instead of colors. Without having had the experience of playing it, I would have dismissed it as homework dressed up to look like a game. However, the fact remains that Alex seems to really like it. Unlike my wife and me, he has not decoded the mechanics to realize that there's no challenge here. It's much like Raph Koster's example of tic-tac-toe in Theory of Fun for Game Design: it's fun until you figure it out, and then it isn't. The mechanics of the game are not dressed up at all: flip a card, measure, move. There is no narrative and no pretension. This makes it less painful to play than The Tick: Hip Deep in Evil, which Alex frequently asks to play, but which similarly provides no meaningful decisions.

Detail from the Inching Along box
The box for Inching Along proudly proclaims that it was "invented by a 1st grade teacher." The publisher is in the business of making resources for teaching, so this is an important bit of marketing for them. I can't help but wonder what other games would look like if the designer's professional background was prominently displayed on the box. Every Reiner Knizia game should say, "Invented by a former banking analyst!"

The Metagame

I enjoyed Shadows Over Camelot as a cooperative board game, and I certainly prefer it over Inching Along. Reflecting on the experience of playing both of them with my son, I realize that both provided the opportunity to play an interesting metagame: the game of teaching the game. To help Alex make sense out of Shadows Over Camelot, I introduced poker. That is, I used the game of poker explicitly as a learning tool, knowing that by playing poker, a player learns certain patterns. If my memory is correct, I learned to play card games like poker, blackjack, and cribbage long before I played any interesting board games. When faced with the immediate challenge of teaching Alex about these patterns, I fell back on the game I used to learn them. One might argue that learning these patterns for Shadows Over Camelot might have been more effectively done by simply using the Shadows Over Camelot cards, and one would probably be right!

We have been trying to find ways to motivate Alex toward reading, and it appears that playing Shadows Over Camelot reinforced the utility of literacy. By the third game, he was able to mostly keep his cards secret, although he often would announce what he drew when he drew it. The pride in his voice as he recognized the cards was worth sacrificing the secrecy of his cards. When it comes to matters of cooperation and sacrifice for the greater good, I dare not make any grand claims, but I will say that it has already given us  a spike in the ground when talking about such complex issues.

The metagame of Inching Along is thinking of clever ways to embed mathematical lessons into the gameplay. At five years old, Alex has shown some facility for mental arithmetic with small numbers, but being asked to move forward the sum of 11 and 12 is more than he can manage in his mind. In the foreground of the photo above are some blue glass beads that we use as manipulatives to illustrate addition and subtraction. We had tried an abacus as a simple way to move beads around. I personally found this much more difficult due to  the arrangement of beads on rows, when I wanted to cluster them in more intentional ways not afforded by the rack structure.

We also had a pad of paper where we showed how two-digit numbers can be added by adding their digits separately. I don't think this algorithm stuck with him, but it did provide practice at talking about rows and columns while practicing properly holding a pencil and drawing digits. Even just the practice of using a ruler was certainly good for him, since from time to time he would try to count from the "12" end instead of "0".

Parting thoughts

At about this point in the post, I feel compelled to add a "Conclusions and Future Work" section, for which I can blame the brainwashing of my profession. I'm eager to try Shadows Over Camelot with some people who are a bit older than my own kids so that I can see the traitor mechanic in action. With three players, there is very little room for mistakes, and I suspect (and have heard) that the traitor is very powerful. I have also heard that Battlestar Galactica has an even better implementation of a traitor mechanic, but I feel like I should not play that until I've watched the series for fear of spoilers. Along these lines, I have been seriously wondering whether I should withhold my various Lord of the Rings games from my kids until they read the books.

I have no great desire to play Inching Along again until my younger son is old enough to measure, but I am glad to know that I can talk to my elder son about adding, subtracting, and measuring... but I can't shake the feeling that it's cooler to be able to talk about Picts and mercenaries.