Here’s a video demo of my latest project, Action Go, in progress. I’ve got all the code from Go-Tetris (the flash version) ported, and capture / territory counts are updating correctly. Now it just needs a bit of visual polish, a way to switch between game modes, a help / tutorial screen, and maybe some GameCenter leaderboards and achievements. There are a lot of other things on my wishlist, like score multipliers when you make more than one capture/territory at once (super easy), or one I just thought of today — a bonus/multiplier for when you clear all of one color or, better yet, the entire gameboard.
Anyway, here’s the video:
This year’s Global Game Jam is over, and from my perspective it was a raving success. I took part with the other IGDA Twin Cities folks, as part of a relatively large team focused on making a local multiplayer game using Xbox controllers. (Click the image to read more about the project I worked on.)
The weekend began on Friday night with everyone “pitching” at least one idea for a game in front of the group. As there were about 40 people there, this took quite a while. Then people started splintering off into groups. I went into this year’s Global Game Jam with several “agendas”. (Incidentally, I probably wouldn’t recommend this for beginners, but this was my third year taking part, and at least my sixth game jam, so I felt it was okay for me to have some goals.) Here is a list of those goals, in order of importance to me, and whether or not I felt they were achieved:
- Use Unity – Before this year’s jam, I had really only dabbled in Unity development. I’d watched a few tutorials, installed it a number of times, played around in a couple of sample projects. I went into this year’s jam with the intent of glomming on to someone else’s project who “knows” unity, so I could learn from them and hopefully make some contributions. Status: Wildly successful! I now feel like I know my way around Unity, and can at the very least make sense of projects when opening them. (This was not true before, as I had no idea where to look for things.) I could now easily make a Unity game on my own, and have some plans to do so in the not-so-distant future. All the developers on my team were experienced Unity developers, and I learned quite a bit over each of their shoulders.
- Make a game using controllers for input – This was a secondary goal, for sure, but it turned out to be not-so-hard to find a group who had this same agenda. I have big plans for this year and multiplayer games, so I needed to have a better sense of what is easy or difficult about using controllers. Status: Definite success! I not only got a sense of how to “manually” implement controller input in Unity (watching on Friday night over Ryan Schaefer‘s shoulder), but then spent an hour or so mucking around with Patrick Hogan’s InControl project, and pretty easily got that working also. (We ended up not using it, because I had some problems initially, but I think they were local to my machine/setup.)
- Make a “Candy Jam” game – If you haven’t heard of the Candy Jam, essentially, this is a game jam protest of King.com’s attempt to trademark the words “Candy” and “Saga”. There is a lot more information if you follow the Candy Jam link, but if anything, I think the case is not stated strongly enough. The problem is not just with King.com, the problem is with the system of trademarking as it applies to games in general. Similar to the way patents are given for too general concepts in the tech industry, trademarks on single-words are also far too general, and allowing them hurts the industry in my opinion. Anyway, I wanted to join this protest and contribute a game to the jam. Status: My teammates easily agreed, and this was a success also. (Note that we have not yet submitted the game “officially” to the Candy Jam, but that will happen soon!)
- Design an “action” game rather than turn-based game – Designing a game definitely took a back-seat to my first two objectives for the weekend. I pitched a game idea I had on Friday, but it was pretty simple, and I’m not terribly surprised nobody seemed super excited about it. Then during the after-pitch process, I had a lot of design ideas for another “asymmetrical” multiplayer game. (4-players each with their own objectives for scoring.) I actually still think that idea has a lot of potential, but it was fairly complex. We ended up sorta waffling on what idea we were going to make, deciding we should all just get started, and work on independent “scenes” in unity. None of the games I helped make were my design, so I can’t really say this was successful. Status: Definitely thought about it, but ultimately did not achieve this.
As I mentioned, Friday night was pretty “unfocused”, but I still felt like it was worth it, because I got to learn a lot about controller input in Unity, and thus, also a lot about Unity in general. I was also instrumental in setting up version control for the project on Friday night, but I’m not sure that was a “success” really. I’ll say more about that in a bit. When I left around 4 AM on Saturday morning, there were somewhere between three and five independent “ideas” getting floated around our group, but only one (Bird Drop) had anything appearing on the screen. When I showed up again on Saturday, Bird Drop was playable, and quite fun! I spent a few hours implementing the score display, as well as the system that triggered the game over screen and restarted the game after about 10 seconds or so. Eventually, I also worked on the over-arching menu system, as well as implementing sound effects.
In addition to my personal goals, here are some bullet points about “What went right” from our team’s perspective (although this is all still “in my opinion”, I’m not speaking for the team here or anything):
- We made a game! – Not only a game, we made (more or less) 3.5 games. There was even art for a 5th one that never got much past an empty scene in Unity. Probably more impressive, we made a menu and stuff. It really helped that Bird Drop was playable (and super fun) on Saturday, and that game got a lot of polish.
- Bird Drop is awesome! – I think everyone, even those who never worked on it directly, can take some amount of credit for how great it was. Although of course Ryan and Bill (programmer and artist respectfully) are the ones who deserve the most accolades, as the game was truly “theirs” from the start.
- teamwork! – I truly think we worked well as a team on this, with everyone contributing whatever they could (and often whatever was asked of them) to the overall team effort. This was a lot of people, certainly the largest group I’ve ever “jammed” with, and it was surprisingly painless. Certainly nobody tried to take over the project or had overactive egos or anything like that. A lot of credit should go to Zach, (who also organized the Jam, and runs the local IGDA chapter). He was probably the “glue” that kept the group together.
This would not be a true postmortem without some bullet points about what went wrong over the weekend:
- Git woes – I was one of maybe two or three of us who had used Git previously, and vocally advocated for using it over SVN for version control. I set up a repository on my bitbucket account, and initially it was marked “private”, which meant that I could only invite some small number of people to it. This limitation showed up in a couple of different ways, and eventually we resolved some of the problems with it by just marking the repo as public (which I should have done from the getgo). In retrospect, one of the other git advocates had only used Github before, and I didn’t want to use that because it’s not free, but of course it is free for public repositories, so we should probably have just used that, which would have allowed him to continue using the github app (and let some of the other devs use it too). Two of our most experienced Unity devs had never used Git before, and we wasted quite a lot of time getting tortoisegit working for them. I would NOT recommend tortoisegit in general, as I still don’t know how to view “git status” using it. Totally non-intuitive to those of us who basically only use the command-line git.
- Too much polishing on Bird Drop – This is definitely my own opinion, but I felt like we maybe spent too much time adding “juice” to Bird Drop when we could have been helping out finish up the other game modes instead. Bird Drop even ended up a bit more buggy at the end of the jam than it was on Saturday as a result. The final build we uploaded has several bugs that were introduced toward the end of the project.
- Not enough attention to the other game modes – None of the other game modes were really playable until Sunday, and subsequently were single-developer affairs until that point. As one of two “swing” developers I should personally have made more of an effort to help those other projects get finished faster, so we could have done more iteration on them.
- No focus on Friday – We basically didn’t even start coding until midnight on Friday.
- Too much time spent on infrastructure – While we were unfocused on Friday, I think we spent a lot of time talking about what code each of the game modes would share, and where that code would live. One of our developers spent a lot of time on that code, and it ended up only used by one of the games. That particular developer was WIPED by the end of the project, and it’s really only because he is an absolute rockstar that he even finished that game mode.
Overall, it was a great weekend, and I had a blast. Thanks to everyone on my team, and to everyone who participated at our location!
So I occasionally have the problem where I want to store a bunch of x,y coordinates. I have solved this a number of ways in the past, but most recently had the idea of writing a category on NSNumber that simply stores two 16 bit integers, bitshifted together. So without further ado, here’s the github project for NSNumber+XYCoordinates.
My first version of this I couldn’t get negative numbers to work, but after some patient binary math explaining today at the coffee shop from my friend Matt, I finally got it to support numbers between -32767 and 32767.
Essentially, my category just adds the following methods:
NSNumber *xyNum = [NSNumber numberWithX:10 andY:10];
int x = [xyNum xValue];
int y = [xyNum yValue];
This seems to work pretty great, and is way less annoying than my previous favorite technique, which was to convert between NSString and CGPoint all the time.
So I got to thinking tonight… this should be fast, right? But I have no idea how fast, really, or how to compare it. So I wrote some test cases. Each of them assigns and then reads back out again some number of sequential integers using various techniques that I’ve used in the past. I compiled the following lists for different numbers of values:
CGPointToNSString – size of 100 string objects in multidimensional array is 2263 (0.002 seconds).
NSDictionary – size of 100 objects in NSDictionary is 2413 (0.001 seconds).
NSSet – size of 100 objects in set is 1545 (0.004 seconds).
NSNumber+XYCoordinates – size of 100 objects in multi-dimensional array is 2033 (0.001 seconds).
CGPointToNSString – size of 10000 string objects in multidimensional array is 241803 (0.162 seconds).
NSDictionary – size of 10000 objects in NSDictionary is 289593 (0.076 seconds).
NSSet – size of 10000 objects in set is 199798 (0.044 seconds).
NSNumber+XYCoordinates – size of 10000 objects in multi-dimensional array is 203503 (0.046 seconds).
CGPointToNSString – size of 1000000 string objects in multidimensional array is 31702088 (10.187 seconds).
NSDictionary – size of 1000000 objects in NSDictionary is 38735561 (121.886 seconds).
NSSet – size of 1000000 objects in set is 25866828 (118.003 seconds).
NSNumber+XYCoordinates – size of 1000000 objects in multi-dimensional array is 25919832 (114.918 seconds).
You see that the technique compares favorably against CGPointToNSString, at 100 and 10,000 values, but somehow, the CGPointToNSString technique just blows it out of the water in terms of speed when we get to a million objects. (Still much smaller though.) I don’t fully understand this, but I guess maybe the C API is faster at high volumes? Let me know if you think you might have some insight!
I’m still trying to finish up Catchup, the board game conversion that I’ve been working on for literally about a year now. (Obviously not full-time.) But I decided the week before last to take a quick break from it and update DrawCade to support the new MFi controllers. That took me all of about three days, (the second update, version 2.1 that fixes some issues from the 2.0 update is now live, yay!) But most importantly, what I got out of those days was a wrapper that supports iCade style controllers (pretending to be bluetooth keyboards), as well as the new GCController style controllers. (The Moga Ace Power and Logitech Power Shell are the only two available at the time of this blog post, but the first Bluetooth one has also been announced, but is not yet available.)
Anyway, I promptly decided I MUST create a game that would use the new controllers. The obvious choice is to port Go Tetris to iOS. This has been on my TODO for a long time, calling it Action Go to match Action Chess, but the big holdup was that I have never been satisfied with touchscreen controls for Tetris. It can be done okay, but not great. I’ll of course have some “okay” controls in there, but now that there are some viable controller options, I’m super excited to get it playable, and decided it was worth putting Catchup off for a few weeks to do so.
I started the project a little over a week ago, and promptly spent a day getting some cool menu animations (using AGGeometryKit) in there. I made the following video:
Then I spent three days preparing some changes to my GDC speaker proposal. (Which still hasn’t been accepted, but also hasn’t — yet — been rejected.)
If we were counting today, this would be the 5th day I’ve worked on it. I’ve got the tetris aspects pretty much done, but the piece capturing and two-eye breaking aspects are not yet complete. That is the bulk of the code that needs to be “ported”, and consists of about 800 lines of ActionScript. I’m maybe an 8th of the way there. Ironically, I’ve got the touch-screen controls finished, but still need to shoehorn my shiny new controller class in there. I decided I wanted it to be playable first. I’m guessing it’ll be another week or so of work.
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.)
tl/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:
(Yes, I know this looks awful! I have lost any html skills I maybe once had!)
The full rules for the game can be found in this public google doc.
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.
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 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.
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.
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.
This happened at dinner tonight, my 3-year old daughter had a game idea that was, unfortunately, never properly explained.
The first two MFi game controllers have been released.
The Moga Ace Power, as well as the Logitech Powershell. The two controllers are similar but the Logitech offering does not include analog sticks. From the pictures that are available, the Logitech product may actually be higher quality, but I ordered the Moga one anyway, simply because I like the look of it a bit better, and because I want the analog sticks.
It’s worth noting that I do a lot more gaming on my iPad than on my phone, so I’m not sure how much I’ll use this other than for testing. I’m definitely very excited for a bluetooth connected version when that appears.
I mentioned on twitter that I think this is a big deal. If I’m right, we’ll all know it in a year or two, but I think Apple will continue to eat the big guys’ lunch in the gaming industry, and the relatively quiet announcement that apple was introducing a controller API in iOS 7 was essential for them to more directly compete with Microsoft, Sony and Nintendo. Obviously, these controllers, priced at $99 each are not (yet) cheap enough to be mass market, but of course that’s also pretty typical of Apple products in general, so that may not matter. My prediction is that we’ll just see more and more of these hit the market, and the only indication that Apple products are continuing their domination of the gaming industry will be their slow proliferation into the market. A lot is talked about the competition between Apple’s app store and the Google Play store, but hardly anyone talks (except maybe abstractly, or in passing) about how the app store is competing with the console market. (OK, yes, some people are definitely talking about it, but it doesn’t seem like it’s in the public consciousness yet.)
Pro Tip: Do not order directly from Moga, as you’ll pay a minimum of $5 shipping, and you can order directly from Apple for the same price with free shipping. Also, at least the Moga is already showing up in some physical Apple stores, so you could just head out to one of those, or check availability online and then head out to one of those.