GeekGold Bonus for All Supporters: 98.77
39.6% of Goal | left
Archive for | Back Stage
Preorder One Night Ultimate Werewolf now from www.beziergames.com
One Night Ultimate Werewolf
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, Inc., 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, Inc. 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.
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.
Completing the basics
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 document I created pretty much had everything, including the sink in the Kitchen food room. As I look at that document now, it’s interesting in that very few items made it through to the final campaign, due to time, technology, and design limitations. One of the basic ideas that did make it through was that the tutorial would consist of a bunch of super-easy campaign levels that walked the player through the basics of the game. That stayed, and it’s pretty effective (If you’ve never played Castles before, be sure to take your time and read the helpful notes before each level in the tutorial). Getting through the tutorial gives you a bit of a head start on the campaign, too. In fact, one of the campaign levels can only be accessed if you complete the tutorial…but don’t worry, you *can* zip through the tutorial in less than 10 minutes.
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.
How the castles (campaign levels) are unlocked evolved over time. As a game designer, I had originally devised an intricate, completely insane system that could only be understood by someone with a PhD in Mathematical Game Theory. Both Jeremy and I slowly modified this system to a much more accessible and understandable series of rules for unlocking levels. Early on, you need a certain total number of “crowns” to unlock each castle. That changes mid-campaign when you have an option of going in one of two different directions, one which features multiplayer games while the other feature single player challenges. These are accessible only if you gain at least one crown in the previous castle. Complete either of the two new paths, and you can continue with the final leg of the campaign which now requires two out of three crowns to proceed further. The campaign culminates in an awesome giant single player castle, where the final castle you build will have upwards of 50 rooms!
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
Read more »
Hello Dear Readers,
In the process of full disclosure, I wanted to update you on my new job.
Since helping found this blog on BGG, I have begun to shift my career from its origin to a focus on gaming. This has involved doing several freelance projects, additional writing gigs, and now it is taking a fulltime swing. BGG has really provided me with some great opportunities and I owe a lot to you the readers.
As of today I am starting as Marketing Director at Shenandoah studios. My work will involve doing PR work for them but I will also be focused on better serving existing users through community building activities. This is a great opportunity for me and a good first step into this industry.
My intention is to continue to work on the blog in my same capacity. Aldie has agreed to this. I love this blog and I love this effort. I also will not be reviewing any of the games from Shenandoah, but will pass those on to others on our staff. Otherwise our coverage of them will be the same as other companies.
With this, I am just now moving to Philadelphia and so you may see a few blips in coverage. I am excited to be a new area and I think all in all these changes in my life will actually give me more time to make the blog better.
Thank you for reading and I hope we can keep serving you the content you want.
Tell us about the current or future release of a board or card game app for a mobile device. If it is a board game app release or major update we will certainly mention it in our news and will possibly review it as well.
Click Here to Submit News About a New Release or Major Update
We are Seeking Testers For Our Voice Server and "Virtual Game Nights"
iOS Board Games wants to experiment with a Ventrilo server. The idea is that we would like to provide a place where interested people can go and use their headsets to engage in push-to-talk voice chat in a virtual "game room" and at size-limited semi-private "tables" while playing iOS board games online in realtime. The idea would cover both organized events as well as more loose usage 24/7.
After testing, we plan to gradually open this up more widely to you all. If you are a reader of this blog and are interested in voice chatting with other interested iOS board game players online you will get to try it out relatively soon. For now however, we're just looking for testers who can put up with a rough testing environment and give us feedback on how we set up and manage what users see when they connect to our Ventrilo server.
If you are interested in helping out with the testing, please GeekMail me.
Due to a series of very fortunate and unexpected events I now find myself attending Gen Con this weekend. I will be at the convention Saturday and Sunday. I have over 10 interviews planned and hope to pick up many others along the way.
I am very excited as this will be my first con. Look at me smile!
I will be updating Twitter constantly this weekend, so go ahead and follow us @iosboardgames. I will be posting impressions and thoughts about the convention as they happen.
I want to meet you, our readers. I will be in the exhibition hall most of the day and in the open board game hall in the evening. You will be able to recognize me by the dazed grin (oh and I will probably be carrying an iPad with me). Feel free to email (firstname.lastname@example.org) or geekmail if you would like to meet up. If you see me, please say hello.
This is a great opportunity to get some firsthand news on the future of iOS board gaming. Stay tuned to the blog and Twitter over the next few days to get the latest scoop.
So What About Android?
It is a question that comes up a lot when we talk about iOS board games. And not to make light of their differences, but it's a natural question given the number of Android devices out there and the similar mobile device capabilities and basic user experience--that of a touch screen mobile device capable of playing boardgame-style apps. For reasons that have certainly been discussed in many places, board game apps on the Android are still catching up to iOS but have much potential. We think this makes for the perfect time for us to begin covering Android board games. And to be honest, we're just darn curious about them!
Let's Cover It!
So as of today iOS Board Games Blog will begin covering Android and eventually other tablet/mobile device board game apps as well, in addition to our main regular iOS board game app coverage. Some of our reasons for expanding a little into this coverage include:
• because there is a demand (as evidenced by the cries for Android whenever an iOS board game app is announced or released).
• because we feel that what is essentially happening is that flat screen touch devices are becoming common and playing board game apps on them will become common as well. While this is a maturing activity on iOS, it is beginning to happen on other platforms, namely Android, as well.
• to simply cover iOS on the front page of a site dedicated to board games in general feels a bit parochial and we believe our placement somewhat obliges us to report a little more widely to benefit more than just those who choose iOS over Android.
We've Got Help
In our efforts to bring you news of Android board games, we've brought on some help in the name of Mark Webb who will be posting from time to time to keep us abreast of news related to Android board games. Mark is of course a fellow BGGer and an Android enthusiast who impressed us with his knowledge and understanding of Android and of course his willingness to share them with us and you.
Let's Go Pens!
One more win...Beat the Sharks!
We'll let Mark introduce himself in his own words:
Mark Webb wrote:
Hi everyone, I am Mark Webb--wwwebb here on the Geek. In 1999 I bought a Palm 3 PDA. Since then, I have played board gaming programs on various mobile platforms, my most recent being iOS and Android devices. Gabe and Brad asked me to contribute news and information about Android board gaming apps. I thank them and BGG for giving this opportunity to share my passion for gadgets and games.
We look forward to hearing all about juicy Android board game stuff and expect Mark will be dropping in from time to time (and probably soon) to fill us in. Welcome Mark!
Related Blog Changes
You will probably have noticed that we have modified our categories. This is to better help our readers select what they would like to read from our blog. Additionally, it will be clear in our posts which mobile operating system we are covering. And for now the blog's title will probably remain.
Though they will be under the same blog, we do intend to keep iOS and Android blog posts clearly separated so that readers interested in only one or the other may easily ignore or click "mark read" in their subscriptions. We do hope, however, that a cross-pollination of interest can eventually grow on both sides because, after all, we are all united in board games!
iOS Board Games Wants You!
You will have no doubt noticed that we've lately featured some guest contributors. It's our intention to feature even more in the future. So if you feel that you have got something to contribute to the iOS Board Games blog (and please, no product promotion), we would love to hear from you! Send us a GeekMail!
Through the establishment of the iOS Board Game Blog we have started to bring together a community of iOS Gamers. We are grateful for all of you and all that you contribute to this blog.
In order to more effectively and wholly use the online multiplayer tools provided us, we at iOS Board Games would like to use the community we have formed to create a system where fellow geeks can find players who are using the games they are using, add them as friends, and play online. The hope is to create a greater social experience around iOS board gaming, because of course board games are about social interaction. An online community of iOS board gamers would also allow for online tournaments and prize giveaways (yes, we may have prizes coming down the line).
The Problem as I See It:
Many of our favorite board game apps have excellent online multiplayer systems. Some use Open Feint, like Ra or Through the Desert, or Game Center, like Neuroshima Hex. Others have developed their own systems that work great, mainly Carcassonne and Samurai. All of these systems allow you to play with strangers or with friends. However, in many cases games you play with friends have more options. For example (correct me if I am wrong), in Carcassonne you can only play an asynchronous game with friends, all quick play games are 90 second turns. Also playing with friends allows you to track more stats in many games.
A greater online multiplayer base for these games will help the players and the developers. It will also encourage new developers to put an emphasis on online multiplayer in their apps. Currently there in most of these board game apps there is not system to find friends, there are no lobbies to meet in and in a sense there is a lack of community. In some cases, like Viking Lords, there are many stalwart fans of the game but the multiplayer lobby is almost empty. If I want to find friends to add to my online games where do I go? If I knew I could find friends online when I opened my app, it would encourage me to use the app more often.
StarCraft is a great example of a multiplayer system. In the latest version of Battle.net you can connect directly with Facebook to see which of your friends are playing the game and add them to your friend pool. You can chat with these people, party up, and play games together. Yes, I can and sometimes do play games with random people, but knowing I have friends I am familiar with online draws me to the game more often and I see it is a social gaming experience, rather than just a gaming experience.
To my knowledge there is no easy way to find BGG friends to add to your apps. There have been attempts to create forum posts for the particular games but there is no centralized location.
Many Ideas, No Solution:
We need your help. We have many ideas on how to do this but we have yet to stumble upon a great solution. I will share with you our current ideas and please give us any input you have in the comments below.
1. Individual Game Forums: We can make a post in each forum where fellow geeks can list their usernames. This gets the information out there, but does not centralize it or create a community feeling. This is not a good idea, but I just included it because this is more or less a brainstorm.
2. A Geeklist: Each item on the geeklist would be a separate game. Players would then comment on the items in the geeklists with their usernames. This would centralize all the information but could become hard to handle. Also geeklist owners do not have the options of deleting comments, therefore if someone posted something silly that wasn’t a username, it would be hard to clean up.
3. Separate Blog posts for each game: We could make a post for each game, then those interested could comment with their username. It then gives us the power to manage and delete comments if needed but does not make the data very centralized. It also may required some digging through blog posts to find the game you want.
4. A Guild: We could set up a BGG guild for iOS Board Games. There could be posts in the forum for each game, players would then list usernames on those posts. This could also be a great place to set up and run tournaments. Also because Guild runners must approve people who join, this provides a good gate keeping system.
5. A Spreadsheet (Google Doc or non-cloud excel based): This can be combined with one of these other methods, maybe the blog or guild. In my mind a google doc spread sheet is great way to organize the usernames for many people. You can list your name. BGG username and then there will be a column for each game. It would be nice if there were a way to tie this in with BGG.
6. iOS veiwable, maybe an app: Whatever the method it should be viewable and usable on iOS devices. Many of these methods would be through the safari browser. If there were an app that could be programmed it could be useful as well, though this would take more planning and development.
These are some of the ideas we chave come up with. There are many tools available to us on BGG and other sources. We want to hear your ideas. What would be the best way to implement a player matching tool into the community? What ideas have we overlooked?
Let us know in the comments below.
Hello. My name is Gabe Alvaro (bgg username: blindspot) and I'm the other half of this blogging team. I'm a big fan of board games and Apple's iOS platform and devices, the iPhone, iPad and iPod Touch. Brad approached me about doing this blog and since it's on a topic that I am wildly obsessed with, I was very excited by the idea! It's my hope that through our collective efforts we can regularly blog about all things related to the iOS versions of the board games we know and love.
Here's a little bit more about me. I've been on BGG since December 2005. I "discovered" it after an old friend introduced me to Settlers of Catan and told me about BGG. I then used it to begin acquiring a number of quality board games that were totally new to me at the time and to kick a nasty World of Warcraft MMORPG habit. I've never gone back to video games since...until the iPhone came out.
Like many who come to BGG, I soon began acquiring board games by the online-retailer-free-shipping-box-load. I soon sadly learned, however, that my closest friends were all too busy to get together and play board games. So in the middle of 2006 I started local public board game group out of a local FLGS. It became the Berkley Board Gamers. That effort eventually attracted many local gamers and all was well in my gaming world. The game group is still going strong and flourishing better than ever, even after I pretty much handed the reigns over to one of our great fellow organizers.
I got an iPhone in December 2007 and in June 2010 I picked up an iPad. My wife gave birth to our beautiful daughter in August 2010. While it was a tremendous and life-changing experience, our daughter's arrival in my life had the effect of severely curtailing my game group activities. Though I was somewhat disappointed, I have simply shifted my interest a bit from cardboard to iOS versions of board games. I am, however, still trying to make it out to the game group once in a while. That's my board game group in the picture to the left, toasting the birth of my daughter on a night when I was unable to attend. Awesome group!
Since picking up my iPad last year I have been discovering all of the benefits to tablet board gaming. I have a very large list of these benefits which I will perhaps share in a future blog post. It should suffice to say that I have been devoting lots of my energy toward finding and playing all kind of iOS board game apps. I have also been thinking quite a bit about that activity and how it will change not only my gaming habits, but the gaming habits of others.
And of course I did not need a blog to begin chronicling trends that I have seen in the iOS board game app entertainment space. So far I have done a few living GeekLists including a list of Multiplayer (human) iPad games, some classic games clone lists, a list of games with asynchronous multiplayer features, a list of games that would benefit from asynchronous multiplayer features, and a list of unofficial "clone" iOS implementations of popular board games. I am attempting and mostly succeeding at keeping them all up to date when new games are released.
I look forward to using this blog as a central place to write about those trends and many more topics related to iOS board games. I'm excited to work with Brad and together share our observations and read the observations of others who are enthusiastic about iOS board games. So without further ado, let's get blogging!
Tue Feb 15, 2011 11:14 pm
Watch this space. Next update on 2/14...
Sat Feb 12, 2011 12:46 am