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!
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!
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).
This 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.
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.
I had a strange idea this morning. “What if every time you moved a piece in a game, you were also moving one of your opponent’s pieces?” I don’t know of any other games that have this same mechanic. I present for you here, a very simple abstract small-grid game I’m calling Entanglement.
Edit: A bit more details about how this came about and playtesting (over lunch) with my friend Nate. Usually when I have an idea for a new game, I enter some minor details in a google-doc/journal I keep for that purpose. I make sure to record the date, and what I was doing when I came up with the idea. In this case, it was such a simple idea, the game came to me practically fully formed, and I went straight to a new file to write out the rules. I jotted them down in about 20 minutes, and got back to work. Then over lunch I played the game a couple of times with Nate, and immediately it felt too complicated. (Which felt weird, because it was already SO simple!) So then I revised, and we played a few more games (without the variant rules listed in the .pdf).
Overall, I don’t think this is one of my better games, it feels likely to be “solvable”, but it has some interesting decisions to make, and I was quite happy with my 10-minute prototype. If you play it, please let me know!
If you haven’t already seen the L3D kicksterter, head on over there and check it out. As of this writing, there are still 13 days left to get one of these awesome LED cubes.
I’m excited to announce that I’m working on some games for the L3D. As of last night, I’ve got a project with 4 game controllers working with the L3D “simulator”. You can see one controller working with my sample project here:
I’ll be posting the code in the next week or so, after I get my cube in the mail and test on some actual hardware. The L3D library (including primitive simulator shown in the video above) is all written as a plugin for Processing, (which, incidentally, I’ve wanted to work in for AGES), so it was a relatively simple matter to get the L3D plugin working with the Game Control Plus plugin.
Now that I’ve got them working together, I’m planning on working on the following projects:
L3D Snake — a 3d version of this classic game, for 1-4 players — this one is practically done in my example code, just needs some auto-movemet, and an array of previous spaces for each player, and end-game conditions.
text library — I’ll be helping write a general library for scrolling “marquee style” text. This should help with displaying who won once the game is over, along with maybe showing the score, or even game selection, if I get around to wrapping up several games into a package of some kind.
some games of my own design — I’ve already got a simple color-selection territory game ready to go. This should look really pretty, as well as (hopefully) being fun to play. For 2-4 players. There are some other ideas I’m floating around also.
L3D Tetris — This just needs to happen. I’ve written a lot of tetris variants, but never a 3D one (though I’ve always loved 3D tetris), so I think it’s finally time.
L3D Invaders — A 3D space invaders could also be really fun.
I’m also really interested in the possibility of designing some turn-based “board games” using the L3D. I haven’t written anything down yet, but there are some ideas percolating in the back of my head.
I’ve been meaning to write a post for a while now with pull quotes from the two big Catchup reviews. (It’s kind of a shame I haven’t even mentioned them yet on here.)
But before I get to those, Catchup is free in the App Store today. I’m hoping for a big influx of new players who might then tell their friends about how great it is, and maybe some of those folks will purchase the app tomorrow, when it’s back to $2.99. So if you haven’t already, go download it now! (But if you’re reading this, my guess is you’ve already got it, so thanks for that.)
Anyway, Catchup’s first big review came from Pocket Tactics on the 14th of August, exactly a week after its release. It’s an absolutely stellar review, giving the game 5 out of 5 stars, and I’ll just let some of the quotes speak for themselves:
“Catchup is as elegant as a game can reasonably be, presented in a marvelously user-friendly way.”
“…it’s packed with all kinds of options, some of which are unprecedented in my experience.”
In another quote that I found quite amusing, the author, Kelsey Rinella, also manages to call Nick (the game’s designer) a yahoo, while still complimenting him:
“I am not amused that some yahoo can waltz in and make what I do look easy and sound like a caring, brilliant guy at the same time.”
Catchup’s second big review was from the iOS Game review behemoth Touch Arcade. It absolutely floored me to get a full review on the front page of Touch Arcade, and they gave it 4.5 out of 5 stars to boot. Here are a couple of quotes from author Shaun Musgrave’s review:
“If you’re even a little bit into strategy games, you need to get some Catchup all over your mobile device.”
“There are also a number of achievements set up through Game Center, some of them very cleverly devised to force you to play outside of your comfort zone. That’s my favorite type of achievement.”
The Touch Arcade review didn’t appear until August 22nd, slightly more than a week after the Pocket Tactics review. Another week after that, Catchup was back on Pocket Tactics (on the 29th) for their “Games of the month” for August. Here is another great quote from that:
“The greater the ratio of fidelity to a complex system to rules overhead, the better I tend to like a design. Catchup doesn’t even attempt to satisfy my strongest gaming craving, and yet I feel excitement every time I see the badge saying it’s my turn in a game. It’s like rediscovering excellent vanilla ice cream after years of trying all sorts of tarted-up frozen confections. It’s such pure gaming goodness, without dissonance or unpleasantness of any kind.”
Obviously, I’ve added some of the above to the app’s app store description. (Let me know if you have any opinions about the ones I chose!)
I will probably write another post at some point about stats, including download numbers, and what kind of impact these reviews had on those. But anecdotally, the Pocket Tactics review got us slightly more downloads on the day of the review, (I’m guessing because their readers are closer to our core demographic), but the TA review had a longer impact, for more days. Possibly we fell off the front page of PT faster.
Here are the release notes for Catchup version 1.0.1, which was approved and went live in the App Store sometime late last Saturday night (September 6th).
* added a setting to let you change who goes first in a vs AI game
* minor changes to text strings, mostly consistent capitalization of AI and Catchup (thanks go out to Martijn Althuizen for help with this work!)
* minor changes to Dutch localization
* relatively significant changes to the german translation
* fix for the “next game” button flashing after you take an async turn
* close the GameCenter UI if the app goes into the background
* misc additional minor bug fixes
Thanks again for playing Catchup!
After getting two emails almost simultaneously on Sunday morning, both letting me know their game over screens were reporting the wrong winner, I pre-pended the following message to the 1.0.1 release notes, and sat down to find the problem:
WARNING: this update actually causes inaccurate end-game win reporting on the game over screen. (The stats and leaderboard submission should still be correct.) This will be fixed in the next update.
And here are the release notes for version 1.0.2 that I submitted to apple on Sunday afternoon, (September 7th):
* fixed bug with incorrect winner name on game over screen (Sorry!)
* corrected title bar string on game screen
All of this illustrates one of the frustratingly difficult aspects of solo application development — regression testing. Or, for anyone unfamiliar with the term, testing existing functionality after a code change “to make sure everything still works”. Basically, it was my work on the new feature (letting the user pick whether or not they go first in an AI game) that broke the game over screen reporting. As bugs go, it’s fairly minor. (I don’t mean to belittle the frustration if you encounter it!) Nothing is crashing, and the win statistics are reported correctly, both to Game Center and the internal stats page. I definitely tested quite thoroughly playing against the AI before submitting 1.0.1, but I just plain didn’t think to check local multiplayer, and might have played through an async game, but I’m not 100% sure. Anyway, I clearly didn’t encounter the bug. (Or didn’t notice if I did.) The specifics are kinda funny: the wrong player name is reported as winning the game in async, but only to one of the players. (Which player depends on who actually won the game.) In the local multiplayer scenario, it basically always reported player 1 as winning.
I have plenty more features to work on for the next build I submit, but figured I should get this fix out there ASAP.
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” The 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…
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
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.
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.)
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!
Catchup version 0.9.1 hit the app store earlier this week. Here are the notes that shipped with that version:
* russian localization
* german localization
* settings screen: delete local saved game when changing manual AI level
* fixed a bug with tutorial step 3 not getting displayed
* made popover text scrollable if necessary
* translated a few more strings for all localizations
new in 0.8.x
* traditional chinese localization
* added HSB sliders to color screen, cleaned up UI
* fixed crash in iOS 6
I have been learning a lot with this release, namely about how much extra work localization entails, but Game Center async code stuff also. In fixing a bug at the last minute related to determining whether a Game Center game was still valid (specifically, it goes through and checks all the players to make sure their “match outcome” isn’t set), I introduced another bug, this one making Game Center invitations completely fail, as the match outcome is in an “unknown” state for those, since the invited player hasn’t accepted it yet at that point. Apologies to all the folks who ran into this!
A few minutes ago I submitted build v.0.9.3 to fix this issue. The complete release notes are as follows:
This build fixes a really horrible bug with Game Center “invite” games ending as soon as they began. My apologies!!!
Thank you very much for playing Catchup!
* fixed “invite” games ending as soon as they are created
* number of “your turn” games is sometimes incorrect, (I need to reset all helper arrays when the UI opens)
* crashing bug when you delete an async game in which it is your turn, start a new one, then click next game after taking your turn (need to re-create all the arrays in the async helper)
* swapped positions of share and close on the game over screen.
* added a new “use english instead of XXX” button for non-english localizations
* lots of fixes for Dutch translation text, some english ones
* credit for Dutch translator in English localization
* dutch (nl) translation
* minor change to make one of the tutorial steps a bit more consistently worded
I did use the official form to request an “expedited review”. I have had good results with that in the past, but also know someone who had it “not work” recently, so we shall see.