games I wanted to make for Ludum Dare 28

So another Ludum Dare has come and gone. (The 28th Ludum Dare, although don’t ask me why the twitter hash-tag appears to be #LD48, rather than the equally noisy #LD28, because I can’t figure it out.)

The theme this time around was “You only get one.”

I saw the theme on Friday (on twitter, of course) and being “aware” the game jam was happening, spent much of that night (in between and around playing board games as I usually do on Friday nights) thinking about what kind of game I would make for it. I idly wondered how many Highlander or Lord of the Rings games would get made over the weekend, although browsing the (approximately 2000) competition entries, I have yet to see any. (I have looked through far less than a representative sampling, however.)

It was Saturday afternoon before I decided I definitely didn’t have enough time to participate, but I was still thinking a lot about game ideas. At that point, I had narrowed down the infinite paths in my brain to about two game ideas. Who knows, if I’d had enough time to actually make something, which one I might have latched onto.

First idea: touch-and-drag math game

I’ve been thinking lately about games that I characterize as “math puzzle games”. Some app store examples are Drop 7 (very early example), 10, Nozoku. I think some of the inspiration here is seeing the updates to my friend Roger’s Nurikabe app, Nurikabe Vault, as well as seeing some twitter buzz around Asher Vollmer’s forthcoming Threes.

Anyway, the game idea is essentially a grid of empty spaces that slowly fill up with numbers and math operators. (0-9 and +, -, x, %) The goal would be to “remove” those numbers by sliding over an equation that equals exactly 1. It would start easy with lots of 1s, 2s, 3s, and +s and -s, but eventually end up more difficult. Of course the speed of numbers and symbols appearing would also need balancing. This idea is simple enough I could easily have made it over the weekend. I may yet do up a prototype, we’ll see.

Second idea: local multiplayer

This is clearly inspired by all the thinking I’ve been doing about local multiplayer games, (which deserves its own post some other time), but essentially the idea here is a “get the man with the ball” type game. These are not uncommon and I would not have pursued it without adding some twist or spin on it, but I’ve been really wanting to make a game or two that uses 2-4 PS3 or XBox controllers plugged into a computer. (With the eventual intent to showcase the game in an arcade cabinet somewhere, again, more about this later.) I didn’t actually come up with (enough of) what would make this game super different from every other game with a mode like this, but I was thinking maybe the “thing” you carry around gives you some power, (like a sword that gives you the ability to fight off the other players, or a teleport on a timer or something) and that would be randomized between “rounds”. Again, not a super unique idea or anything, but it fits with some of my personal short term goals.

(Thanks to Gavin Bowman, who inadvertently encouraged me to write this post.)

Root Down

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.

How long does it take to make an AdHoc build?

An AdHoc build is how you get iOS apps onto an Apple device without going through the App Store. They are typically used for testing. I was asked this question recently, and spent 15 minutes writing up this reply, so I thought I’d post it here. The obvious caveat is that it can of course vary from project to project. A bigger more complex project has more “moving parts” that can need fiddling with when creating a build.

So… How long does it take to make an iOS AdHoc build?

I use TestFlight to distribute my AdHoc builds, and typically, I tell clients an AdHoc build takes between 15 and 30 minutes to complete. Thankfully this work “stacks” quite a bit, so doing a few of them at once might only take 20 or 30 minutes. This process basically just involves opening the project, verifying a few settings related to provisioning profiles and “targets”, building an “Archive” of the project, uploading the new build to TestFlight, and writing some release notes as well as picking the users to receive the build. (Thanks to the awesome TestFlight OSX app, those last two steps can be done while the upload is in progress.)

This assumes, however, that all the devices are already registered with TestFlight. Everything takes longer when I need to add additional devices. This stacks too, so adding 1 to 10 or 15 new devices only takes another 15 or 20 minutes. The main additional thing that I need to do in this case is upload the device identifiers for the new devices to Apple’s provisioning portal, and download a new (or updated) provisioning profile that includes those new devices. This additional work has to happen BEFORE I can make the AdHoc build for those devices.

What I find frustrating is when all these tasks are split up over the course of hours or days. For instance, when I’m asked to send a build to some new individual, but they’ve never used TestFlight, and aren’t yet registered there. Then I have to send them an invite, wait for them to accept the invite, wait again for them to register their device, then finally I can get their identifier and begin the process. This means either waiting for the new person before creating the build (sometimes this can take days, of course!), or just creating two builds, one with the devices I already have, and another when I get all the important information from the new person. Considering the adage that a “a 15 second interruption results in 15 minutes of programmer downtime” (which is more or less verifiable), these build requests can really add up to lost productivity for me.

One final note about what AdHoc builds are not.

After an app is in the app store, unless you are testing a new version, you should really be using that version, and not an AdHoc build. There are many reasons for this, but notably: 1) AdHoc builds will expire when the provisioning profile expires. 2) You get the peace of mind that what you are seeing is what your users are seeing. 3) You will get the updates via the app store, as your users do. 4) You can instal the app on multiple devices without needing to provision all of them. Don’t forget about using promo codes to get “free” versions of apps to your testers or employees after an app goes live! (In my experience, you rarely use all of them for press as you should, and you get a “fresh” batch after each update anyway.)

AdHoc builds are an integral part of iOS app development, but creating them is annoying to me because it’s not programming. Of course, neither is wring this blog post.

When Board Games Go Mobile

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.