Castles of Mad King LudwigCastles of Mad King Ludwig debuted at Essen Spiel 2014, and has since gone on to be very successful for Bézier Games, with several printings and a ranking in the top 50 on BGG. Prior to the analog version of the game’s debut, I was already deep in discussions with Jeremiah Maher, the developer who has done amazing work for Bézier Games in the past, including the Suburbia app and the free One Night Ultimate Werewolf app, to produce an app version of Castles.
Throughout this diary I’ll bounce around from “I” to “we”. When I say “we,” I’m referring to the collaboration between the developer (Jeremy) and myself. There are a whole bunch of things that the developer did pretty much much on his own, too, and I’ll try to highlight those as they happened.
My involvement with the app version of the game is pretty much continually hands on; I view the end result of the app as a collaboration between the developer and myself. In many ways, it’s the same relationship I’ve had in my previous working life as a product manager for Adobe, Intuit, Corel and other software companies, but instead of developing productivity applications like Illustrator and payroll software, we get to work on boardgames! My job is to come up with the overall direction for the app, provide guidance on what features I’d like to see implemented, supply all the graphics, rules, and game design concepts from the analog game to the developer, provide input on the UI, design the AI based on my understanding of how the game works, create the framework for the campaign mode, and design all of the campaign levels. I’m also playtester #1, receiving builds at least once a week and running them through their paces and providing feedback to the developer as well as detailed bug reports. The two of us have regularly scheduled Skype meetings every two weeks in which we discuss the current progress of the app’s development, next steps and scheduling, and work through all the issues that have cropped up in the recent builds.
The developer’s job is to do the “real” work…coding and lots of stuff that I take for granted, because from my point of view, it all seems so effortless (because I’m not doing that work). And there’s an amazing amount of work that goes into an app like castles. I really can’t emphasize enough how awesome Jeremy is…he’s an independent developer, with no staff (but with a very supportive family), who did all the development work for Castles by himself in just under 16 months. Castles is a fairly complex game by itself, as you’ll see in this article, and if it was just having a workable game that would be one thing. Instead, it’s a rich app with a giant campaign mode, an amazing AI, and a very polished UI. Considering that there are so many boardgames that STILL don’t have an app, which are being done by much bigger game studios, this is a huge accomplishment. Also, during this time period Jeremy also did a huge update for the One Night app (which again is an awesome piece of cross-platform technology) and created a stand-alone cross-platform setup app for Favor of the Pharaoh.
Initial design and prep work
The Suburbia app had been out for several months when we started the initial design work on the Castles app, and Suburbia had suffered from some initially lukewarm reviews due to (1) a nasty bug that wasn’t caught in beta testing and (2) limitations in Game Center for online play. The bug was fixed quickly, but the Game Center issues continued to linger on. Even with that, the Suburbia app has held steady at 4/5 stars, and sold reasonably well. It continues to sell even now, 4 years after analog Suburbia was released, and more than 2 years after the app was released.
One thing about the Suburbia app which has limited its potential to reach a large audience was that it was tablet-only. There are about 7 times as many smart phones as tablets in the mobile ecosphere, so we were only reaching 1/8 of the possible number of mobile users. We really wanted to make Castles work on phones as well as tablets, and that ended up being one of the chief goals of the UI and graphical design: it had to provide a solid, quality experience on much smaller screens than a typical iOS or Android tablet.
The initial framework for the Castles app was decided early on: It would feature local multiplayer pass-and-play matches, matches against 1, 2, or 3 AI players, and a solid campaign mode. We decided to take asynchronous online play out of the mix almost immediately for three reasons:
1. The potential for issues/bugs is incredibly high on both iOS and Android platforms
2. Because of the Master Builder phase, there’s an additional player switch every game turn that slows things down for asynchronous play
3. A relatively large chunk of development time would have to be devoted to implementing it, resulting in either a delayed release or reduced features for the rest of the game.
The pass-and-play matches would be designed to match the physical board game’s style of play, with all features from the game present. For development purposes, this was the underlying framework of how the game would work in the app, and a logical place to start development. This included graphics, placing tiles so that doorways matched, implementing the point system, and all of the other systems like master builder pricing, king’s favors, rewards, etc.
The AI would be the next step in development. The Suburbia AI was good, but not great, and we were determined to make the Castles AI even better. This is a pretty daunting task for a game like Castles, where players’ choices for which tiles to buy are based on not just immediate points, but also long term structural goals and potential for rewards, and all the different end game VPs (King’s favors, secret Bonus cards, money remaining, and depleted stack points). And there’s another layer on top of that: the Master Builder mode meant that the AI would have to evaluate the other players’ intentions when pricing rooms, weighing the needs of opponents against the needs of the AI.
Finally, the campaign mode had to be really good. The Suburbia app received many accolades for its campaign mode, though it was fairly limited in scope and length. Our goal was to improve upon the Suburbia campaign mode in every way, giving the levels more variety, providing a more compelling system for level rewards, and making it the correct length and difficulty.
Initial gameplay implementation
The first step was getting the rules and graphics to the developer. Jeremy was given a prerelease copy of the game and the rules as a first step. With a thorough understanding of how the game was played, Jeremy then deconstructed the underlying physical structure of the game: The “table” area where the game would be played, how tiles could be placed, and how points were tabulated.
He then set out to make the system within the app for placing room tiles. Dale Yu (the developer on Castles) and I had already done this with the analog game, devising a grid system that all the pieces had to fit into. Each square in the grid corresponded to 25 square feet (a square with the width of 5 feet and the height of 5’), with possible doorways centered on each of those grid squares. This is the secret sauce that allows Castles rooms to fit together so nicely; all rooms (including the round 150 and 500 rooms) fit into this grid. For instance, a hallway is a 1x6 room, while a 100 room is a 2x2 room. Once I communicated this to Jeremy, things began to take shape quickly.
On January 20th, 2015, in our bi-weekly Skype meeting, Jeremy showed me an alpha build of the game. It wasn’t really a game at that point, but instead was a cobbled-together chunk of framework technology that allowed dragging rooms down from a transparent “contract board” overlay along the top edge onto a playfield that was covered with numbers (each number being a square in the “table” grid that served as the playing surface). Even this early, many of the UI elements that would make it into the game were in place: The highlighting of possible placement locations, and the rotate and cancel buttons.
The first build I received, a few days later, had the same things in place, but I was able to test it out for myself. Zooming was already implemented at this point, and I was thrilled to drag rooms around and have them connect. It’s the little things.
A bug is found - in the Analog game
You know how I was just going on and on about how awesome Dale and I were, coming up with that grid system that everything fit so neatly into? Turns out it wasn’t so neat after all. There was an issue that even after the game was printed, no one noticed (and I still haven’t seen anyone report it). The thing is, the octagon rooms are…wrong. Foyers and 600 rooms have their angles cut in the wrong places. The result is more aesthetically pleasing when the rooms are by themselves, but when you try to fit them together, they’re off.
This wasn’t an option in the electronic version; the pieces had to fit correctly. Unfortunately, it wasn’t so simple as to just adjust the shape; the artwork on the pieces was the wrong shape too, and it would have to be changed or the tiles would appear distorted. Fortunately, the artwork had been done in Illustrator, so it was relatively straightforward to modify the walls and contents to make them work in the app. If they had been pixel-based, we would have had to have them both entirely redrawn by the artist.
Initial AI work
The first step in implementing any AI is to get it to follow the rules. The AI works under the same set of restrictions that a human player does. It’s the decisions points, where it can do different things, that things get tricky. The first builds with the AI had the AI randomly choosing a tile from the contract board and randomly placing it on an available room. Not particularly earth shattering, but the first few times I saw it, it already felt like the AI was making decisions (it really wasn’t). Jeremy had implemented it so that if the room that was being placed needed to be rotated, it smoothly rotated from the contract board down to the playing area, a really nice, smooth effect that made it into the final game (though it looks like one of those “polish” kind of things we normally would have done late in the process to make the game look better). After that was in place, there was an option for what he called “rapid play” which took a fraction of the time, but wasn’t as graphically pleasing. This was for testing purposes to make sure there weren’t issues with placement or other decision making that would be implemented soon.
Two months in, the app had a lot of the fundamentals in place: a random setup of the contract board from a shuffled deck of room cards, tile pricing, Living, Activity, and Outdoor rewards, connection points, placement points, downstairs icon points, and score tracking. It was almost playable. In just two months.
Of course, it was a lot of the details that are in the in game that would extend the development time quite a bit, as we’d soon find out.
After about 5 months, most of the actual game was in place, and it could be played against a computer AI opponent (who was still just randomly placing things, not much of a challenge) or a human opponent via pass and play. A lot had been implemented in that time period: King’s favors, Bonus cards and Utility room rewards, Sleeping room rewards, Corridor rewards, Food rewards, depleted stack endgame points, Passing as an option, Endgame money scoring, the ability to view other player’s boards on your turn, and a status bar at the bottom of the screen that tracked actions from each player (initially used for bug tracking, but then kept in the game so that Human players could easily review what computer AI opponents had done during their turn if they weren’t paying close attention).
While Jeremy was busy coding, I put together a Castle AI document. This was my attempt to quantify strategic choices, boiling everything down to mathematical decisions. Here’s my initial AI concept notes:
Here are the main vectors for analysis by the ai:
1) Immediate points: how many points is each room worth? What is the cost per point?
2) Favor lead: Similar to what we did with Suburbia for goals. Being ahead on each of the favors is worth X points.
3) Reward value: what is the likelihood of completing a newly purchased room? What is the value of completing it?
4) Future turn look ahead: 2-3 turns out: placing stairs gets the ai no points now, but it will get the ai access to downstairs rooms and a free corridor (by completing the stairs).
5) Value of rooms to opponents: buying a room is not just points for the ai, but also might reduce the number of points for opponents by removing it.
6) Master Building pricing: Pricing rooms out of reach of opponents vs. pricing them just within reach to maximize money during the MB turn.
7) Personal Bonus card valuation: This should always be considered.
That was a very high level look at what the AI needed to do, without any mathematical solutions. I also wrote up another document specifically for optimal AI room placement. You’ll see in the final game that the AI places rooms really well most of the time, particularly using its ability to close off multiple doorways at once with a single room placement. However, there are so many variables and options, that in order not to overheat your device, a lot of shortcuts were put in place, so once in a while you’ll see the AI do something a little unusual, like blocking off a doorway or not leaving itself enough space to place a room next to a doorway.Quote:AI MathematicsCompleting the basics
When the Skynet AI gains consciousness, it will do so because it understands math better than we do. Until then, we have to provide a computer AI with all the building blocks it needs to make human-like decisions. I wrote up an initial attempt at optimizing computer choices with a formula based on the most important concept in this and many other VP-based games: how many points will you have at the end of the game as a result of each decision you make? That formula is:
End Game Points = Current Points + (potential) In Game Points + (potential) Final Scoring Points
It’s the “potential” points that are really tricky. Each room you place will give you points instantly, but most also have these “potential” points that may be realized later in the game. For instance, when you place a Dining Room, it gives you 1 point, plus 3 connection points if you place it next to a Living Room type room. But it has the potential of giving you additional points: 3 more from placing another Living Room on its open doorway, the points you would get from having an extra turn when the room is completed, the points you get if you obtain a Bonus Card that is either Food rooms or 300 rooms, King’s Favor points, if this gives you enough to move you up a level for those end game points, 2 points if the 300 stack is depleted, and additional connection points from all the room tiles that have Food room icons on them that can be connected to the Dining Room. These potential points change in potential value from the beginning of the game, when there are much higher possibilities that you’ll obtain the other things needed to get those points, towards the end of the game where if you’re the last player to play, they total 0, since nothing can happen after the tile is placed. So Potential points are variable based on time, availability of other tiles, the amount of $ each player will have throughout the rest of the game to purchase more rooms, bonus cards, and other players’ boards (who might be interested in the same rooms or bonus cards that are potential points for the Dining Room).
What this really meant was that all of these things needed to be quantified so the AI could make the best possible decision. Here’s an example: For the Dining Room, the AI has to determine what the value of the Food room completion reward (an extra turn) is. To do that, it needs to figure out the Average Points per Turn it thinks it will get for the rest of the game. This is the math for that:
APT (Average Points per turn) = ((CRP+IGP)/(NTR+NTT)
CRP is the Current Points.
IGP is the potential In-Game Points, which is equal to Potential Connection Points (CP) + Potential Completion Rewards (CR) + Potential Room Points (RP)
CR = NTR/average number of open doorways per incomplete room * Average Reward value of incomplete rooms
RP= NTR * Average value of known + unknown room placements
NTR is the Number of Turns Remaining = (Room cards remaining/number of players) + (incomplete Blue rooms (played or on the contract board)/number of players)+((unpurchased hallways + unpurchased stairs)/2)/number of players)
NTT is the Number of turns taken
All that just to figure out what the reward for a Food room is worth to the current computer player.
And the AI has to compare that Dining Room value to the value of placing every other room that’s available (including stairs/hallways, and the value of simply passing and taking $5), with more math that evaluates the point value of $$ at that point in the game, which is subtracted from the value of placing that room.
The weird thing is that this process seems SO complex when it’s broken down like it is above, but our brains do a lot of this stuff in the background, while we’re talking about an entirely different subject, like is it really worth the extra cash to purchase the amazing Broken Token wood insert for the analog Castles of Mad King Ludwig game (it is, go get it now, it’s awesome).
The good news is that all of this math applies to the Master Builder as well, though he’s got to run through all of these computations for each player, and do some other fun computations to balance the pricing of rooms he wants versus the rooms that other players want.
The AI was continually tweaked throughout the development process, getting better and better. I’m really happy with some of the things that happen in the game, including when AI players collude against a Master Builder (I’m sure you’ll read about this in some cranky player’s online post if you don’t run into it yourself). The AI is not friendly, its only goal is to get the most points, and it will do whatever it has to in order to defeat its opponents. We didn’t program any good sportsmanship in there, and definitely no remorse.
One of the aspects of the AI that I’m particularly proud of is that it won’t buy really high priced rooms unless the value (End Game Points) is appropriate for the cost. This is also quantified in the app, with another series of formulas that takes a whole bunch of things into account.
Despite the fact that there’s a ton of AI computation going on for each decision it makes, the real time that the AI takes is a tiny fraction of a second…computer players take their turns instantly, without you having to wait for them to think through all of these scenarios. Three cheers for living in 2016 where technology has allowed AI’s to make these complex determinations so quickly. In 10 years, we’ll look back at this time as when the AI’s for most games really was good enough for all practical purposes, and that we should have stopped with the technological advances at this time. That is, if the hopefully-benevolent robot overseers of 2026 allow us to dwell on the past at all.
The core game, including 98% of the rules, a workable AI, graphics, and multiplayer (through pass and play) was in place by the end of August last year. Releasing by the end of 2015 seemed like a reasonable goal, as we only had the following to do: Add the campaign mode, Enhance the UI, make the AI polished, and squish any outstanding bugs.
Each one of those things, however, took about 2 additional months of work. In hindsight, August 2015 Ted was such an optimist!
While players liked the campaign mode in the Suburbia app, we knew that it wasn’t as good as we had originally wanted, and that we wanted to do something better…a lot better…for Castles. While Jeremy was busting his butt coding the basics of the game during those first few months of development, I went to work on a campaign PRD that outlined the direction of the campaign; how it would work in terms of different levels, rewards, unlocking, and length, and also the components of the campaign that would make it interesting. We wanted to make each campaign level unique, with different goals and compelling gameplay, so that each new level that players opened up would be fresh and exciting.
The first thing that Jeremy did with the campaign was to create a campaign building mode for me, so I could have the tools necessary for level design. That was a huge help, as it allowed me to test different scenarios and try out all sorts of things that would have been impossible otherwise. Throughout development, the campaign builder got more and more features, to the point now where it’s really just a tool that takes what I’m envisioning for a level and materializes it in the app, and makes it pretty straightforward for Jeremy to implement in the actual app.
Designing the levels was as close as I got to my game designer roots during this process, as each level really is its own kind of game, bracketed by the framework of the basic Castles rules. In many ways, it reminds me of designing AoS/Steam expansion maps (of which I did a few dozen back in the day), where all you have to do is change one or two rules, very carefully and deliberately, and the result can totally reinvigorate the base game. Because each level can be any size and shape, I created an Illustrator document that allows me to quickly design the base shape, size, and location of key rooms (that’s right, in the campaign, some levels start with rooms already in place). I also designed a spreadsheet that captured all the key information in each campaign level, every thing from number of opponents to which rooms are available to what the specific crown goals are.
Meanwhile, Jeremy came up with the basic concept and “story” of the campaign, which follows you, a novice castle builder, as you work your way up the Middle Rhine in Germany building castle after castle, each of them based on the actual castles that line both sides of the Rhine. I’ve been to several of these castles on side trips from my annual trip to Essen each year, and while the castles you’ll be building are quite different than what’s currently available for touring, Jeremy managed to capture the essence of the historical flavor of those castles, including a little introductory blurb on each one.
From September through most of April, the tutorial and campaign levels were continuously tweaked and redone, and I’m super happy with the way they turned out. It really adds a lot to the Castle game playing experience and makes the app hugely replayable.
Not only that, but we have plans for additional levels to be added to the game after it is released. I’ve already been working on the designs for a few of them.
The UI had been workable up through August of last year, but we had a huge list of things we wanted to add or change to make it better. Little things like how the end game score was displayed, how the player interacts with the new match options, how help should be available, what the background of the tiles should be, sounds, collapsing the contract board so that phone users could have more screen real estate, tapping rooms to temporarily zoom them right on the contract board, and so much more. Dozens of little things that add up to making the app feel as polished as possible.
The amount of work required for each little change, however, can’t be overstated. It’s one thing to agree to implement a UI feature, but then there’s the “how” that feature is implemented, the actual coding to get it to work, the testing to make sure it meets our expectations, modifications to the original design and more coding to make those modifications happen, and then of course fixing all of the bugs which pop up throughout that process.
As the project drew closer and closer to completion, Jeremy kicked into overdrive to make sure every little aspect of the UI was as perfect as possible. All sorts of little extras started appearing in builds…some of these things we had discussed, others he took the initiative on and just did them. Fortunately, Jeremy is one of those developers with a knack for both UI and graphic design, so it was incredibly rare for me to see a new feature and spit up on it….most of the time I was pleasantly surprised, like in the last few builds where a preview of the campaign level screen was shown (I had pinged Jeremy for a while about that possibility, but figured we were too close to release to get that in place), or when the music for each of the campaigns had a different starting point from a very long playlist.
Finally, even though we decided to forego online multiplayer (and in hindsight it was a good decision, as it allowed the rest of the game to be much much better as a result), Jeremy hooked up Game Center (iOS), Google Play Games (Android), and GameCircle (Kindle Fire) to track a variety of achievements within the app. It’s yet another little thing that makes the app feel even more polished and refined.
Polishing the AI
After testing the app for months and months, there were a lot of areas where I thought the AI could be improved. Of course, many of those things, while conceptually little, ended up being exceptions that happened in various circumstances. Getting the AI to place hallways properly, with all of their doorways and possible orientations/locations, was particularly tough, and even now once in a while the AI will place a hallway someplace that makes you scratch your head. The math involved with valuing room tiles that were related to the Kings Favors was another area that needed work: For instance, while it’s worth 2 points to be in first instead of tied for second (8 vs. 6 points), it’s really a 4 point differential between you and the player you’re tying with. If the AI is already crushing that player in points late in the game, the 4 point differential isn’t important, but the 2 additional points still is.
The AI process for the master builder also took some extra time. The math was all in place, but it still would price rooms unexpectedly, which felt random, and not all that smart. That required a lot of tweaking, but now I’m pretty sure that most players will be constantly amazed that the computer player always seems to price the rooms you want either just barely within reach, or, if it’s the perfect room for you, at a price you can’t afford. The only people in real life who do this process that well are your AP-prone friends, which isn’t an issue in the app (none of the computer opponents have any AP issues, fortunately).
All in all, the AI turned out really well, and while a really good human player can win some of the time, you’ll find it to be a good challenge.
Bug Squishing & Playtesting
The longer the development of any software project goes, the more bugs get entered into the game. Well…sort of. In my 20+ years of Product Management experience, it’s not just the time, but the amount and kinds of additions and changes that happen over time that have the ability to make bugs proliferate everywhere, often in places that are unexpected given the nature of recent changes.
Learning from Suburbia, where we did a very small amount of external playtesting, for Castles we brought on a whole bunch of beta testers back in January of this year, and then tripled that number in March. Getting feedback on the app from testers with different devices was great, especially since now we aren’t just supporting iOS and Android, but we’re supporting phones and tablets on both platforms. While we didn’t cover all of the possibilities on Android thanks to the ridiculous number of different devices out there, we had a good cross section that should have caught the majority of device-specific bugs.In addition to just finding bugs, the playtesters served another, really valuable purpose for us…they helped us get the campaign to just the right level of difficulty. My personal preference in campaign modes in games is that completing them should be really really really hard, so much so that most people will *never* complete them fully, or earn all the achievements/rewards for them, but that some expert players who stick to it will indeed be able to get them. If you aren’t tempted to throw your device across the room because you just can’t quite get a level, it’s not difficult enough. Fortunately, Jeremy isn’t nearly as hardcore, and between the two of us, we brought the difficulty level of the campaign down to something that can reasonably be finished by pretty much all players somewhere in the 5-10 hour timeframe, with a ton of replayability, as each level is totally different from every other level. When you do complete a level successfully, you always have the option to play it again to try to do even better. We also included a reset button for the campaign so if you do complete it, you can go through it again, and see how much better you’ve gotten since your first try. Our playtesters let us know which of the campaign levels were fun, which ones weren’t (some we scrapped and replaced), and if each of them are indeed completable in a reasonable number of tries. The end result is a campaign that’s super-compelling with an ever-increasing level of toughness as you make your way through it.
Release process and publication
To shed a little more light on the release process for apps, traditionally, Apple has taken 7-10 days to approve a new iOS release. Of course, there is the possibly that Apple spits up on the submission because of an actual bug or because one of the multitude of mostly-unnecessary guidelines required from Apple isn't addressed. So upon submission to Apple, we usually expect to have to wait at least a week until the app has been approved and is available in the App store.
Like most developers who plan on launching their product on all platforms simultaneously, priority #1 was getting the iOS version done and submitted due to those typical long review times. So our primary focus with the last few builds had been on iOS bugs and Game Center implementation. Once we had an iOS build we felt was good enough for submission, it was submitted to Apple, and then the focus changed to Android devices, including Kindle Fires. The Google Play submission process is very very fast (within a few hours, usually), and the Kindle Fire submission queue takes less than 24 hours to get an approval, so we gave ourselves about a week after the iOS version was submitted to squish any Android bugs we could find with Google and Kindle devices. And then the unthinkable happened…Apple approved the app less than 48 hours after it was submitted! It turns out that they’ve shorted their review time significantly recently. It’s nice to see Apple putting their truckloads of cash to good use for a change by staffing up the app review group.
As I finish writing this designer diary, there are less than two days before Castles of Mad King Ludwig is released, and we’re stoked to see how players respond to this labor of love. On a related note, if you enjoy the game, please take a few minutes to rate and review the game on the appropriate store…the number of people who rate the game relative to the number of downloads is always a tiny fraction, and for games that the general public hasn’t heard of, those star ratings and customer reviews are their only exposure to what people think about the game. As a boardgamer, I suggest that you do this for all boardgame apps…the more ratings there are (especially for good, solid games), the more downloads of those games will happen, which funds developers allowing them to produce more and better boardgame apps. It’s a way you can help prime the pump and ensure that the boardgames we all love continue to be converted into great apps!
Thanks for reading this…I hope this provides some insight into the development of not just the Castles of Mad King Ludwig app, but other boardgame apps as well!
Castles of Mad King Ludwig is available now:
- iOS Universal, $7
- Android, $7
- Kindle, $7
Among the best things in life is playing printed games in person with family and close friends. When those are not convenient we like iOS Board Games. News, reviews, previews, and opinions about board gaming on iPhones, iPads, iPods and even Android devices. (iPhone board games, iPad board games, iPod board games, Android board games)
Archive for Ted Alspach
- [+] Dice rolls
30 Oct 2015
If you aren’t familiar with the app, it’s free for iOS/Android and works on phones and tablets. It’s had one major update already, when Daybreak launched, and at that time we added several new features, but for the most part they were all “add-on” features - they just were bolted on to the app however they fit. For Vampire, the app has been totally rethought and redesigned, while ensuring that we kept the things that people love about the app: ease of use and quick in-and-out gameplay.
As a game designer, I spend a lot of time reading reviews and comments about my games on BGG. It’s a little narcissistic if you just read the comments for people who rate the game a 10, and it can be downright depressing to read the 1 2 3 rating comments. But I read them all, because I want to know what is working and what isn’t for players of my games, so I can learn what I need to do to better next time. For games with a companion app, like One Night, I also read Google Play and iTunes reviews to see how the app is being received.
What’s good, what’s bad
The app research resulted in the following takeaways for the app:
Pro: Everyone loves Eric Summerer’s voice work. Player who noodle with the settings like Ashly Burch’s voice work as well, but Eric takes the crown here.
Pro: The app is super convenient, and the overall UI works really well.
Pro: The app is free. People love free.
Con: The nighttime narration can take too long sometimes.
Con: The Doppelganger role is confusing (this is commentary from both the game and the app).
Con: New players are confused that all the roles aren’t shown in the app (Villager, Tanner, Hunter, Bodyguard, Prince, Cursed).
Con: There’s no way to pause the narration and/or timer when an out-of-game event occurs (doorbell, baby crying, etc.).
Con: It wasn’t obvious where to go to change the Game Timer settings.
Con: It wasn’t obvious where to change any other settings, either.
There were also two issues that were (in my mind) egregious enough to fix them in an minor bug-fix update:
Issue: There was a bug on Android that prevented users from changing the hardware volume while in the app. While this didn’t make it unplayable, it caused a lot of issues for people who launched the app with their volume very low initially.
Issue: One of the new Daybreak app features, which added a new screen of dialog (and related narration) to every night right before players were told to wake up (it asked them to move their cards around slightly with their eyes closed), was loved by some and hated by others. Of course, the haters were very vocal about their displeasure with this new feature.
The Android sound bug was simply a bug that was easy to fix (I’m not a developer, and with my background in product management, all “little” bugs are easy to fix…hahaha). The “Move your cards around” issue was different. Because some people loved it I couldn’t just take it away, so instead a new option was added to the options screen that allowed players to turn it on and off as needed.
Getting the app prepared for Vampire
With my list of pro’s and con’s I started making a list of the enhancements I’d like for the app, adding screenshots and as much detail as possible. Of course, I also had the new Vampire-specific functionality to deal with, which meant even more new features and changes.
The most critical things with any One Night game release-related app enhancements are (1) to add all the new roles and (2) figure out how they integrated with the existing app roles. In addition, I really wanted the new narration in place early for testing purposes, even before the final roleset was determined; with Daybreak I waited until late in the process to do this, and it resulted in lots of late-stage changes to gameplay that put more pressure on me than I was comfortable with.
I sent the first list of role narration to Eric Summerer back in December 2014, and because he’s a consummate professional, he turned them around like he always does in a few days. I had the initial set of narration audio on December 10th, and after my developer turned it around pretty quickly, that allowed me to do testing of the app AND the game right away.
The above paragraph makes it seem like I got the audio files, gave them to my developer, and I was able to test, just like that. Nothing could be further from the truth. Prior to getting the script to Eric, I had to figure out the entire order and logistical mess that is now One Night Ultimate [lots-of-stuff]. Some of the ordering was very apparent, because most of the new roles that add Marks into the game happen in a pretty solid block. But others had to be squeezed in between other existing roles. Not only that, but there is a ridiculous amount of logic that is required for the app to spit out the correct narration based on various combo’s of roles. Every audio file/screen has a series of “show if X is in the game” and “Show if X is NOT in the game”. For instance, the narration that tells players to look at their marks halfway through the night only plays if one of the new Mark-adding characters is active…so those characters had to be listed out for that line. Some of the role interactions are incredibly complex too: The Apprentice Assassin and Assassin narration is very different if one or both of them are active.
Then there’s the Doppelganger. Hardcore One Night players love the Doppelganger. I love the Doppelganger, too. However, with Vampire, the Doppelganger has resulted in spaghetti logic that required a two-story whiteboard to comprehend, let alone figure out. There were times that I seriously considered placing a line in the Vampire rulebook that said “You can’t use the Doppelganger with Vampire” which would have saved a ton of time and at least one punchboard from having to be included in the shipping box. But I stuck to it, and worked out most of the kinks (there could still be some edge cases out there that no one has found yet, but I’m sure that the previously-mentioned hardcore players will let me know when something isn’t right).
Here’s a look at a portion of the spreadsheet I use to track the narration in the game:
The other issue that I had been in denial about was that with all the new characters in Vampire (and any unlocked stretch goals during the KS campaign), the roles wouldn’t fit on the screen. They just barely fit for Daybreak/Bonus Pack 1, and they had to be reduced in size in order to work there. I didn’t want to go any smaller than the Daybreak edition of the app, so some sort of way to have more roles would have to be incorporated. Ultimately, we went with a scrolling list, that’s ordered by night wake up order. But even with that, I knew that the majority of players would have just the base set, or some combination of games that weren’t all of them, and to make everyone scroll through characters that they didn’t have was bad design. Buttons across the top of the app that show the different games/bonus packs were the solution to that, allowing players to turn entire games on and off at once.
The New Features
I then went through and focused on each of the major cons I found when doing my research, attempting to solve them in a way that wouldn’t compromise the integrity of the app.
Expert Mode: To solve the “nighttime narration takes too long” issue, I developed a special mode called “expert mode” where the narration is limited to critical directions, and not the long, drawn out rules that usually are played. This effectively cut nighttimes down by about 50%. The werewolf screens, with this option on are “Werewolves wake up. [pause x seconds] Werewolves close your eyes.” If you change the role timer to 0 (or just turn it off), this speeds through the night like you wouldn’t believe. Of course, to do this required a whole new set of audio files and screens (yay, more busy work).
Verbose Doppelganger: To address the “Doppelganger is confusing” issue, I chose to address the single most difficult aspect of the role: remembering which roles go right away (when the Doppelganger first wakes up), and which ones are done later. With this option on, the narration will list the Doppelganger roles that should do their night action right away. It does this by listing all of the roles that are active and should be done immediately: “Doppelganger, wake up and look at another player’s card. You are now that role. If you viewed the [Seer], [Robber], or [Troublemaker], do your night action now.”
All Roles Available: The app was designed to assist with nighttime narration. From that point of view, only the roles that actually wake up at night needed to be in the app. However, that point of view isn’t shared by players new to the game, and feedback from new players was that the app was “missing” roles, because there was no Villager, Hunter, Tanner, etc. Many users rated the app low as a result, saying it was missing roles. Initially, those kind of comments (and their ratings) can seem irritating, because “that’s not what the app is for” comes to mind. But in retrospect, just because that was how the app was originally designed doesn’t mean that it syncs up with users’ expectations. Initially I thought I would just add the missing roles allow them to be clicked, and (since there isn’t a night action for them) just ignore them in the app.
Then I realized that here was a golden opportunity to address another issue that I personally had run into, but just chalked it up to user error: Having the wrong roles selected. When this happens, it’s halfway (or more) through the night when everyone realizes that somethings not right, like a role that should be called was skipped, and it requires a total redo: cards have to be shuffled and redealt, and the night has to start over again. In fact, I was often doing a lot of math in my head when setting up the app each night: I would count the number of players in the game, add three (for the 3 center cards), and then subtract the non-waking roles, then count the number of selected icons in the app. With weird math like that, it’s no wonder that screwups happen occasionally.
The new feature lists *all* the cards in the game, including duplicates (for instance, there are two werewolves, so now there are two buttons for werewolves). A number appears within the Play button that indicates how many roles are selected. As long as that number equals the number of cards on the table (including the 3 center cards), you’re good to go.
Pause: This seems like a little thing, but adding a pause button to the app so that it stops the narration or timer wasn’t easy. The result is a much more flexible app, and it also provides a way for a group to say “before we vote, let’s just…” and still have the app count down the vote.
Game Timer quick access: The first version of the One Night app allowed players to change the game timer right on the main screen. The Daybreak version pushed that handy adjustment feature into settings, requiring the user to tap the settings button, and then tap the Edit button of the Game Timer options. Not terrible, but definitely not convenient. The new app provides the ability to access the Game Timer directly by pressing and holding the game timer icon, displaying the Game Timer settings instantly.
Gear instead of i: The first version of the app had very little in the way of settings, and was mainly about providing info to the user about the app and game. Thus, a lowercase “i” was chosen to access preferences. Replacing the “i” with a gear was a welcome change, and makes it very obvious where settings are.
2X Complex roles: Testing showed that roles like Cupid and the Priest, where players have to move several items around (in both of those cases, 4 items) take longer than others at night, so there's now an option to double the length of complex roles like those.
The first version of the app shipped with a crickets chirping background. You could turn it on or off (or change the volume of the crickets). Functional, but a little annoying at high volumes (Tom Vasel’s review of One Night had the background sound on and sounded terrible). The Daybreak version of the app upped the ante by providing two different musical compositions (created by yours truly from Logic Pro libraries) as well as wolves and card shuffling noises.
For Vampire, and really for the whole series, I wanted something that was uniquely, distinctly One Night, so I started talking to composers, and finally settled on one who seemed to get the spirit of the game. The first track he delivered was the Fantasy track (available on the current version of the app), and it had a strong set of melodies. So strong, in fact, that I began humming the melody and eventually came up with words to it, which we ended up using for the One Night Music Video.
Once the basic melody was locked down, it was time to come up with interesting variations: I had him create a whole bunch of them: A wild-west Spaghetti Western sound, a horror movie soundtrack (you can hear part of it at the beginning of the Music Video), Vampire Rock (think Lost Boys and From Dusk ’til Dawn), disco and others.
To accommodate all the new tracks, the background screen of course had to be entirely redone.
Final voice files
Some of Eric’s voice files were cobbled together just for testing purposes, and those had to be replaced. Eric supplied more then 130 new audio snippets for the app. Ashly Burch provided a complete set of audio files for the update as well.
This is the final step. All the new features are are being tested thoroughly to see how they’re working. The vampire logic is the toughest to test, and while most of that is complete, the roles weren’t finalized until just before the Kickstarter, so the logic needs to be retested with the roles that didn’t make the cut taken out, and with the roles that have been achieved via stretch goals in. Some of the other new features build on that logic, so they have to be entirely tested as well.
Finally, testing will be done on as many devices as possible, so we can do a simultaneous iOS/Android release.
Shipping is soon!
As you can probably tell from this writeup, a lot goes into making a companion app for a game like One Night Ultimate Vampire and One Night Ultimate Werewolf. But it’s definitely worth it, as I know the experience of using this app makes the game that much better!
- [+] Dice rolls
Possibly the most exciting thing about the Ultimate Werewolf: Deluxe Edition Kickstarter campaign (ridiculously overfunded at $138K) was that we met the Ultimate Werewolf Timer App stretch goal early on. I lined up a developer and started finishing up the spec immediately and made sure the developer could complete the app for a simultaneous release with the game (currently on track for June).
This tells the story of how the app was designed from the ground up. If you just care about what’s in the app and don’t want all the backstory, skip down to the section “So, how did the app end up?” which provides a capsule summary of the final app along with screenshots.
A timer app for Ultimate Werewolf? Really?
One of the best things I've ever done was to start using timers when I moderate Ultimate Werewolf. I've been using an iOS app called "Timer" (really) that for $4.99 did all sorts of things I didn't need it to, and didn't do some other things I wanted it to, but I jerry-rigged it and got it working. And the response from players who took part in those games that had a timer has been overwhelmingly positive as well; the added structure of timed days allowed villages to focus on the job at hand and spend less time on devolving tangents. At various events where I moderate, players will often come up to me and go out of their way to thank me for using a timer. In fact, I believe that the use of a timer is essential to get those players back who've shied away from Ultimate Werewolf in the past...not only does it keep the game moving, but it's a godsend for eliminated players who are watching the remaining events unfold.
While the Ultimate Werewolf rules don't say it's mandatory to use a timer, I strongly suggest that you do, devoting an entire page in the rulebook (in the new edition) to using one effectively. Of course, it's easier now because the Ultimate Werewolf Timer app will be available when the new version of Ultimate Werewolf ships this summer...and this app absolutely rocks.
I've designed apps before, both as games (Suburbia) and game utilities (Start Player, One Night Ultimate Werewolf), so I was able to use that experience along with my use of all sorts of timer apps and desktop timer applications when designing the Ultimate Werewolf Timer app.
Defining the Requirements
Before the Timer app was designed, however, the first thing I did was list all the things I wanted from an Ultimate Werewolf helper app, that would help moderators with their games of Ultimate Werewolf. A full-blown moderator app is definitely something I'd like to do someday, but of all the components of that idea, the most critical one was a timer app that really worked well for Ultimate Werewolf...it was the core of the moderator app idea.
The one aspect of the Ultimate Werewolf Timer app that had to be in place that just wasn’t available in any commercially available app was decrementing day times. In Ultimate Werewolf, each day after the first should be shorter, forcing the game to move along quicker and quicker. This is necessary for two reasons: (1) There are less players that need to speak and (2) there are more players waiting for the game to end. A rough guideline for timing Ultimate Werewolf games is to make each day about 30 seconds per player, so if there are currently 10 players in the game, the day should last 5 minutes. The next day, assuming the village eliminates one of its own via a vote and the werewolves eliminate a player at night time would have 8 players, so the day would then be 4 minutes long, and so on.
Because of this requirement, there needed to be 2 settings present: First, the length of the first day. And 2nd, the amount that the days get shorter by each day. I quickly determined that it was easier to let the moderator choose actual times for both of these settings than to simply choose the number of starting players and do the (very easy) math for them; because players would still want to adjust that very arbitrary “30 seconds per player” guideline, and then there would be a second setting for that, and then there would be the educational requirement of stating why that number was important.
But to throw a curve into the mix, there was another variable, which was that the first day of any Ultimate Werewolf game is a little longer, as there are traditionally player introductions and initial discussions which often take longer than Subsequent days. How much longer (if at all) is determined by the group. So now a third setting needed to be added: “first day”.
At this point, I put all this onto a rough layout with the first crude mockup like this (this included the idea from the original “moderator” app idea which tracked the number of players in the game):
So I had my basic settings, but I also needed to know what I would display on screen while the timer counted down. Obviously the timer, but I thought it would be nice to show what day (of the game) it is, which can help players track who was eliminated and when. I also needed buttons to allow the moderator to move to the next and previous days quickly. And finally, if the discussion is going well, I might want to add some time to the timer “live” or take time away if there’s dead silence. So here’s the mockup for the first “day timer” screen:
At this point I put the app design aside to focus on other things.
The First Major Revision to the Design
A few months later, inspired after moderating a few games of Ultimate Werewolf one night, I started working on the PRD for the app, and the actual design of the screens. At this time I was working in a portrait orientation for the setup screens, with the idea that you could rotate the device for the timer display to horizontal or vertical orientation when it was running. So the first mockup for the setup screen looked something like this:
The timer screen itself looked something like this (note that it now has a Pause button, a critical element that had been missing from the original mockup). This design was a weird combination of the typeface for the then-not-quite-released-yet One Night Ultimate Werewolf game and the graphics from the Ultimate Werewolf Ultimate Edition game:
At this time I also included a settings screen, which at this point was simply a sound control settings screen:
Again, this was shelved for a bit while I worked on other projects.
Ultimate Werewolf: Deluxe Edition and Revision Two
I had wanted to do an updated version of Ultimate Werewolf for a while, but hadn’t gotten around to it. The original game was out in 2007, and the Ultimate Edition followed shortly after in 2008. I wanted to do a five-year anniversary edition with new (or updated art), but as 2013 started drawing to a close, I realized I wasn’t going to make the date in time. And the more I looked at it, the more I realized I wanted to change with the game, so the Deluxe Edition was born. I decided to make the timer an integral part of the new edition, and when the Kickstarter project was being developed, making a stretch goal to help cover the cost of development for the app seemed like a perfect match.
Of course, with a new design for the cards, the app I had designed wasn’t going to really match, so I went to work redesigning the app, and really digging in deep to make sure that the app would be the the definitive timer to be used with not just Ultimate Werewolf games, but all werewolf games.
As I looked with a critical eye at the planned timer, I realized I had missed two important elements: Night time and player defense. In Ultimate Werewolf, several things can happen at night, including werewolves deciding who to eliminate and the Seer picking someone to inspect (she learns if that person is a werewolf or not). So a timer was added for that phase. When a player is accused of being a werewolf during the day, quite often I would stop the time and allow the player to defend themselves and answer questions from the other players. With time stopped, however, that could take a long time, and players could often devolve the conversation into totally unrelated areas to the point where some players would forget who is “on the block” (nice for the accused, but bad for the game). So I added a defense timer as an interrupt; the idea is that when there is an accused person, the moderator taps the Defense button and a new timer starts just for that person’s defense. When the defense time is up, players must vote on the accused. Afterwards, the day timer continues from where it had been prior to the Defense; if the player is eliminated the moderator can press “next” to get to the night timer.
I continued to revise and modify the feature set. I dropped the ability to change orientation because the timer looked much better (and was easier to read) in horizontal view, and developing it for vertical view was an unnecessary use of development time. I added a few other niceties, like hiding and showing most of the elements on the screen and a rising sun animation with floating clouds, and then submitted the PRD to the developer so he could start working on it.
Feature additions and changes during development
The first few builds from the developer were focused on getting the timer right, including the ability to adjust the time “live” and it took several iterations to get to the final set of controls: tapping the “+” increases the time by 00:10, while pressing/holding the “+” increases the time by 01:00.
I used a projector in one of my Ultimate Werewolf tests, and discovered that in a brightly lit room, the contrast was acceptable with the white numbers on the blue background, but it wasn’t great. An option was added to settings to hide and show the background so that the contrast would be as extreme as possible in those situations.
A few of the tests resulted in a couple of players being ardent clock watchers, and as a result of them informing the other players of the time remaining every 10 seconds (or so it seemed), the ability to hide the time in settings was added, for a more natural experience of watching the sun rise and fall each day.
With the feature set locked down it was time to make some cuts. I haven’t included any info here about the features I wanted that we cut from the initial release in order to make the release schedule, but as always, it’s a painful process with much soul-searching, despair, and occasional cursing. The app is currently in testing, with only a few features not implemented yet, but it is definitely on track to be available in June as scheduled.
So, how did the app end up?
The most impressive part of the app is the one you (and your players) will be looking at all the time: the Day Timer screen. This fully-customizable screen (you can turn most elements on and off in Settings) displays the time left in that day in minutes and seconds in giant numbers superimposed on a background scene of trees and a nice summery sky with clouds floating by lazily. It also shows the day, the “real world” time, and a series of control buttons at the bottom (below the treeline) allowing you to go to a special “Defense Timer” (that’s right), pause the time left, or skip to the previous or next timer.
But the one thing you can’t see in a screenshot is the movement. The Sun subtly moves across the sky, rising at the beginning of the day and setting at night. And what’s super cool, if you don’t want the countdown timer to display, the Sun can still move across the screen, giving a much more analog feel to your games…the village will slowly notice that the sun is setting, and rush to eliminate a werewolf (they hope).
During the day, you can opt to use a Defense timer when a player has been accused of being a werewolf. That gives them a very limited amount of time to defend themselves and for the rest of the village to ask questions of them before the vote. When the Defense timer is up, an angry mob can be heard (though all sounds are customizable), and you can call for the vote immediately.
At the end of the day, there’s a night time timer; this is great for those moderators who take FOREVER to get through a night phase (I’m talking to you, Frank DiLorenzo, my Night of the Black Moon co-author), and also works so you can be hands-off of the timer (one of the things I’ve run into as a moderator is that when recapping the events of the night for the village first thing in the morning, I forget to start the timer again). After the night time timer is up, the next day starts automatically.
After the game, the timer setup you used is remembered and you can just start another game with the same timers, or you can make adjustments in the easy-to-use Setup screen. This is where you turn on and off things like how quickly the time of each day gets shorter after the first day, if you want there to be a separate Defense timer and Night Time timer, and how long each of the timers should be. Find a setup you really like? You can save it and load it in the future, even if you totally muck around with the times. You can save any number of sets of times and load them this way.
On the Settings screen, you can choose which sounds sound for which alarms, to turn on and off display items, and to set your device to stay awake while the timer screens are present (though it will still fall asleep while in the setup/settings screens, so you don’t have to worry about quitting out of your app when you’re done using it).
The app was developed on both iOS and Android platforms simultaneously via Corona, but the iOS version will be out the door first, with the Android one following closely thereafter. Ultimate Werewolf: Deluxe Edition should be available in stores this summer.
And yes, the app will be free!
- [+] Dice rolls