Last month I finished up working on this game, Joggernauts, with my friends over at Space Mace Games. Specifically, I worked on a lot of the saving and menu stuff. This was definitely a watershed project for me, since it’s the first game I’ve worked on that will be released on an actual game console. (The trailer I embedded above is actually on Nintendo’s YouTube Channel!)
I’ll definitely be posting about Joggernauts again when it comes out on the Nintendo Switch!
This morning, I had a discussion with my daughter, trying to explain to her why I didn’t want to install a particular idle/incremental game on her iPad. Without naming names, it’s one of those idle games that just doesn’t have an end. I don’t think it’s a particularly bad game, but once you learn its systems, (which I do find interesting!) there’s nothing left to it but grinding for more of the same. I don’t particularly want my daughter playing games that are 99% grind.
This led me to think philosophically about why I want to play those games. I do value new game systems, and I think incremental/idle games have some of the more interesting systems being designed today. Depending on the game, it can take a while to reveal all the systems in play, but I think, if I’m being honest with myself, I am liable to play far longer than it takes to understand the systems. Or maybe by the time I’ve played long enough to understand them, I’m invested in my progress in the game, and feel compelled to continue.
One of my client projects right now is a game to teach kids about the dangers of smoking, and this has led to some discussion in the office about the nature of addiction. (Or anyway, some reading of the wikipedia page for addiction.) And I think the nature of these games (watching the numbers increase) is a sort of reinforcing / rewarding stimuli, meaning it’s possible to feel compelled to play, which I definitely do.
In the last year or so, I’ve kept a browser window open on my iMac (which is always on, on my home office desk), and there are usually between 4 and 6 tabs open to various idle games there. These are the type of games that do not have endings. (It’s worth noting that I also don’t like books or comic book series without endings!) I like to think that I basically just play these types of games in tiny spurts. But the truth is that I’ve been spending hours in front of that iMac at night. Hours when I could be making games. (And sometimes I am!) But these are hours that I could also be filling with any number of other higher-quality distractions.
I think playing games has inherent value! But when I think about where that value comes from, I find that it’s tied closely to having new experiences. Solving (and discovering!) new kinds of puzzles is especially satisfying for me, but experiencing new stories is also a totally valid benefit. So it makes sense that it’s the repetition of experience that I find distasteful for my daughter’s gameplaying. (Would I be as reluctant to let her spend hours playing Tetris? No, but maybe that’s a topic for a different post.)
Games that involve some grinding are totally fine. In traditional games, “grinding” is (optimistically) used to enhance the player’s feeling of accomplishment when they are finally strong enough to continue unveiling the story/experience. Pessimistically, it could be argued it’s often just an unintended consequence of the game’s mechanics.
And of course not all idle/incremental games are infinite grinding. The best ones do have an end. (Spaceplan or Universal Paperclips are some good recent examples.) But many do not. I’m not going to stop playing those types of game entirely. (I really do enjoy discovering their mechanics and systems.) I’m just going to try and become aware of when I’ve reached a point of diminishing returns, and stop playing then.
I’m a huge fan of Looney Pyramids. Mostly because I think it’s the most successful game system ever produced. And by successful, I mean that it’s probably had the most games made for it.
Now that I’ve said this, I might argue that Chess is the most successful, especially by that metric, since there are probably way more chess variants in existence than pyramid games, but of course Chess was never meant to be a game system. Then again, we can’t actually imagine what Chess was meant to be, since it’s not even remotely known who invented chess originally. Maybe they imagined a future in 2 or 3 thousand years when their game would be used to play literally hundreds of games.
Okay, anyway, so over 3 years ago, I had an idea, chatting with a friend**, and asked another friend*** to make it for me. The idea was a deck of cards that depicted Looney Pyramids on them. I imagined you could make a ton of games using them. Then I imagined some of those games. I don’t think I really playtested any of those games much until months later.
But the point is that I never got around to posting the PnP files for the deck of cards. So without further ado:
I wrote a forum post about Eigenstate over at Board Game Geek in the Abstract Strategy Game Forums. In the post I cover where I got the idea, how I made the original prototype, and a bunch about ideas that I tried to incorporate and didn’t work nearly as well as the current rules.
But the big news is that Adam from Adam’s Apple Games is planning to publish the game. This is obviously extremely exciting for me, as it’ll be my first board game to have a real box and print run.
Anyway, I’m going to reproduce the BGG post here for posterity:
New game: Eigenstate
Eigenstate is a 2-player abstract strategy game with incredibly simple rules that grows in complexity as you play.
Each turn you move a piece and then add two additional eigenstates (pegs) to your pieces giving them more possibilities for movement on future turns. Land on your opponent’s pieces to remove them from the board and when you’ve reduced them to one piece remaining, you win the game.
You can check out the rules and a 3D printer file for the pieces here: https://tinyurl.com/eigenstate (I’d really love to hear about it if you take the time to print it out!)
Design by subtraction
As you can see from the photo above, each piece has 25 holes, and all but the center space correspond to a possible move for that piece (relative to the center). Each piece only starts with a single movement peg, facing forward.
This design was a direct result of my playing a lot of The Duke and Onitama, and realizing that I wanted to make a game with similar movement mechanics. This was back in the summer of 2016, and at the time I was doing a project where I tried to come up with a new game idea every day. This game was the result of one of those ideas, and because of that project, I know the precise date I came up with the idea. (2016-03-28, and it’s outlined in vague terms in this blog post) I wrote again about the idea once I’d built the initial prototype, (and started thinking about it as a game system) about a month later, on 2016-04-25.
I’m extremely happy with the current simplicity of the game rules, but as usual, it took a lot of playtesting and experimenting to get there. After the initial idea about pieces that gain additional movement possibilities over time, I had a lot of different ideas about how the game should play. But first I had to make a prototype.
I bought some cribbage pegs online, and then spent a couple of afternoons in my friend Lloyd’s garage with his drill press. Once I had a physical prototype, I started playing versions of the game wherever I could, often with pretty wildly different sets of rules.
Ideas that were interesting, but didn’t quite work included: allowing piece rotations; action point allocation for placing pegs and moving around the board; using the checkmate mechanic from Chess; using different colored pegs for different movement mechanics; recycling (repurposing) the pegs you capture from your opponent; forcing your opponent to put pegs in their remaining pieces when you capture one (with the end-goal to make them fill up a piece); and all kinds of ideas related to scoring based on the number of pegs in your control. Some of these were more complicated than others, but all of them resulted in a far more complicated game than the game as it exists today.
Notably, in this period of floundering around, I sat down with Patrick Leder (at GlitchCon a local game development conference here in MN), and also Nick Bentley (at Gencon 2016). I don’t think either of them were all that impressed, and around that time, I basically shelved the game for about a year after that.
In the summer of 2017, I signed up for a table to show my games at the Twin Cities Maker Faire. Most of my games are for touchscreens, so faced with the prospect of a 10-foot table mostly empty but for a couple of phones and an iPad, I decided to lay out Eigenstate. This meant I had to explain it to people very quickly. Without referring to my notes, and pretty much off the cuff, I decided on the simplest possible rules I thought would produce a playable game. Essentially you only needed to remember to do two things on your turn, move a piece, and place some pegs. (I decided on two.) It was just piece elimination, the easiest possible win condition to explain. I’d playtested variations on each of these rules separately, but never in that combination, and again, always as part of a more complicated ruleset.
I was a bit surprised by how well the game played with those simple rules. The game was played a bunch of times throughout the day, with really positive reception. I think if there is any part of the design I’m still looking for specific feedback about, it’s the victory condition. Capturing your opponent’s pieces is fine, but it doesn’t feel very unique.
In quantum physics, the term eigenstate refers to the possible movement of a particle. It’s a bit more complicated than that, of course, (and honestly, I have only a slippery grasp on the concept), but once I hit upon quantum physics (and in particular using the uncertainty principal as a metaphor for movement in the game), I began hunting around for suitable quantum physics terms. I think there’s a cool extended metaphor about each of the pieces being particles in a system, and the players competing to observe their opponent’s system first. How moving your own particles (pieces) helps you observe that system is left as a thought exercise for the player.
It’s worth noting that the rules as written don’t really reflect this metaphor, and I’m not sure they will (other than some flavor text) in the final version. As with the idea itself, I know when I came up with the name, on 4/26/2016.
I am very pleased to be able to announce that Eigenstate is slated for publishing by Adam’s Apple Games. Adam has already 3d printed some additional copies of the game, and it’s being playtested internally. It will probably get a kickstarter later this year sometime.
For years I’ve been a very vocal proponent of the Experimental Gameplay Workshop at GDC. This year’s session hit the internet quite fast (over on the GDC Vault), and I consumed it last night. As usual, I’d definitely highly recommend game designers and developers give it a watch.
Often, I want to refer back to the session after, or follow a particular work I saw there, but it can sometimes be quite difficult to find a list of participants for a particular year. This year’s seemed especially un-google-able, so I’ve compiled a list here:
Baba is You, Arvi Teikari – A sokoban-like game where the rules of the game are also pushable blocks, and can be rearranged.
Untitled Goose Game, Nico Disseldorp & Stuart Gillespie Cook, House House @house_house_, A game where you play as a goose and interact with your environment and an AI controlled gardener to complete objectives.
Everything is going to be Okay, Nathalie Lawhead @alienmelon, This is an art game, or “an interactive zine”, that focuses on using humor to confront modern horrors.
Noita, Petri Purho Nolla Games – An action rogue like game where every pixel is simulated, which means they are both destructible and have real-world (and fantastic) properties.
Time Watch, Balthazar Auger and Lucas(?) from NGD Studios @ngdstudios – A FPS that allows you to play a single death-match three (or more) times, all the while altering causality.
Feng Shui, Saúl González and David Marull from Ludopia @LudopiaNet – A puzzle or architecture game allowing you to place furniture in a room and incorporating the principals of Feng Shui.
Luna, Robin Hunicke and Brad Fotsch of Funomena @funomena – Luna is a VR game with music and flowers.
Freeways, Justin Smith from Captain Games @manbearcar – A game about drawing freeway lanes and making efficient paths.
La Tabla, Chaim Gingold and Luke Iannini @tablaviva – An open source table and projector combination with lots of exciting possibilities for interaction and play.
Of these, I was most surprised by Baba is You. It won two IGF awards, so I guess I wasn’t the only one. I have already downloaded the game jam version from Itch, and played through all the levels. I am definitely going to pick up the full thing when it launches on steam.
I have also been following Dynamicland when I can, and I’d be interested in hearing about the relationship between La Tabla and it. I know that some of the people involved are or were involved in both, but that’s about it. Maybe I can interrogate someone about it at Eyeo Festival in a couple of months. La Tabla is on github, and I’m pretty tempted to put together a table so I can play with it myself.
I’ve participated in a number of game jams over the last ~7 (or so) years. For the most part, these only get posted somewhere online when either it’s part of the process of “completing the jam”, or if I’m working with a team, and someone else takes the helm. I’ve decided I should be keeping track of these somewhere, and that place is, for the moment, organized chronologically below.
I first attended 360iDev in 2011, and participated in the overnight (13 hr) game jam there. As near as I can tell/remember, I made a real-time, abstract-board-game-inspired, iPad game I called ColorWheel. (The code was native iOS.) I wrote-up the experience in the second-half of this blog post.
I did my first Global Game Jam (GGJ) in 2012, creating a board game (with actual artwork by August Brown!) that weekend called Eat Thyself. The theme of the jam was an image of an ouroboros.
I went back to 360iDev again in fall of 2012, and collaborated with another developer, Levi Brown, to make an iPhone puzzle game called Cloud Growth.
In 2013, my Global Game Jam entry (which somehow didn’t make it to the GGJ website) was a card game with app component, I called Heart Burn. I write a bunch about it here. August Brown again supplied some artwork, although I’m not sure how much of it saw the light of day.
In January 2014, I participated in the Global Game Jam with a bunch of other IGDA Twin Cities regulars, and (I believe) this was the first time I’d worked in Unity. There were so many of us (9!) that we actually made 4 games, (almost 5), and bundled them up as Saga of Candy Friends. (A name influenced by King.com trying to trademark/copyright “saga” in a game’s title around that time.) They were all local multiplayer games. As the person least familiar with Unity, I played pickup, and ended up working on a bunch of the games. I was most proud of (and probably spent the most time on) the one called bird drop. Afterwards, I wrote a postmortem on this blog.
For the 2015 Global Game Jam, I created a block-matching game for the L3D cube called Match-L3D. The L3D is an 8x8x8 cube of LEDs, and really has to be seen to appreciate. I really liked this game, but because it requires the custom hardware (and an xbox360 gamepad, as well as a computer to drive it), I doubt there are more than a handful of people who have played it.
Not quite a game jam, but my 2016 new year’s resolution was to come up with a new game idea every day. I did this pretty faithfully through about mid-july, and didn’t truly give up on the idea until sometime in September. I wrote up weekly recaps through July 15th (28 of them!), and fully intended to categorize every idea and do a summary post for the whole year at the end of it. I’ve got a spreadsheet that categorizes the first 130 ideas (through week 13), and someday maybe I’ll finish that project.
My 2016 Global Game Jam game was called Life is Hard. It was very shortly after my decision to take development with Unity more seriously, and I teamed up with August Brown, Mike Manor, and Jason Pfitzer to create a set of 3 or 4 (I can’t remember how many of the ideas we got to) mini-games around menial daily tasks. I was the only programmer, but learned a lot about Unity’s animation system from Jason, who did most of the art.
I also took part in the Midwest Game Jam in 2016, creating a VR game (targeting HTC Vive) with two other developers in 24 hours, that we called IndustriElf. You play as an elf assembling toys in Santa’s workshop.
In 2017, I didn’t have time to fully participate in the Global Game Jam, but I brought my 6-year old daughter to the Friday night brainstorm, and we made a little bubble-popper game called Bubble Jumper with only a few additional hours on Saturday. The game was entirely the realization of her ideas, and her wireframes (which we didn’t fully implement) were especially great.
My 2018 GGJ game was another collaboration with August Brown, a very cute looking tetromino-placement puzzle game called Tetro Buddies. (The name was courtesy of my 9 year old niece Weather.)
Most recently, (two or three weekends ago, as of this post), I worked on a game in Pico-8 for the 2018 Midwest Game Jam called Emergent Sea (playable if you click through, but read the instructions posted below the cartridge first). The team was four programmers including myself, Scott Lembcke (who also did the art!), Ben Gartner (who also made the music!), and Chris Phan (who contributed a ton, especially considering this was his first game and game jam!). It was my first time really writing anything in Lua, and I rather liked it. The theme for the jam was: emergence (but the game’s name pun credit goes to Scott).
I think I found them all, but who knows. In the future I’d like to make a “page” out of this list, and link it somewhere more prominently. (Maybe with images from each of the games!) I’ll add a link/note here if I do that, for posterity.
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):
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.
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.
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.
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!)