Category Archives: Board Games

Q&A – Porting Board Games to Digital

Posted on by

I recently answered a short barrage of questions by some non-technical folks researching the business feasibility of board game conversion. Since I gave them these answers freely, I thought I would also post them here. This is all based on my own personal experience, so feel free to exercise skepticism and I absolutely welcome your thoughts or differing opinions in the comments below.

1. What resources estimates and how much time do you feel is needed to do a strategy board game conversion to digital?

The answers for this question are as varied as the answers to the question “how much time is needed to do a mobile game?” In my experience, if you’re paying your programmer(s) what they’re worth (which is not a given in the gaming industry), you’re probably looking at a budget somewhere between 30k and 120k. Less is certainly possible with an experienced team, maybe with a code base they’re reusing, but it would raise a red flag for me. (I get a lot of potential clients who come to me with 2-5k, and I politely tell them that we can possibly make a prototype without graphics for that much.)

2. If using Unity as a gaming language, what do you think is involved in porting to another platform say from iOS to Android or vice-versa?

I am familiar with unity, but no expert. (So take this with a grain of salt.) My feeling is that android is more work, what with supporting all the different screen sizes and hardware/processor idiosyncrasies, so if you’ve already done that work, porting to iOS should not be that much more difficult. (Depending on the project, of course.) Going from iOS to android on the other hand could take longer, especially for complex games. (It’s going to depend on how many screens or “scenes” you’ve got to prepare in unity.)

3. Are you aware of what the maintenance/support costs would/could be, if so what do you believe is involved?

This is a great question! Not something a lot of clients think to ask. It’s easy to throw something in the App Store and forget about it, which is exactly what everyone else will do too.

There are obviously diminishing returns though, so I recommend planning a release with at least one maintenance update about a week or so after the initial lunch, and maybe evaluate then whether it’s worth doing another “feature” update a couple of weeks to a month later, also with a follow up maintenance update if your budget can stand it. If the game is still doing well at that point, it’s a good idea to plan to spend some time and push out littler updates as frequently as you can, more for marketing purposes than for any development related reason. All of this will require developer involvement, but it’s the person crafting marketing and messaging that should be spending the most time after launch. I generally think this is underestimated, and can easily be a full-time task.

4. Do you have an idea of hosting (storage/bandwidth) costs?

This is only relevant if you are hosting your own server for some reason. The game should have a website, which is another often overlooked marketing piece, but it will cost far more to create that than to maintain/host it. (Hosting fees shouldn’t run more than $20/ month, or you’re probably getting ripped off somewhere. I pay $5/month + $10/domain, but that comes with doing mostly my own support.)

If you ARE hosting your own backend multiplayer server, you can think of it as another domain name. (It definitely cost you more up-front to develop, so make sure your dev is including that in their estimates.) And unless the game is super successful, most hosting plans should include enough bandwidth. If you get to the point where you are paying ala cart for bandwidth, it still shouldn’t be more than a handful of dollars unless you’re at an extreme end of the spectrum, which is a problem you wish you will have.

5. What’s your thoughts on the digitization of family board games, and what may happen, and when?

Well, “family board games” is a term that might mean a bunch of different things, but here are some initial off the cuff thoughts:

a) it’s already happening to some degree, see Monopoly, Scrabble, Jenga.

b) The family market is much larger than the hobby market, but much tougher to crack. Quality is going to be a very important consideration, as is ease of use and first-run experience, including tutorials and teaching.

c) It’s possible that the aforementioned digital game examples are mostly getting played by board game hobbyists, rather than the general populous you’d expect to be playing a family game, which would be hard to prove either way unless you are the publisher of one of those games.

d) In general, (this is advice I like to give to anybody thinking about physical game conversion), the advantage that board game conversions have over their fully-digital counterparts is that there is already a population that knows about that game and to a lesser extent how to play that game. So the bigger that group, the bigger your advantage. How successful your board game conversion will be is very much influenced or enhanced by how successful a game you are choosing to convert.

6. Are you familiar with Steam, and would you recommend porting or building for that platform?

If you want to target desktops (OSX, Windows, or Linux), then I would highly recommend building working with Steam. I cannot make a recommendation about whether those platforms are viable for board game conversions in particular. Steam is a bit like Apple’s App Store and Game Center rolled into one, but cross platform for desktop games. There is an API that you as a developer can write to, and implement Steam achievements and various other social offerings.

7. Do you feel the effort to port from say Android/iOS phones requires more work to port to Tablet versions as well, or not?

Generally there is a portion of every project devoted to UI work. The amount of time spent will be different for every project, but generally I think it’s a higher percentage of the project for games than other application types. Let’s say, for a game, 50% of the development effort was put toward UI work. If you had only developed for one screen size at that point, you might have to re-do or at least re-touch much of that work. If you plan from the beginning of the project for multiple screen sizes, you can save yourself a lot of pain in “porting” to a different screen size, but it is still more work, no doubt about that.

8. What about PC/Browser porting, are you noticing or see the need/demand or value in doing that, and if so are you familiar with the effort in that case let’s say after a mobile version has been completed?

I do see this happen from time to time, though not with a lot of board game conversions. My concern would be monetization, since the folks who play web-based games are used to getting their games for free, and you have to have a very large active userbase (in the hundreds of thousands, from what I understand, although I’m no expert) to make money with advertising alone.

9. How many people do you believe is needed to convert and maintain a board game digital conversion, and what roles?

For a “full featured” conversion, I see the following needs:
– Programmer/developer
– Artist/graphic designer
– Sound Effects person and Musician (often can be the same person)
– Some kind of project manager or person making feature decisions
– A person (or team!) in charge of marketing

I have worked on a lots of projects where there were a couple of developers who split duties. This includes several apps with Tysen Streib, who would expertly craft the AI and game logic, while I handled all the rest of the application, including ultimately integration of his code into the project.

Another optional role I’ve found myself filling briefly at the start of smaller projects is that of UX designer. It is always nice to have a blueprint to work from, and good wireframes can really speed up development as well as help keep your team on the same page if there are multiple developers.

The mix and makeup of all of these roles will be different on every team, no doubt. There are certainly some indie developers who tackle all of these tasks for every project! I’ve found that keeping scope small is always a good thing, work toward manageable milestones, and you’re less likely to be surprised by how long something takes you to complete.

Some Tools for Tabletop Game Design

Posted on by

Below you can find my slides from the presentation I gave at last night’s IGDA Twin Cities meeting.

I think the presentation went okay, but I should have realized ahead of time how boring a topic spreadsheets can be. I saved the demos for the end of the talk, and by the time I got to them, I was really feeling the boredom radiating from all corners of the room. Anyway, I hope these slides are helpful to someone.

While preparing for the talk, I came across an interesting article about the history (origin) of spreadsheets called A Spreadsheet Way of Knowledge.

creativity is hard — tips for playtest feedback

Posted on by

I was musing on game design this morning, and came to a conclusion that I already knew both intellectually and intuitively, but one that I’m not sure I’ve articulated to myself previously: Game design is a creative endeavor. (With all the subjectivity and painful process woes that plague all creative endeavors.)

I’ve always just made games that I myself wanted to play, avoiding the entire camp of game design that suggests your players should be influencing your design. That may sound like an arrogant position to take, but at first it was borne more out of laziness and ignorance than anything else. Until I attended my first GDC in 2012, I didn’t even really realize there were people whose job was game design, and I certainly didn’t realize there were books written on it or — more importantly — people thinking about it academically. It was that revelation, more than any other, that has kept me going back to GDC; I find immense value in immersing myself in game design topics opinions and thinking for a week, not to mention all the networking opportunities.

But anyway, aren’t I also a player? In my opinion, I’m a player whose wants and desires are seriously under-served. (That means my games are probably for a small segment of the market, and I’ve made peace with that. I’m not looking for commercial success… if it finds me, awesome.) I’m not going to cave to the pressure to make games for someone else. Because essentially I feel like that’s compromise. And I think compromise kills art. My vision is no more important than anyone else’s, but it’s also just as important as everyone else’s. And hey, I’m the one making it.

So is this all one big excuse for not accepting constructive feedback? Partly, yes. These thoughts all come in the wake of showing off a new (-ish) board game last night at a local game designer meetup. I haven’t talked about this game publicly before, and this whiny blog post is probably not the place to start, but it was not received well. (In spite of many — at least 10 — fairly successful playtests previously.) Mostly, the feedback last night consisted of ways to change the game entirely, ways to take it in some other direction. Essentially, the playtesters (game designers, but for one) didn’t enjoy the game, and spent a good fifteen minutes after their play trying to brainstorm ways to “fix” the design. Almost all the player suggestions last night involved tearing up the design and making something new out of the pieces. This is something I’ve already done with this particular design at least three, maybe four times so far, and I’m actually very happy with where it’s at right now, so that option is not really on the table.

It’s hard not to take this kind of feedback personally. (Made more difficult by at least one of the designers in question having a lot of problems keeping his feedback constructive.) The whole experience really threw me for a loop, and I spent this morning struggling against an impulse to just put the game away and not think about it for a while.

Perhaps I can salvage this piece by adding a few bullet points about giving constructive game design feedback.

  • Be thoughtful — Generally speaking, think before you speak. As best you can, it’s a good idea to form complete thoughts before you speak them. If you’re offering up specific “fixes” for a perceived issue, make sure you articulate that issue before you offer up your solutions. Think about why something is a problem before you say it’s a problem. General “impressions” are generally not that useful, better to back them up with a “why” or a “how”.
  • Be courteous — Nothing invalidates your feedback quicker (or makes it harder to hear) than an insulting statement. Make sure your feedback is about the game, and cannot be construed as a criticism of the designer. In general, if it’s not nice, try hard to think of a way to say it nicer.
  • Context is everything — Ideally the game designer has asked for specific feedback points, but even if not, it’s probably worth asking some probing questions before getting into a torrent of specific criticisms. There are several “levels” at which you can talk about any game. Is the designer looking for feedback about the overall systems used in the game, or are they looking for feedback about specific components or balance issues?
  • Be specific — “I did not like this.” is not, by itself, useful feedback. Generally speaking, the more detailed you can be about why you didn’t (or did!) like something the better. If the designer was paying attention, they probably already know whether you were enjoying the experience.
  • Stay on topic — I’ve found that “after playtest discussion” can easily veer into a speculative realm of what-ifs and imaginary games that could exist. This is especially true with game designers. Try not to be the one leading the discussion away from the current game.

Workers, Workers II, Workers III

Posted on by

I had the pleasure of attending United Geeks of Gaming’s Game Designer Sessions event last night, and play testing the latest (third) iteration of a game whose working title has always been “workers”. I realized after a couple of games that the rules were a little “fuzzy”, seeing as how they’ve never been formally written down, and decided that some kind of documentation was in order… Hence this blog post. (Half rules formalization, half designer diary.)

Workers was initially conceived as a “born digital” board game with the central mechanic that there are a variable number of “resource pools” in the game, and every round each pool’s count of available resources is incremented by one. The name stems from it being a very light “worker placement” game, with the initial version allowing for only one action taken (worker placed) per turn. I’ll get into the various specific actions available when I go into details about each version of the game below.

The only other shared mechanic for all the versions of the game has been the turn / round mechanism. Each round a starting player is indicated, every player takes an action (or two) for their turn in clockwise order, and then the starting player indicator is passed to the next player (also in clockwise order).

Workers “One”
Workers Screen Shot - game startThe initial version of this game remains the only one for which there is a (completed) digital prototype. I completed a very quick and dirty app to “prove out” the game mechanics in an evening or two of work and subsequently sent it to some of my TestFlight users for feedback and testing. The prototype was “successful” in that it convinced me more work was needed, but ultimately had quite a few design flaws, which I’ll detail in a minute.

As you may or may not be able to understand from the screenshot, there are 5 available pools of resource (yes, a hard-coded number, even though I knew from the beginning that I wanted it to be variable), as well as hard-coded two-players (with their resource counts on either side of the screen). In the center are all the available actions, and under the main resource pools (which double as buttons for taking the corresponding collection actions) are action buttons for selling each combination of two resource. This version has a selling mechanic whereby you can sell pairs of different-colored resources for the value shown on each pair. Between rounds, not only do the number of resources in each “pool” increment, but the point values for selling each combination are also incremented every round. When a player took a selling action they automatically sold all possible combinations of the two resources for the point value shown. (So if they had 3 green and 2 blue, and took the green/blue selling action when it was worth 5 points, the would end up with 10 points and 1 remaining green resource.) After a sale action, the value for that combination is reset to zero.

Available actions (one per turn):

  • collect all of one resource pool
  • sell a combination of resources

The game lasted a set number of rounds. (15 here, although I experimented with different values.)

Reasons this version is a failure:

  • Replayability: essentially this game played the same no matter how many times you played it. This was pretty boring and led to an…
  • Optimal strategy: it turns out, the best way to play this game is to keep collecting resources, whatever pool has the most, until the last two or three rounds of the game, then sell for the highest possible point combination. Boring and stupid. I could possibly mitigate this by capping either point values for selling, or total number of resources, either per player or per pool. Ultimately I never implemented either, and instead moved on to working on…

Workers II
The next version of the game was conceived to “solve” some of the design problems in the fist game by adding variability (via a game board), as well as removing the complex in-game scoring (the entire “selling” mechanic). I don’t remember whether removing in-game scoring was a goal in and of itself, or whether it was primarily meant to facilitate paper prototyping. I took this version to my first Game Designer Sessions meetup, (quite a number of months ago). The game was played at that time with decks of cards with different colored backs for each resource pool.

The “game board” consists of an empty grid at the beginning of the game. Grid dimensions (as well as “number of resource pools”, “starting player resources”, and “starting resources in each pool”) are meant to be variable for each game.

Scores weren’t known/calculated until the end of the game, when all the spots in the grid were filled with resources. I played with a couple of formulas for scoring (see below), but in general, I wanted the more groups and the larger the groups to have higher point values at the end.

Available actions (again, choose one):

  • take a pool of resources
  • play a single resource from your resources into the game board

Problem:

  • One issue became evident right away, and that was lack of incentive to be the player who plays onto the game grid. After one play test, the player who sat back and hoarded resources was the clear victor. If I remember right, I believe we played a second game after the first and changed the “play on the board” action to take the resource from the pool rather than from your hand. Additionally, you got to take one resource from the pool into your hand as part of that action. I came up with another possible solution on the fly last night.

Workers III
The version I brought last night had basically one new mechanic: Every player started with a “x2” (times two) card face-up in front of them. There were two ways you could use this card, but when you did, you turned it face-down, and those actions were no longer available to you. I also play tested this version of the game with colored cubes for resources, which I felt was more visible (at a glance) than had been the case with using decks of cards, and had the added benefit of keeping the game board size considerably smaller. (I drew the game board out as well as “spots” for 4 resource pools on a single sheet of graph paper.)

Possible actions:

  • take all of one pool of resources
  • place a cube from your resources onto the game board
  • use your “x2” action to increase the subsequent pool increment by one additional cube per turn (this could stack if multiple players did it)
  • use your “x2” action to place a cube on top of a cube already on the game grid (increasing the size of that group by one without taking up a spot on the board)

We played a relatively quick game with 4 players, 4 resources, and a 4×4 grid, but less than halfway into the game I remembered the problem discovered in the playtesting of Workers II. I let the game play out, but suggested we play another game where you take two actions per turn, but your second action has to be a placement on the game board. One player left, so we played 3-players, 4-resources, on a 4×4 grid, but everyone started with one of each resource. I feel like this went pretty well, but still “needed something”.

Possible scoring mechanisms for multiple variable-sized groups:

  • group-size times group-size added together
  • group size added together times number of groups
  • Fibonacci values for each group totaled, times number of groups

I have lots of ideas for Workers IV. I’ll post back here when I get a chance to try any of them out!

thoughts on CCG & LCG apps

Posted on by

Today Hearthstone is finally available worldwide, and I will definitely be spending some time with it on my iPad. I have played it a bit on my desktop, enough to get the feel of it, and decide I wanted to wait until it was available for iPad. (Mostly because that’s where I spend most of my time gaming.)

I’m not really interested in commenting on the F2P mechanics, (since enough has been made elsewhere of how “gentle” they are in Hearthstone, or how “right” Blizzard is getting it), I’m more interested in a study of the game mechanics independent of the monetization strategies (no matter how closely they may be coupled). From what I saw at GDC, Blizzard really spent a lot of time trying to make Hearthstone accessible to the masses. This manifest in a lot of different ways, but essentially they are balancing card abilities and deck compositions (for pre-built decks you encounter and use early in the game) to help new players.

I never really got into Magic the Gathering. I know there will be some of you that stop reading at this point, but I guess what turns me off about it (and, realizing this, the entire genre of deck-based-fighting-games) is the direct conflict. Most of the card abilities deal with combat. Dealing damage to your opponent is a (if not THE) central mechanic, and I guess I just find that emphatically boring.

A month or two ago, I did get pretty into Card Wars, a LLG (CCG?) inspired by an episode of Adventure Time. It was a great episode, and made everyone who saw it (well, everyone I’ve talked to) want to play the game. It’s a lane-based game like Solforge, Spectromancer (or it’s sort of predecessor Kard Combat), or Kongregate’s more recent Tyrant Unleashed.

The first Hearthstone talk I saw at GDC (I saw two) was one about the AI, and I was pretty much entranced by it, loving this slide of the overall architecture:
20140416-162859.jpg

I guess this is another one of those posts where, if I had infinite time, I would dissect the mechanics I like about each of these games, and draw a cool diagram or something, but I don’t have the time, and I’m going to go download Hearthstone now, before I forget.

Primitives and Hex Primitives

Posted on by

As a sort of follow-up to yesterday’s post on small-grid games, I realized that I haven’t made this pair of games public anywhere yet. (That I remember.) That post led to some Facebook discussion, where we got to talking about hex grids, and I mentioned that I haven’t seen any small hex grid games… but then I realized that I had worked on a design for one on-and-off last year!

Primitives is a relatively simple game where you place a card or one of your makers, or otherwise manipulate the gameboard. (I believe the last rules I playtested said you could do one of those per turn.) Manipulating the board means you could change a single card without a marker already on it, either by moving, rotating, or flipping it. By claiming a card, you “lock” it into place, and subsequently receive points for its symbols (and any matching symbols on adjacent cards) at the end of the game. The point values are dictated by the symbols on the center of the cards, either plus (+1 point) or minus (-1 point). Each card is double-sided, so flipping a card means it will change that symbol from + to -, or vice versa. The game ends when everyone has placed all their markers and all the cards are out on the board. More playtesting is probably needed, but I may need a rule that says something like: “If only one player has markers remaining, they MUST place it on their turn, and if everyone has placed their markers, the only available action is to place a card onto the gameboard.”

The first version was played with standard playing cards in a hex-like configuration. But I realized I could get more symbol matching in there (and more rotation) if I switched to hexes for the cards themselves. I also went from six symbols to three, for essentially the same reason. Here are some photos of various paper prototypes.

Primitives (version #1)
20140325-145301.jpg20140325-142342.jpg



Hex Primitives (version #2)

20140325-142311.jpg20140325-142258.jpg



These games were inspired by my playing Love Letter for the first time, and wanting to design a game that used a similarly ridiculously small number of components. (Love letter is played with a deck of 16 cards. Primitives is played with only 7.) I may try and bring this game to a Game Designer Sessions meetup tonight or in the future.

Root Down

Posted on by

icon_in_contexttl/dr: I just submitted an app version of a board game I call Root Down to the app store. The app will be free, and represents not all that much effort on my part, but if there is interest, I’d like to update it with AI and multiplayer.

What is it?

Root Down is a 2-player abstract strategy game where the main mechanic is that pieces flip from a state where they can move (kickers) to a state where they cannot move (roots) after every move. The key is that kickers must also be next to a root in order to move, and the number of spaces they move is also determined by the number of kickers next to each root. I spent an evening and adapted the game for iPad, and have now iterated on it a couple of times to the point where I think I’d like to get it out there and see if there is additional interest. There is no AI, and the game can only be played on an iPad with two players. Consequently, I can’t imagine it will get that much interest, but I still want to put it out there and see what happens.

Here are a couple of screenshots:

screenshot-1screenshot-2

(Yes, I know this looks awful! I have lost any html skills I maybe once had!)

Full Rules

The full rules for the game can be found in this public google doc.

Features

I could probably wrote an entire additional blog post about what features I decided to include and ultimately decided against including in this simple game. As I mention below, I essentially wrote the initial version of this app in an evening. Probably four hours tops. I knew I wanted to put it out there, get it in the app store, even though it’s pretty minimal in what it does. That initial version basically just had the following:

  • 2-player “pass and play” multiplayer (on the same device)
  • a rules popover
  • end-game popover with final scores

Yes, that was it. I spent another couple of hours adding the following:

  • an edit button on the game screen — This allows you to change the opening setup, and initially I thought it would be useful as a “poor man’s undo”, but it can’t undo capture counts, so it really doesn’t work for that.
  • a feedback button — This just opens the standard email popup.
  • an Abstract Puzzle logo that fades out to the home screen — This doesn’t look as good as I wanted it to, and I’m still debating pulling it from the next build. The problem is that I didn’t have a version of the logo with a transparent background, and the black on red ended up just looking okay, but not great.

App Store Submission

Apple rejected the first version because they didn’t like this bit in my app description: “This is an app experiment. There is no AI (yet), nor are there the other typical bells and whistles usually present in iOS board game conversions. If there is interest, I plan to add an interactive tutorial, asynchronous multiplayer, an AI to play against, universal (iPhone) support, and whatever other features are requested.” I removed all of that, and replaced it with a call to use a “submit feedback” button on the app’s menu.

Subsequently, (this morning), I found a bug in the end-game scoring. I’ll be rejecting the binary, and resubmitting in the next hour or so.

History / Backstory

A month or so ago, Christian Freeling (creator of Mindsports) started a contest on BGG in the Abstract Strategy forums concerning “activator” games, or games with pieces that “activate” other pieces. The idea percolated in my brain a bit, and suddenly I found myself on the floor with my copy of Card Chess, playtesting an idea or two.

I got enamored enough with the game that I wrote up the rules, and wanted to post them on BGG to get feedback, but I didn’t have a name. I started thinking about the pieces in my game that activate, and how they sort of put out tentacles to the pieces next to them, kind of like roots on a tree. Eventually the Beastie Boys’ Root Down popped into my head, and the name was set. Eventually I re-wrote the rules to incorporate “roots” and “kickers”, and “kicking it root down” from the lyrics of that song. I think it works pretty well, actually, for an otherwise themeless abstract. Eventually, I did post the game to BGG. I have also submitted the game to the actual BGG database, where it is pending approval.

When Board Games Go Mobile

Posted on by

When you consider some of the game design imperatives for mobile games — playable in short bursts, interruptible, simple touch controls, UI that fits on a small screen — you may not immediately think that board games are a good fit for the medium. After all, many board games are an all-evening affair, require complex strategies, and cover the dining room table while they’re being played. But there are several reasons that board games are extremely popular on mobile, even games without the marketing budgets and brand recognition of Monopoly or Chess.

First, it should be noted that these are games with an existing fanbase. With a few notable exceptions (see Solforge or Cabals: The Card Game), mobile board games already have a physical version. This means that there is a certain niche fanbase that probably already knows about the game. Quite possibly there are hundreds or even thousands of people who have already played the game and know its rules. Some games already have enthusiastic fans that will help promote a digital version without even playing it.

As anyone with a marketing background knows, the more times a person sees a product, the more likely they are to purchase the product. So a fan of board games might have seen it in their local hobby store or read about it on Board Game Geek. By having a digital version on the market, your game has a leg up on the competition by sheer virtue of name recognition. In fact, this cross-media marketing can go both ways. Notable board game publisher Days of Wonder has been fairly public about the boost in sales their game Ticket To Ride has seen when the app version goes on sale or is otherwise promoted in the app store.

Price point is also worth talking about, as most hobbyist board games cost between $20 and $60, and most mobile apps cost between $0 and $1. A board game conversion application can often command above-average “mobile market value” (usually between $3 and $10) simply because it is being compared to the price of a physical game that is priced considerably higher. To a hobbyist board game connoisseur, picking up a $5 app to “try out” a game that would normally cost much more is quite a bargain. If the game includes a tutorial (as it should!), it might even attract a secondary market in players of the physical board game who can’t, or won’t, be bothered to read a complicated instruction manual.

Design Considerations

All of this should not be interpreted to mean that you can ignore the mobile game design imperatives mentioned at the beginning of this article. In fact, those should be some of your primary considerations when you evaluate converting a board game to mobile. Can you shrink all the information onto a 3.5-inch screen? Can you adequately distill the strategies and experiences of playing that particular game into a single-player experience, and will that experience still be fun? Sometimes the answer to that last question is only maybe, or flat out no, but mobile has another compelling attribute that will allow the game to still be worth making: always-on internet! This means it is perfectly possible to make a mobile game that is multiplayer only. There have been some really successful examples of this, (Words With Friends, for example). Another important question is whether the game can be played asynchronously. What I mean by this is: can each player take their turn without needing the input of the other players? If so, this allows for non-realtime (asynchronous) multiplayer and vastly simplifies the implementation of single-device multiplayer.

I would still recommend you include a single-player experience if you can swing it. The main reason for this is related to the cross-pollination I mentioned earlier between physical and digital. Folks who already own a game will have less reason to pick up a digital version if it is multiplayer-only. Sure, they can play against strangers and over long distances, but it is incredibly compelling to be able to play a board game you enjoy without needing to wrangle up several friends to do so. Some mobile board game publishers claim that their usage stats also show more single player games played than multiplayer, but that is highly anecdotal evidence.

Another question to ask is: does anything need to change when going from physical to digital? Should you use the art from the original board game? (If you can, the answer to this one is absolutely yes.) Obviously, you don’t have little wooden bits to move around, but of course you could simulate those. What if the wooden bits in the game are just counters? Would it make more sense to just show the number they are meant to represent instead of showing the pile of wooden bits? Anything that can be represented numerically is something you should contemplate.

I’ll illustrate this with an example from one of the first (and still one of the best) iOS board game conversions, Carcassonne. Carcassonne is a tile laying game, where on your turn, you have a random tile to play. In the physical version, you randomize by making face-down stacks of tiles or by pulling one from a bag. Theoretically, you know how many tiles there are left “in the bag” (and even what kind they are) by counting the ones already played on the table. In practice, that’s rarely something anyone figures out when playing the physical game. Yet, in the digital conversion, the developers chose to show a list of all the tiles in the game, with the number remaining of each type clearly displayed. This simple inclusion immensely changes gameplay because players will spend less time trying to determine whether or not a particular tile will be available to them later in the game. This allows for a much more strategic playing of the game.

Final Thoughts

I don’t have space here to go into all the nuances of licensing a board game property for mobile conversion, but I will say that you can bet most of the more popular games have either already been licensed, or have some other reason for remaining unlicensed. There are thousands of board games, however, and there are many, many diamonds in the rough. Likewise, I could write an entire article about UI considerations. How to best represent physical components on a touchscreen device is question that has been answered many different ways already, and only a few great games have really nailed it.

A few board games have now been released simultaneously with their digital counterparts. Marketing a board game is not so different from marketing a video game, and platform dominance applies to both. There may come a time in the not so distant future when we expect these simultaneous releases. Perhaps someday, digital “conversions” will not be considered “conversions” at all, but rather, just another way to play the game.

Note that I originally wrote this article for the IGDA Perspectives Newsletter, and it was posted at the end of November along with the following bio (which I also wrote, just FYI).

Martin Grider has been developing iOS applications since late 2008, when he launched his first application ActionChess, a Chess and puzzle game mashup. At the end of 2012, he developed and helped launch For The Win, an iOS board game conversion for well-known board game publisher Tasty Minstrel Games. Martin is passionate about mobile game development as well as game design for both video games and board games. He is a proud member of the IGDA, where he has presented for the local Twin Cities chapter on iPhone Game Development, Mobile Game Design, and his own mobile games.

A 4X Dice Game

Posted on by

dice-pnpThis project came about while I was joking yesterday afternoon with my friend Patrick about how we needed to rush a space-themed dice game to Kickstarter before TMG publishes Eminent Domain Dice.

I’m still working on my deckbuilding 4X game, so 4X mechanics have been on my mind a lot lately, and the more I thought about it, the more I actually thought a 4X dice game could be pretty cool. Right away I had the idea that you would take your actions at the beginning of your turn, then roll the dice to plan out your next turn’s actions. From there, the game practically wrote itself.

I went to BGG to post my rough draft of the rules (without any graphics or pnp files), and before I got that far, I discovered that the theme for this month’s 24 hour game design contest is dice. Well, that seemed awfully convenient, but reading through the rules, I’d have to do everything myself, prototype art and all… so I did.

The other thing I did for this project that I’ve never done before, because I think it’s part of the “complete board game package”, is that I wrote some “flavor text”. I’m actually pretty happy with it too. Here’s probably my favorite bit: “What gravity at the edge of a black hole, this calculating weight of choice?”

So without further ado, here are the rules (and PNP pages, including custom dice in two sizes), for my new game, which I am tentatively calling 4X Dice.

deck building with standard playing cards

Posted on by

I posted a set of rules on BGG this morning for an idea I had for a deck building game with standard playing cards. The game was specifically envisioned for the 2013 Solitaire Print and Play Contest. I think the idea could be expanded to a multiplayer game, but I haven’t done too much thinking about that yet. This was partly inspired by the contest, and also partly inspired by this neat RPG I found (also on BGG) called 52 Card Adventure (also playable with standard playing cards). Anyway, here my rules are, reposted here for posterity:

Object
Acquire all cards into your deck in as few turns as possible

Setup
You start with 10 cards in your deck, (all 2s & 3s, and two 4s). Also set asside the other 4s and two 5s for scoring. Shuffle the rest of the cards and lay out five of them (the lineup) for purchasing.

Turn overview
A turn consists of the following steps:

  • increment your score/turn counter (see scoring below)
  • draw 5 cards and use them to acquire other cards
  • put all the cards used, unused, or acquired in your discard pile
  • refresh the lineup back up to five cards

Gameplay details
Draw 5 cards from your deck each turn and buy cards using the values of the cards you’ve drawn. For example, you may buy a 10 of clubs by paying a 9 of diamonds and two of clubs. You do not get “change” for your purchase and the same card may never be used to buy more than one card.

You may only buy a card if you are using at least one card of the same suit.

If you buy a card using its exact value (a 6 using two 3s, for example), you may acquire another card from the lineup without paying anything for it. The “same suit” rule does not apply to the free card acquired in this way.

You may acquire as many cards from the lineup in a turn as you can afford/acquire.

Face cards (J, Q, K) may be acquired by paying their value (11, 12, 13), or (more likely) with the free card after an exact payment. When they are in your hand they may be used as their value (11, 12, 13), or you may discard them to draw additional cards from your deck. A Jack lets you draw one card, Queen two cards, and King three cards.

An ace may only be acquired as the free card from an exact value payment. Thus if the last card to be acquired is an ace and there are no other cards remaining in the lineup or lineup deck, this is the only way to lose the game. When an ace is in your hand, you may use it to acquire any card from the lineup regardless of suit or cost (other than an ace).

Scoring
Right now, your score is simply the number of turns it takes you to acquire all the cards in the lineup deck.

Lay a 4 and a 5 face-up near (but separate from) the play area. Place the other 4 and 5 face-down on top of them. The 4s are your “tens” counter and 5s are for 1s. On the first and subsequent turns, reveal one of the suit symbols on the face-up 5 by moving the face-down 5 on top of it. When you get to 5, flip the face-down 5 to face-up, and cover the other suit symbols. For six, move the top face-up card to revelal another symbol, etc.

(I hope this is explained well enough. I cannot take credit for this, as it’s how my family has scored euchre for years.)

Feedback desired
I’ve played through this a bunch of times (best score was 12). I think the scoring is the weakest part right now. Definitely looking for ideas on how to improve that.