iOS Updates and version numbers

First of all, the update to Catchup I mentioned a while back is finally live in the app store today! This got hung up a bit because Nick wanted me to make the new catchup rule the default. I told him I would definitely do this if he would handle translations of the rules update. (But of course wrangling a bunch of translators is much more difficult than the few lines of C++ needed to make the rule change itself!) So as of this writing, the rules change is still optional (and off by default). If and/or when we get some translated rules, I’ll probably push out another update to flip the default.

I’m also working on updates to some of my other apps. Unfortunately, it’s not really a straight-forward process, and there are some that will still probably not get an update at all. (Action Chess, for instance, just needs to be entirely re-written, which I’ve pretty much decided I’ll just do in Unity rather than go for iOS native.)

But in all the apps I’ve done so far, one thing I’ve had to do is change the code that shows the version number. I thought I’d write a mini-tutorial because this is kinda dumb. In pretty much all my apps, I previously had this block of code somewhere (usually in an AboutViewController class’s ViewDidLoad or ViewWillAppear method):

[self.versionLabel setText:[NSString stringWithFormat:@"v%@", [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleVersion"]]];

…but now I’ve changed it to the following:

[self.versionLabel setText:[NSString stringWithFormat:@"v%@.b%@", [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleShortVersionString"], [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleVersion"]]];

This results in a version number that looks something like v1.4.b2.

(It’s worth noting that I highly recommend putting a user-facing build number in your all your apps somewhere. This is super important for getting bug reports and feedback. The technique above allows your code to update that user-facing number without having to include it in your code directly.)

In case it’s not clear, self.versionLabel is a UILabel instance, either initialized in code elsewhere, or (more likely) in a Xib or StoryBoard.

Anyway, Apple put out a technical note about version numbers and build numbers back in 2015, but somehow I missed it. Now I’m not 100% sure about this (possible it’s just that I was always confused about this), but my theory is that, at some point (maybe around 2015), the CFBundleVersion key changed functionality, from the version number to build number, and the CFBundleShortVersionString was introduced as the new version number. (This is really difficult to google for, I tried, so if anyone has a more accurate historical rundown, I’d be interested in hearing it.) Anyway, both string are required, but the build number is specific to the version number. (I.E. both have to increment for actual releases, but if you bump the version, you can reset build number back to 0 or 1, or whatever.)

These values are changed in Xcode, in the general project settings. Worth noting that the version number is shown to the user in the app store, but I don’t think build number is exposed anywhere (that I’ve seen). I usually try to follow semantic versioning, with the actual version number containing the first two dots (major and minor version changes), and more or less use the build number as the third “patch” number.

I guess the thing I find the weirdest about these bundle keys is that neither one is named “build”. And I would expect the build number to be the shorter one, not the version number. But maybe that’s just me! Hope this helps someone.

ProcJam and #NaNoGenMo postmortem

I’ve always wanted to make some interactive fiction, and last month I decided to spend some time working on a procedurally generated Inform7 game. You can read more about it on the Github “Issue” thread where I announced my intent to participate, but I’m reposting my final “wrap-up” entry here:

Post-mortem / wrap-up post:

Failures
Mainly, I didn’t make a 50k word “story”. Although you could maybe argue that the inform “story” isn’t the “whole story”, that’s what my script generates, and I was planning on using that for the word-count metric. My plan for getting to 50k had basically been to increase the number of rooms the script generates until I hit that number, but that isn’t possible because some of the items I’m using for randomization don’t contain that many items. (And I didn’t realize or notice this until just now as I was prepping this post!) Turns out I can only push the script to ~25 rooms, before it tries to randomize from several sources with only that many items. The word count at 25 rooms is only about 4700-4800.

Also worth noting that version with 25 items doesn’t always work. I went ahead and pushed an example of this output as `output/v0.5-source-broken.txt`. Pasting that script into inform gives errors that I’m probably not going to take the time to fix. (Essentially, some of the source for my randomized room text is probably problematic, and should be excluded.)

Additionally, I’m pretty sure the game as-is at the moment of this writing isn’t that fun to play. There isn’t enough randomization of the puzzles. Essentially, each room has the same fetch quest. (If you’d never played it before, and went into it without my spoiling it for you –which I’m not going to do here– it’s possible it would take you a bit to figure out, but once you did, you’d know how to solve every other room, and it would grow tedious pretty quick. I think the version with 4 rooms (in a 2×2 grid) is probably the best way to play. There is some novelty in the randomized room names and descriptions which can sometimes be pretty surprising. It might be fun up to 12 or 16, but again, it would get old pretty fast in its current incarnation.

Another failure, I could argue, was my goal of learning Inform7, but I’ll write more about that in a bit.

Because I wasn’t really happy enough with the output of this script to post it anywhere, I also didn’t submit it to ProcJam. That was/is also definitely a fail.

Successes
I wrote some Python! Python is ridiculously easy to write. It feels a bit like I say this about every new language I learn these days, but learning the syntax (there is almost none!) and the various APIs was a very minor part of this project, and generally quite fun and easy. Debugging errors was quite easy, as error messages were very easy to search for, and often even that step wasn’t needed.

I learned quite a bit about writing Inform7! Unfortunately, that’s about the best I can say about it. Inform got harder and harder to work with, and was generally the opposite of my experience with python. My take-away from Inform is that you want to write one sentence at a time, compiling after every one. Every new thing you try and do will require searching through the documentation for an example you can copy/paste. There were dozens of times when I would modify even just one word from an example and then scratch my head about why that changed caused it to stop working. And debugging was always a nightmare. The error messages sometimes contain (sometimes hilariously) a bit of randomization themselves. This seems interesting/funny the first few times you see the same error and the text is different, but the 3rd or 4th time, when you are at wit’s end, it’s no longer funny. Here’s an example of an inform error (but not one with randomized text, I don’t think):

You wrote ‘now the Greyish Blue Book Of Matches is nowhere’ , but although ‘the Greyish Blue Book Of Matches is nowhere’ is a condition which it is legal to test with ‘if’, ‘when’, and so forth, it is not something I can arrange to happen on request. Whether it is true or not depends on current circumstances: so to make it true, you will need to adjust those circumstances.

In general, my take-away is that Inform7 syntax is a great big can of worms. It would probably take me a month of working full-time to really understand the entire system and how it all works together, and feeling competent in it would probably take much longer. (This was obviously not that month!)

Wishlist / TODO list
If I wanted to spend more time on this project, these are the things I was planning on doing:
* Randomized puzzles. Right now there is really only one type of puzzle. I would love to have 4 or 5 types (at least!), and generate different room descriptions based on the type.
* Additional inform elements: Right now, there are rooms, objects (some edible), containers, and that’s about it. I really wanted to get to the point where there was also a randomized person in each room. The amount of things you can do with Inform is staggering really. I’ve only just scratched the surface, for sure.
* Finally, making this available to the rest of the world. This boils down to how I wanted to do this initially, and how I think it’s feasible. Both would have been published as a webpage. A) I wanted to make a version that was different every time you play it. But the only way I could imagine that happening would be to install the command-line version of inform on a server, and at request time, generate the source, compile it, and redirect the request to that output. I’ve no idea if that’s practical, but it’s not something I wanted to attempt. B) The more practical alternative would be to generate a bunch of outputs all at once. So that would be writing another script to run my `game.py` script X number of times, saving the output off to a tmp directory, then using the command-line version of Inform7 (i7) to compile each output and save off a web-playable version into a subdirectory somewhere. Tentatively I was planning on doing this 365 times and then writing some kind of index.php to swap them out based on day of the year.

TL;DR
I really enjoyed working on this project, and learned a lot about Inform7 and python, but wouldn’t really consider this a “successful” project, mostly because I just didn’t spend the required time on it. There is always more you can do, of course, but in this case, I didn’t take the project far enough where I think it’s ready for public consumption. (It is all public, however, and anyone can play with the stuff I created. If you do, I’d love to hear about it!)

A Catchup Rules Change

Some time ago, Nick Bentley, the game designer behind my app Catchup, proposed a slight change to the rules over in the forums on board game geek.

Please see the forum link above for all the specifics, but the crux of it is that in the original version of Catchup, you could claim a hexagon creating a group up to the largest group on the board without triggering the catchup mechanic. But with this new rules change, even tying with your opponent now triggers an extra claim for them on their following turn.

I’m working on an update to Catchup to make it iOS 11 friendly, and support the new iPhone X screen size, and figured while I’m at it, I’ll add this new rule as an option in the app. So I’ve created a new toggle in the game options, and I’m leaving it off by default, because I don’t think most people will know about it, and I don’t want it to take anyone by surprise. Also, for now, because I don’t really know how I would indicate which version is being played in the UI, you won’t be able to play with the new rule in online games. If there is enough (any?) clamber for it in online play, I may consider adding that in the future.

Donuts In Space, Unite Austin, and 2017 Recap

I’ve been pretty lax on posting here this year. The main reason for this post is that I realized I hadn’t posted about Donuts in Space, which is a game I made explicitly to put on the Donutron. In case you’re not familiar, the Donutron is a donut-inspired arcade cabinet installed at Glam Doll Donuts on Nicollet and 26th in South Minneapolis.

The Donutron currently features all games made by local-to-Minnesota game makers. Donuts in Space was the first donut-themed game on the cabinet, and is a game where you play as a donut rolling around on top of a giant donut floating through space, racing the clock to collect mini-donuts. You can also play split-screen multiplayer. Here are a couple of screenshots:

So the other reason I wanted to post is that I keep meaning to write about Unite Austin. First of all, I decided to go to Unite because a) Unity is a good chunk of my freelance work now, (easily 50% in the last year, possibly as much as 80%), and b) it had been a while since I went to a technical conference where I expected to learn anything. I did learn a bunch, mostly about the new Timeline and CinneMachine features built into Unity 2017.x, but also a bunch about various AR stuff. I also got to try out demos of the Microsoft “mixed reality” headset and software, as well as the Meta 2 AR headset.

When I registered for the conference, the website also managed to upsell me on taking the Unity Certification exam while I was there. (So yes, I am now Unity Certified, at least for the next two years.)

Let’s see, other random stuff that’s gone unmentioned this year:

Threes! inspired

In part because I’ve only just found out that someone beat Threes! for the first time, I’m finally going to write a post about my game Slide Quest.

But it won’t (just) be about Slide Quest… (Feel free to skip to the list of my three favorite Threes!-inspired games below.)

Okay, first off, I’ve never publicly talked about Slide Quest before. There are several reasons for this, but namely I’ve been embarrassed by it. I actually never meant to release it. (This is hard to believe, I know, but in some past versions of iTunes Connect — apple’s publishing webapp — you had to set a release date for your app. If you started creating the app in there, but you didn’t know if you wanted to publish it, one technique was to just set the release date to some far off date in the future. I did this, but then that date passed, and the app was released. No fanfare, I didn’t even get notified, or if I did I was too busy with client work to notice.) Anyway, when I found out it was released, it was to a few pretty terrible reviews. (It was basically not much more than a prototype.) I decided I’d rather it was out there than not, but I felt dumb, and basically never promoted it in any way.

I was also embarrassed because of all the issues around whether or not games inspired by Threes! are clones. Threes! was famously cloned very soon after its release, with a game called 1024 appearing in the app store only three weeks after Threes!. This was exacerbated by the release of another game (called 2048) by an 18-year-old developer who claimed he’d never even seen Threes!, and had written his game based on 1024. 2048 was made in javascript, in a weekend, and released for free on github. It proved to be extremely popular, in part because there were a ton of versions of it that appeared for free, often with Ads. (Threes! later went “free with IAP”.) 2048 was also an easier game. It’s wasn’t as punishing as Threes!, and a casual player was more likely to hit upon a winning strategy.

The point is, within a month, there were probably hundreds of games inspired by Threes!, both in the app store and elsewhere. For more about Threes! and clones, you should read the Polygon writeup, but also read the post by the developers of Threes!, where they also post all their correspondence (emails) during the game’s creation. That post is rather heart-breaking, but the email archive is actually a pretty amazing resource for aspiring game developers.

Anyway, I loved Threes!, and played the hell out of it at launch. I bought the tshirt. At some point I started thinking about an RPG with the same “swipe mechanics” as Threes!, and the thought kept me up at night. I too put together a prototype of that game in a weekend. That game was initially called RPGeez, but eventually I changed the title to Slide Quest.

There are several subtle differences (aside from the obvious aesthetic ones) between Threes! and 2048. In Threes! a swipe only moves each of the tiles on the board one space; in 2048, they move until they can’t move any farther. There are of course other differences, but this is the main thing.

With Slide Quest, the main mechanical difference is that there is a character on the board. That character is “you”, and you slide around the board with every swipe. You have a level, and you level up if you attack (combine with) a monster on the board that is the exact same level as you. You can attack and defeat lower level monsters without effect. Higher level monsters just block the board and lead to (eventual) game over. Like 2048, Slide Quest is definitely much “easier” than Threes!, but it does have one more interesting twist, in that every 33 levels, the algorithm for what level monsters spawn on the gameboard changes, getting more difficult.

Over the 3.3 years since Threes! was released, I’ve sometimes taken note when I see other games inspired by Threes!, mostly because I’m curious to see how they tweak the mechanics.

Here is a list of three Threes!-inspired games that I quite enjoy:

Stencilsmith, by Nicholas Sepi Jr. — This game is probably easiest to describe as Threes! meets Minecraft, though much simpler than that makes it sound. Essentially, there are pickaxes that need to combine with land to make materials, and the materials can then combine with pickaxes to make more powerful pickaxes. There are also swords, which need to combine with materials before they can then combine with enemies to take them off the board. You have three hearts (in the main game mode), and when you combine an enemy with something not a sword, it takes a heart.

SideSwype, by Radiangames} — This game combines Threes!-style swiping and match-3 mechanics. I really enjoyed it, and it’s got an elegant graphical style. Incidentally, it’s also by the developer of Slydris, which is an amazing game.

Puzzle Chips, by Curt Stein — Curt Stein created one of my early app store favorites called DropOut. In this poker-chip-themed take on the genre, each tile is a stack of chips. When the stack gets tall enough, it can be tapped to remove it from the board. So basically the numbers don’t really combine or increase, but as you play, chips that are worth more will spawn more frequently.

In a post back in 2014, I talk about small grid games, and said that 2048 was my favorite threes-inspired game. But in my memory of the time, I didn’t actually play that much of 2048, I was actually just really excited to surf the many forks of it that added different mechanics. Now when I try and view forks on github (it says there are 15,037), it just gives me the error “Too many forks to display.”

Please let me know (either here in the comments, or over on my twitter) if you have other Threes! inspired games that you like.

UPDATE (2019-06-13): Adding some screenshots and removed app store link as the game hasn’t been live for at least a while now.

Also worth noting that Twinfold by Kenny Sun does what I wanted to do with SlideQuest WAY better than I did. Basically just adds a ton of other elements, and is actually more of a “real” game than SlideQuest ever was, while basically being a similar progression-based high score game. Highly recommended.

Another one bites the dust

Tonight Abstract Puzzle got a slight refresh, removing some expired App Store links, as well as adding headers for “Forthcoming” games Puzzle Prison and ActionGo, and “Retired” games ActionChess and Oppo-Citrus that were removed from the app store last September.

I also added Root Down to the lineup, and changed some wording here and there.

Sadly, For The Win will be moving from “Mobile Board Games” to “Retired” sometime in the next month or so. I got the same email from Apple about it as I got for the other two games. I don’t have time to update it to support all the new screen sizes (and that app in particular would probably require some new graphics).

Get ’em while you can!

Last week, as part of their initiative to clean up the app store, Apple marked two of my oldest apps as needing updates or they’ll be removed from the store (in 30 days). Since I don’t really have time to update them right now, I’m changed their pricing to free so everyone has a chance to download them before they’re removed. When I do get around to doing updates, I’ll definitely put them back back in the store as paid, so get ’em while they’re free!

The affected games were ActionChess and Oppo-Citrus.

These are games that I’m really proud to have made, so if you haven’t played ’em, please do go check them out. (And let me know what you think!) Enjoy!

Notes from pyramid games playtesting

My good friend Nate was kind enough to playtest 3 out of four of the pyramid games I posted yesterday (we didn’t play the party game), and the results shouldn’t be terribly surprising, but they were generally disastrous. In short, none are ready for prime time. (But on the upside, none were complete throw-aways either, and all have potential!) Here are my notes:

Action / Movement Programming — This suffered from the problem where the player has the advantage, so nobody wants to make themselves the second-to-last player. This meant there was little incentive to try and make the target shape. We did play with a pretty cool variant / modification where there are 9 “goal cards” (in a 3×3 grid), and any 4 cards in that group can be the goal. The rule about “modifying” the programmed cards was very confusing to Nate, and I had to clarify / re-explain it several times. There was also confusion about being able to modify pieces on the gameboard, and I think adding an action that would allow you to modify (swap?) existing pieces would probably help. None of this fixes the disincentivization to make the goal shapes. We talked about maybe not replacing the cards. Also, I just had the idea to maybe only take one of the cards instead of all of them, so most of the shape would still be there, but it would obviously need modifying. Maybe then you also get points at the end of the game for collecting “sets” of a single color card. We also played on a very large gameboard (not quite a full chess board, but it was with the triangular chess boards that are sometimes used for looney Pyramids), and I think we could have just played on a 4×4 grid, and it would have been a tighter and better game.

Action Point Allowance System — This game suffered from the rules allowing you to totally screw yourself. If you didn’t play a combination of either 1) two 2-pip pieces or 2) a 1-pip and a 3-pip, you were giving yourself a serious disadvantage later in the game. I think the rules should just specify you can play one of those combinations. Also, the player who played first had a huge advantage, not because they played first, but because as the rules are written, they also got to play last. I think making both players play only a 2-pip on their first turn might mitigate that problem. Another issue was that we played on a 3×3 grid, but never really used more than 4 towers. Another rule change I’m considering is to make the players fill the grid first, before playing higher levels on any tower… or possibly just to play on a 2×2 grid. (Or both.)

Area Control / Area Influence — Finally, as I’d hoped, this game seemingly has a lot of potential, but we ended up not playing it while we spent like 20 minutes discussing how the captures could work. (Rules as written do not specify capture rules, and I thought I’d just make something up quick about surrounding groups, and we’d see how it plays, but turns out there are too many different possibilities!) It would take me a long while to write all the things down that we discussed, but briefly, we talked about: Switching it to allow ONLY swaps of cards with pieces on them (then you could capture from a swap or a placement). Allowing piece movement to capture, with cards containing pieces of the opposite color “frozen” in their place, essentially “locking” neutral spaces on the gameboard as kind of a suicide move. Finally, if we allow swapping cards with pieces on them (which I think is a good idea), I think maybe it should only be allowed if they have the same (or possibly only if the opponent’s card has lesser) pip counts. Maybe that parenthetical should always be true, which would mean you could only move cards that have pieces on them, since by default all the cards start empty.

I don’t know when I’m going to get around to revising the rules as written, but hopefully in the not-too-distant future!

pyramid games for every BGG game mechanic

At least partially inspired by another BGG user’s lofty goal of 1 new pyramid game a month, around January 1st I had the even-more-ridiculously insane idea to make a goal of designing a new pyramid game for each game mechanic on Board Game Geek. There are 51 unique game mechanics on BGG, so that’s LESS than one a week. Totally do-able, right?!

Of course, I promptly forgot all about that idea, until I stumbled onto the first couple in my design notes earlier today. I spent some time subsequently flushing them out and writing a couple more, and so without further ado, here is a link to the in-progress results: pyramid games for every BGG mechanic.

So far (as of this blog post) there are only 4 rule-sets in a “completed” state. I have notes for two others, but they haven’t been written up yet, which means they may not even be playable. At least one of those not yet present require a custom game board (the one for Roll-and-Move).

pyramid cards backThis idea came, originally, hot on the heels of a renewed interest in pyramid games because I’d helped conceive and design these pyramid cards, a set of playing cards for icehouse/looney pyramids. (The card artwork, — ie, bulk of the work — was done by my sometimes collaborator August Brown.) At the time, I’d thought up a few different game ideas, but it turned out that none of them were really all that fun to play. A statement that may of course also be true about the ones in the link above. YMMV. Two of the designs listed below (and flushed out in the link above) use the cards. I think the ideas in the doc are better than the original pyramid card ideas, but they are still as-yet untested. Anyway, here are some brief summaries:

Acting mechanic — In this game, players take turns choosing a board game, and without revealing that game’s name, set up and play that game with looney pyramids. They cannot talk, and the other players must try and guess which game they are playing. Subsequent players cannot choose the a game that has been previously selected.

Action / Movement Programming mechanic — This game is a combination of seeing patterns in pyramids and using your hand to manipulate pieces on the gameboard. Game play happens in rounds where a “goal pattern” is decided, and players then simultaneously try and choose actions that will manipulate the board to create the “goal pattern” there.

Action Point Allowance System mechanic — This abstract strategy game is played with 4 action points per turn. (With the first player only allowed 2 points.) Some suitable small grid is chosen for the playing field, and each player takes a “stash” of icehouse pyramids and takes turns playing pieces onto the gameboard. At the end of the game, the board is scored and players win based on number of pips that are visible in their color.

Area Control / Area Influence mechanic — This 2-player go-like game is played on a board created with pyramid cards. Cards make up the gameboard, and pieces are placed to “secure” the territory. This is the game I’m most excited about / interested in playtesting.

I’ll post again about this project after I make more progress.

What am I even working on!?!

I have too many projects going right now. I wrote up these descriptions earlier, so I decided to post them. These are roughly in order of priority. (Although the last three are essentially just “on the backburner” for now.)

1) I want to get an update to Root Down pushed out that adds an AI player, as well as universal support. The AI isn’t good in any sense of the word, but it’s good enough to surprise me when I’m not looking too hard. I’m not sure if I’ll try and improve it, or if (more likely) I’ll just release it as is to move on to the next thing. (The universal support is about 80% there, and I should have that submitted sometime tomorrow or early next week.)

2) Last year I did some preliminary work and got my very first game (Go-Tetris) playable on iOS. It’ll be called ActionGo. Since the new AppleTV announcements yesterday, I now hope I can push this out sometime in the near future, with AppleTV support.

3) Similar to Root Down, I’ve had an update to ActionChess in progress for several years. Not taking the time to do it right means that I’ve got to untangle a large pile of spaghetti code to get it done, but the update will add 1) Universal support, 2) One or two minor added game modes, 3) A major new game mode that is more of a “static puzzle” game. I’m calling it puzzle mode, and may also release it as a stand-alone app.

4) I’ve got another action puzzle game in the works that is currently without a title. This is not a board game mashup, but does mash another game genre into the mix. I have an artist (possibly two) I’m collaborating with there.

5) I’m rather slowly trying to learn Unity. I have a project I’m going to make in it, since I agreed to work on a touchscreen version of Entrapment, (the great abstract strategy game by Rich Gowell). So far, I’m a bit hung up on some of the Unity best practices, but I can’t wait to make some progress when I can focus on it.

6) Finally, I have a series of playground games I’m working on. Don’t want to go into too many details, but essentially it’s a playground video game.

Hopefully I can bang out some of these app updates in the next couple of weeks, and focus on ActionGo until the new Apple TV comes out. I’m also experimenting with some cross-platform frameworks. I’ve played a bit with OpenFrameworks, and have also spent some time looking into OpenFL (HAXE). In theory either would allow me to publish games for iOS & Android at least, and whatever other platforms they support.