Xcode tips and keyboard shortcuts

I love working in Xcode. It was my first “real” IDE experience, and while I still use vim pretty regularly it’s generally not for editing code (anymore). These days, whenever I’m not working in Xcode (lately it’s almost always Visual Studio on Unity projects), I’m wishing I was.

I read iOS Dev Weekly (https://iosdevweekly.com/) most weeks, and it was via that lovely resource that I discovered this great GitHub page full of Xcode-Tips (https://xcode-tips.github.io/). I already helped include one tip there (about enabling spell-check), and this post is inspired by one of the tips I found there in particular, about using `cmd-shift-j`. 

Xcode is a 3 panel layout. The middle panel where you actually edit code can be split up in a number of ways, (tabs within tabs? c’mon), but I won’t go into that in this post.

The left panel is called the “Navigator”. It has tabs across the top and defaults to the first tab, or “Project Navigator”, showing all the files in your project hierarchy. 

  • Filesystem tip/aside: When I first started using Xcode I was surprised to learn that files presented here are not necessarily 1-to-1 with the files on the filesystem. On one of my current projects, we are using the awesome open source XcodeGen (https://github.com/yonaskolb/XcodeGen) to generate the project from files on the filesystem. It’s actually called from a script that we run from a git checkout-hook, so we almost never have to think about it. This was a new-to-me workflow, but has a lot of benefits, including keeping the project files consistent with the filesystem!

Keyboard shortcuts relevant to the navigator:

  • Hide (or show) the whole Navigator pane with `cmd-0`. (That’s a zero.)
  • Jump to any of the tabs in the navigator with `cmd-<number>` where number is the index of the tab. So `cmd-1` opens the Project Navigator. This works even when the Navigator is hidden!
  • Best of all, the aforementioned `cmd-shift-j` will open the Project Navigator and select the file you are currently editing. You can then use the up or down arrows to browse different files, and `cmd-j` and then `enter` to return to the code editor.

The panel on the right side of Xcode is the Inspector. It too has tabs, and what’s great is that the keyboard shortcuts are very similar to the ones for the Navigator, but with the addition of alt:

  • Show/Hide the Inspector with `cmd-alt-0`.
  • You can also jump to one of the tabs with `cmd-alt-<number>`, again, where number is the index of the tab. What’s interesting here is that there are a different number of tabs here if you are editing an interface builder file. (I don’t think I’ve ever used these shortcuts.)

In general, I am far more likely to want to hide the Inspector pane than the Navigator pane, so it’s kind of a shame the shortcuts to show/hide them aren’t reversed (not to mention the fact that cmd-alt is a difficult combination on my Moonlander keyboard, but of course I could fix that).

I wrote this up in part so I can create another PR and reference myself as the source for a tip about showing and hiding these panes, but this post was also inspired by sharing with another member of my team that I do the majority of my development on a MacBook, without external monitor. <insert scream emoji> One of the aspects that makes that experience tolerable are all these keyboard shortcuts that let you maximize the space you’re using to edit code quickly and easily.

I hope you learned something from this, but if you didn’t, go check out that Xcode-Tips site, because you’re sure to learn something there!

Played Log 2020

I kept up my played log through 2020, and I ran some analysis again this year.

One thing to note is that I don’t think it’s as valuable as my (admittedly quite brief these days) goodreads book reviews. I’ll be looking for a way to maybe improve on that this year. (Maybe writing periodic reviews of games I’m playing?) Games seldom have the same finality that a book does. Usually my interest wanes or is diverted to other games, and I just stop playing them without reflection. So knowing when to write the review would be maybe the hardest part! One option is to write something down any time I play a new-to-me game. I might try a few different things.

Stats and Observations

Again, not a day went by without at least a game or two played. There were 297 unique games logged. (Although there is probably a statistically significant number of those that are misspellings or differently-worded versions of the same game. 186 of those games were only played on a single day.)

Here are the top ten games played with the number of days that I played them:

  • stone age: 189 
  • good sudoku: 162
  • go: 158
  • innovation: 147
  • blooms: 73
  • animal crossing: 67
  • teotihuacan: 55
  • thrive: 52
  • hive: 40
  • pixelpuzzle: 37

This is definitely a skewed list, because for most of the board games on that list, I was playing async games on BGA. This means, most of those days I didn’t actually finish the game, only played a turn or three. 

The only real surprise on there for me was Hive. I didn’t really think I’d played that many games of it, and I also think of it as a relatively fast game to play. So I did some digging, and sure enough, when I look at my BGA profile, I only played 13 games of Hive, it just took me 40 days to play those games. Amusingly (and so coincidental that I’m rather skeptical of BGA’s statistics), I also finished exactly 13 games of Go, AND 13 games of Stone Age.

Here’s a top ten list of games not on BGA:

  • good sudoku: 162
  • animal crossing: 67
  • pixelpuzzle: 37
  • diablo 3: 27
  • forager: 22
  • satisfactory: 20
  • picross s4: 19
  • picross s3: 19
  • i love hue too: 18
  • hades: 17

Obvious if you look at the numbers, I played a lot of Good Sudoku. I do highly recommend it, especially if you are interested in getting better at sudoku puzzles, or anyway learning additional techniques for solving them. There are three daily puzzles, and the app keeps track of your “streak” for each. I am currently on a 97 day streak for the main game mode. There’s some kind of comparison to be made with the desire to keep up my streak and a sunk cost fallacy. Opening this app is typically the last thing I do before bed, and often the first thing I do when I wake up. 

I was surprised to see PixelPuzzle in this list again. I finished all the puzzles last year, but there is a games+ kind of thing going on. I didn’t play Picross nearly as much as last year because I totally fell off doing my workouts when covid quarantine hit. (I was no longer going to the workout room in my building and doing the elliptical with a switch strapped to the machine.)

I’m happy to report that I did eventually resume daily workouts, (but not until November). Now in my living room. Still playing the Switch tho, it’s hard to hold a traditional controller and do any actual movement.

I only started playing Hades in December, so the fact that it made the list at all is pretty impressive.

I also tracked what platform I played the game on, and here’s the number of entries for each platform. (Note that I usually have 5-10 games going on BGA at once, and typically take my turns two or three times a day, but I would only count each game once per day, but if I played 5 games on BGA, that would count 5 times for these numbers.)

  • bga: 1050
  • ios: 319
  • switch: 258
  • pc: 70
  • web: 20
  • xboxx: 14
  • ps4: 14
  • quest: 8

Nintendo weighs in

Those of you with a Nintendo Switch probably recognize the screenshot above as coming from Nintendo’s year-in-review email. I was not terribly surprised to have played twice as many hours of games as in 2019, but I was surprised that it was fewer games in total. My guess is just that spending more time playing (due to pandemic quarantine) led to getting more sucked into a few games in particular.

About the log itself

Two things of note: the first is that I was much more rigorous with keeping up the same format for each day of the log this year. So parsing the log didn’t involve any data “fixing” at all, which was fantastic. (In pretty sharp contrast to last year.)

Secondly, I wrote the log parser last year in python, and while it was perfectly serviceable, when I went to run it again this year, I wanted to do some additional analysis. It was daunting enough looking at last year’s script that I just re-wrote the entire thing in Swift. I spent at least a few hours over the course of several days on the python script last year, and I did this year’s Swift version in about an hour. I’m crediting advent of code for how easy it went. 

Worth noting I only made it through day 18 of Advent of Code, but I just realized I only put it in my game log a few of those days. If I’d put it in all the days I actually did it, it would have edged out Hades in my top 10 played list!

Blinks 3D Printed “simulator”

I’ve previously only mentioned once on this blog (in passing) that I spent some time a couple of years back working on a prototype for the Blinks game system (https://move38.com/). I backed the first Blinks Kickstarter, and was very excited to make games for the platform when I received my development kit.

I worked the most on a game called Takeover (https://github.com/mgrider/takeover), which I’ll admit doesn’t take advantage of the real-time possibilities that Blinks as a platform affords. It uses the digital aspect for a sort of rules enforcement, but the game is more or less a traditional board game, gussied up in fancy LED clothes. It’s got fairly simple rules that you can read on the Github page linked above (in the README.md file that is automatically displayed on that page). Although since I’ve made a physical prototype, (more about that in a second) I’ve been experimenting with different rules variations.

Takeover was well-received at the events where I showed it off, but much like demoing VR, it’s hard to gauge whether that reception was for the game I’d developed, or the medium in which it was presented. In contrast, Takeover had a rather lackluster reception on the Blinks forums, so I sort of soured on making another game for Blinks. Or probably more accurately, I just didn’t have another idea that compelled me to spend the time it would take to code it for the platform. (It’s also worth noting that all of this happened before I got the final retail version of Blinks in my hands, and by the time that did occur, I hadn’t worked on anything Blinks related in several months.)

Fast forward about a year, and it occurred to me that, precisely because Takeover doesn’t use the Blinks platform to its fullest advantage, it would be entirely possible to play it with only physical components. This of course led to the question of what those components would look like.

I landed on 3D printing hexagonal trays with “slots” for 1 cm cubes to sit in. Because I think there’s a chance other game designers have these 1 cm cubes laying around, and they might also have access to a 3D printer, I’ll also make the .obj file available for download.

Click this image to download the corresponding .obj file.

To use this, you’ll obviously want to print a bunch of them. I think there are lots of possibilities for these above and beyond “simulating” blinks games. If you come up with something cool, please let me know!

Formal Game Representations

There are a few different specialized “languages” out there now for describing games. Perhaps because Abstract Strategy games are often quite “simple” in terms of rules complexity, these sorts of game description languages typically have examples that are abstract strategy games. (But also, I think, there’s probably an overlap between people interested in this topic and people who are interested in games that require an extraordinary amount of logical analysis to play.)

I have been very interested in this topic many times over the years as I became aware of various projects and aspects of this topic, and this post will be my attempt to outline some of my findings.

Early game description work / History

There is a relevant “History” section of the Wikipedia article on General Game Playing (https://en.wikipedia.org/wiki/General_game_playing#History). This is a page on Artificial Intelligence (AI) that can play multiple games – as opposed to a specialized program that just plays a single game like Chess, for example. The article says that this concept was first proposed by AI researcher Barney Pell in 1992, with something the article called a “Metagame System”. Pell’s research, at least some of it, is still available via the wayback machine, and I read through one article called “Metagame: A New Challenge For Games and Learning” (https://web.archive.org/web/20070706185808/http://www.barneypell.com/papers/metagame-olympiadUCAM-CL-TR-276.pdf) from 1992 that was surprisingly readable (and fascinating). In it, Pell says:

“In order to write programs which can accept a set of different games, we must specify how these games will be represented. Although fully-general representation languages are possible (like first-order logic or Turing Machines), it is likely that classes of games will be much more specific, especially those which can actually be produced by a generator. So, any representation language can be used, so long as the games produced are guaranteed to be unambiguous in the chosen representation, and so long as the semantics corresponding to the representation is clear. A natural method of representation, pursued in ([Pel92]), is by means of a game grammar.”

Metagame: A New Challenge For Games and Learning

“[Pel92]” here refers to a companion article titled Metagame in Symmetric Chess-Like Games. This second article does get far more into the weeds with details about the game grammar used to define games that the Metagame-playing AI will learn to play. I found it actually kind of disappointing, because much of the article is dedicated to defining the types of game the grammar will describe, and it was surprisingly limited in scope.

It’s worth saying a bit about the context of these papers, and noting that this research is all about developing AI. The premise here is that an AI that can play multiple games would be more useful than an AI that can just play one game. The whole point of this project was to be able to pit different AI against one another in a tournament. This grammar was going to be used both to more easily facilitate the AI learning the games, but also to generate new games so the AI would be playing something never before encountered.

This is probably worth repeating: The earliest effort to formalize a language for describing games was only undertaken in service of an effort to teach games to computers.

Zillions of Games

I remember playing a program over 20 years ago now called Zillions of Games (http://www.zillions-of-games.com/). The copyright on the ZoG website says 1998. I remember using it to play Othello and many Chess variants, and (perhaps more importantly) explore a ton of other games that I’d never heard of before Zillions. They were probably also games that it would have been near-impossible at the time for me to hunt down in physical form.

Zillions of Games came bundled with ~250 games, each of which was described individually in a .zrf (presumably “Zillions Rules File”). If you owned the full unlocked copy of the game (this was the shareware era when game demos were near ubiquitous), you could import your own ZRFs, and there was (amazingly still is!) a community of folks who spent time implementing new games.

I have a very distinct memory of liking Zillions of Games enough that I wanted to learn how to develop games for it. But I was in college at the time, and distracted by many other things vying for my attention.

You can find some information about ZoG, and the language used to encode the games, on the website, but also on Wikipedia (https://en.wikipedia.org/wiki/Zillions_of_Games). The description language for ZoG is lisp-looking, (with parenthesis everywhere). I only call this out because it’s influenced future projects with this gaol. ZoG had lots of limitations. It was notably not suitable for card games or other games that required any hidden information, probably because ZRF had no concept of variables!

It’s worth noting that, while it’s not exactly the same thing, I do see a parallel between ZRF creation and other platform-specific game creation languages, like Game Maker Studio’s GML, or Godot’s GDScript. Zillions of Games was a Game Engine as well as a product that allowed the user to play the games made in that engine. The games just happened to be board games.

Ludii

More recently, (in the last few years), I’ve been aware of a project called the Ludii General Game System (https://ludii.games/). This is (at least partially) the brain child of Cameron Browne, a game designer, computer scientist, and author, who is very well known in some abstract strategy game design circles. He wrote a book on connection games that I have on my shelf.

Ludii has some very interesting project goals, but more importantly, the project has now written description files for literally over 300 games. (There are over 2,000 games with descriptions for use in Zillions of Games, but that software is quite old now, and I think Ludii is far more interesting.)

You can download Ludii now, and play all of the games it comes bundled with, and even create your own .lud files and load them into the player. There is a language reference for Ludii (https://ludii.games/downloads/LudiiLanguageReference.pdf) that is 386 pages long!

To really dive into Ludii development, unfortunately, I don’t think the language reference is going to be enough. There is also a Ludii tutorials document, but I found it a bit disappointing in its brevity. As of this blog post, there are really only two pages that are particularly relevant to writing your own .lud files. This one on the “basics”: https://ludiitutorials.readthedocs.io/en/latest/lud_format_basics.html and another one on recreating the game Amazons in Ludii: https://ludiitutorials.readthedocs.io/en/latest/tutorial_amazons.html I also watched a nice introduction to Ludii on youtube. (https://www.youtube.com/watch?v=pTkO8h8RBBI)

I’m in the process of posting a few different places (in various BGG forums) to see if there are better tutorials that I’ve just been missing.

Other systems

For the sake of putting everything I know about this subject into this post, it’s worth noting there is another competitor to Ludii that may have been around even before it, called GDL, or Game Description Language (https://en.wikipedia.org/wiki/Game_Description_Language) GDL looks like it was developed at Stanford, very likely in conjunction with some AI coursework. I’ve dug around some of the GDL related sites and there are broken links galore, but there’s lots of information about it online. Some of the earlier Ludii papers reference GDL, so I’m fairly certain it came first.

There is ALSO a javascript project called Dagaz (https://github.com/GlukKazan/Dagaz) which shows quite a bit of promise, and has been used to port all of the games at MindSports (https://mindsports.nl/) from java to javascript. The author of Dagaz write a very nice article on some of this stuff (which someone else translated to English), which you can read here: https://habr.com/en/post/481868/

One more footnote is that there is another comparatively young project aiming to do some of this same kind of stuff in python called Zero Play (https://donkirkby.github.io/zero-play/).

Conclusion

So it seems to me that there are a few reasons someone might be interested in describing games (in a language tailor-made for that purpose):

  1. To improve and teach generalist AI to play multiple games.
  2. To generate new games programatically.
  3. To use a common codebase to facilitate the playing of games.

I am interested in all of the above. Although the implementation details of AI optimization and improvement are not in the circle of my particular venn diagram, access to generalized AI is of interest to me. (I thought about splitting #1 into multiple bullet points.) It’s worth noting that the last project mentioned above (Zero Play) is named after AlphaZero, (https://en.wikipedia.org/wiki/AlphaZero) a general game playing AI that was created by the same team that made AlphaGo. (AlphaGo being the Go-playing AI that famously beat one of the best human Go players in a series of very public games in 2016.)

The second bullet point is definitely one of the goals of the Ludii project, and one that Cameron Browne has extensive experience in. Games which have been created by computers are listed in a “family” on Board Game Geek (https://boardgamegeek.com/boardgamefamily/22566/misc-computer-generated-games/linkeditems/boardgamefamily), (containing at this time only three entries, two of which have Browne listed as designer). Probably the most well-known AI-created game is Yavalath (http://cambolbro.com/games/yavalath/), which Browne created using an earlier program (called LUDI) while he was working on his Ph.D. in 2007. While the earlier work by Barney Pell definitely indicated this was an objective, I didn’t find any evidence that it succeeded.

Finally, it is the facilitation of a general platform for game playing (& playtesting!) that I think a description language will be most valuable to me, personally. This is the primary reason I am interested in Ludii. Ludii’s platform (java application, but also online multiplayer) seems very stable, and has an increasingly tantilizing list of features. There is a category of simple games in particular (with simple rules) that seem to be a very nice fit for the platform. On their forums, the Ludii team have said that web-playability is on their roadmap, and that will lower the barrier to entry even farther.

I am going to try and implement some games in Ludii, and evaluate whether it’s a good platform for playtesting new games. It already includes features for analyzing games like 1st player advantage, and branching factor. These are metrics for their games that every game designer will probably find interesting.

Update:

After writing this post (and promoting it on BGG), Cameron Browne actually pointed me to some additional resources relevant to this discussion, (which led me to even more resources) and thought I’d drop some additional bullet points in here.

  • Brown pointed me to an article by Jacques Pitrat from 1968 called “Realization of a General Game Playing Program”. In his words: “… doesn’t specify a GDL as such, but shows that the idea of GGP has been around for more than half a century!”(https://www.semanticscholar.org/paper/Realization-of-a-gener…) Alas, I haven’t yet found a way to access the paper.
  • Jon Orwant wrote his Ph.D dissertation in 2000 about what he calls the EGGG (Extensible Graphical Game Generator): https://dspace.mit.edu/handle/1721.1/9164
  • Stephen Travener’s program Ai Ai uses a description file type called MGL, for Modular Game Language (http://mrraow.com/index.php/aiai-home/mgl/). It’s worth noting that Stephen Travener is a person quite relevant to this discussion, as he has worked on both Zillions of Games and Ludii, as well as his impressive Ai Ai software, which is also capable of playing and analyzing hundreds of games.
  • Browne pointed out that there are description languages for card games (I haven’t done any research into this yet.) and Video Games. Specifically, he pointed me to General Video Game Description Language (GVGDL), which I haven’t been able to find in a quick search, although there are plenty of hits for VGDL, and I haven’t really looked into that yet either.
  • Finally (again), the Ludii project website has a history page that I hadn’t read until after posting this. It outlines the history of a few other projects that led to Ludii’s creation, including Browne’s previous project Ludi, which I at least mentioned earlier. Well worth a read if you’re interested in more on this topic. (https://ludii.games/history.php)


Thrive – IGDA Twin Cities talk

Last night I gave a talk (on twitch.tv/igdatc, as all of our IGDATC talks have been for the last 6 months) about Thrive. It was basically a retrospective on the design and development of Thrive as a physical board game as well as a bit of a preview of Thrive as a digital board game app. You can watch the talk on YouTube already, but I’m also embedding the slides here for posterity.

Incidentally, I am now distributing the Thrive app on TestFlight, so if you see this and want to play it on your iPhone, let me know, and I’ll send you a link!

Games and Resolutions

So in 2019, I decided kind of arbitrarily to keep a journal of all the games I played for the entire year. There was no real purpose to this, just maybe wanting to be able to look back on it and generally keep track of the games I’ve been playing. (I log all the books I read on GoodReads out of a similar need to keep a record of things.) I can remember anecdotally that there were several times throughout the year that I wanted to remember the name of a game, or recall something about an event I’d been to, and the journal came in handy for that.

So after some normalizing of the journal (which is just a text file) it had 365 lines in it, each starting with a date, followed by a comma separated list of games. I wrote a simple python script to parse the file and output a list of game names in the order of the number of times that game appeared in the file.

Here are the games I played in 2019 that I played on at least 10 days:

  • nintendo labo vr : 10 days – This was almost always played with my kid. Pretty fun parent/kid bonding activity. I have a bunch of cardboard left to assemble in a closet somewhere. I should suggest it again sometime soon.
  • splendor : 10 days – This is my niece’s favorite game, and we play it whenever she comes over.
  • innovation : 11 days – I got back into this game toward the end of December. I’ve been playing it pretty much daily on Board Game Arena.
  • pinball wizard : 11 days – This is maybe my second or third favorite Apple Arcade game. I assume there is an ending, but I haven’t gotten there yet.
  • art inc : 13 days – One of those garbage games I mentioned, I probably played this for two weeks straight.
  • manifold garden : 13 days – My guess is that I would have played through this in a lot fewer days if it’s release hadn’t coincided with my trip to Germany for Essen Spiel. I really loved this game though, and at least one or two of those days were after I’d finished playing it, and started over again from the beginning. My game of the year pick for 2019.
  • dino people : 15 days – Another free-to-play idle game. Cute low-poly dinosaur art. Not much else going for it.
  • yonder : 16 days – I wanted to like this more than I did. It’s got a lot going for it, but I didn’t stick with it.
  • grindstone : 17 days – Another Apple Arcade game. I still enjoy this one on occasion.
  • baba is you : 19 days – Man, I wish I was better at this game. I refuse to look up solutions, so there are quite a few levels I’m totally stuck on. I do think I make progress every time I play, but it sometimes feels like I’m Sisyphus with this one.
  • lumines : 20 days – So much nostalgia for playing this on the PSP! I do love this game in most iterations. I actually started writing a blog post about it, but didn’t feel like I was saying anything important, so I shelved it. Probably in my top 5 game franchises of all time.
  • 1010! : 21 days – This is a staple when I want a monotonous puzzle. A good game for playing while I’m “watching” TV.
  • thrive : 24 days – I’m a bit surprised this wasn’t more, but when I was demoing (and actually playing), I sometimes put in around 10 games per day!
  • picross s2 : 27 days – Nothing helps me zone out like Picross. I can predictably do my 20 minute workout without noticing that time has passed other than between puzzles.
  • shards of infinity : 29 days – I got pretty into this after I met the developer at GDC. I think I was on the TestFlight at first, but I played it regularly for quite a while even after it came out.
  • cats are cute : 37 days – Another free-to-play. Black and white line-drawn cats. Cute.
  • adventure communist : 66 days – Ugh, this game. It’s such a skinner box. I’m still weaning myself off it, but I think I’ve got it down to once a day, or maybe even every other day, at this point.
  • wizards unite : 86 days – I played this regularly for a while over the summer. I’m over it now tho. I like the story, but of course they’re going to dole it out so slowly… probably not worth it.
  • picross s3 : 89 days – I think it was at lunch at MinneBar 2019 when I mentioned to Stephen that I was playing a ton of Picross S2, and he blew my mind by telling me there was a third one.
  • pixel puzzle : 113 days – This is a really nice mobile Nonogram/picross implementation. It’s totally free and all the art in it is from Konami games. I finished all the puzzles.

Reviewing the list for this post, some points I think are worth noting:

  1. There was not a day in 2019 that I didn’t play at least one game. (Yes, I am somewhat proud of this.) But quite a few of the items on the list are what I consider to be relatively garbage games. (Endless idle games with ad monetization, for example.)
  2. I’m fairly certain the journal is missing a statistically significant number of games. In general, I thought I was very diligent, but I noticed that especially when I’m playing board games in a group, it can be especially hard to remember. Most recently, I was going through photos I took in 2019, and realized that I’d taken a bunch of photos of games that I didn’t write down because I figured I’d do so later.
  3. My second most played game last year was one I basically only play on the Nintendo Switch while I’m working out on an elliptical machine.
  4. There are a bunch of abstract strategy games that I played almost 10 days. And if you counted the number of times I played them each day, I played many of them much more than 10 times. These include Nick Bentley’s Blooms (a recent obsession), Santorini (which I played 9 days in the iOS app), and Control-V, which I picked up at Spiel.

I’m definitely going to continue this journal, and this year I’ll make it a point to keep the format a little more strict than I did last year. (I definitely had to do a lot of massaging to get some parts of the journal to parse correctly.) It was really neat to look back over this list!

Design Journal Notes for 2019

Most people I know have heard me talk about how, back in 2016, I tried to write in my game design journal every day. So many good game ideas came out of that experiment that I’m still designing and developing games from that year to this day. (Notably, I had the idea that eventually became Thrive in that year.)

I always meant to write a “wrap up” post about that experiment, but I got bogged down in trying to categorize all the journal entries. I have a spreadsheet I started with a row of 26 checkboxes for each entry. The column headers were:

  • Board Game
  • Video Game
  • Mobile Game
  • Physical Game (Not board game)
  • VR Game
  • Idle/Unfolding Game Idea
  • educational game
  • mechanic only
  • puzzle
  • story
  • expands on previous idea
  • expanded on in later post
  • made prototype
  • feel really has merit
  • multiple ideas in one post
  • 2nd second entry that day
  • 3rd third entry
  • felt rushed or inconsequential
  • short (under a paragraph)
  • long (half a page or more)
  • could be complete (playable if prototyped)
  • would need a team to implement
  • skipped for blog post
  • expanded on in blog post

I clearly made the task extra difficult for myself by including whether the post was expanded on elsewhere, because it was no longer just skimming through the journal, it was also cross-referencing my blog, as well as other entries in the journal. I only made it through categorizing 3 months of posts before I lost steam.

Since 2016, I never really “stopped” trying to write regularly in that journal, but I was definitely not diligent about writing every day. I spent some time and just tallied up number of entries in that journal per year (yes, this was more time than I probably should have spent), and here are the results:

52010 (and undated, before 2010)
12011
72012
162013
302014
322015
3122016
372017
1792018
1952019 [was 183 as of this post date]

[It was only the 19th when I write this. I updated this post with the final 2019 total on Jan 2nd 2020.]

This means, if my math is correct, my game design journal contains somewhere around 802 entries. It’s currently a 254 page single spaced gDocs document (so I can update it from anywhere).

I took some notes about each month in 2019:

2019-01

  • 16 entries, 1 from a dream
  • A few entries about the Thrive expansion
  • Some ideas & feedback from Protospiel MN (Especially about the “pyramid tile” game, which I had as a prototype there.)
  • An entry with a bunch of ideas I had at Global Game Jam, but didn’t have time to implement there.

2019-02

  • 10 entries
  • A notable entry about a Puzzle Prison “static puzzle” mode (which is a good idea, and I should do it)
  • More Thrive entries, three of them about multiplayer

2019-03

  • 9 entries
  • Month started strong, then no entries for a couple weeks (Only one the entire week of GDC!)
  • Hard to believe this was the month the Thrive kickstarter ran.
  • There were 3 entries about Thrive puzzles (which I spent several days actively designing toward the beginning of the month)

2019-04

  • 7 entries
  • One of them was when I first started thinking about the “next” version of Ship Deck (which I have only recently sent off to get printed at Game Crafter) – Interesting that it took me 8 months to finally act on those ideas.
  • Some important Thrive rules clarifications & revisions.
  • Only one real “new idea” from the entire month!

2019-05

  • 6 entries
  • One entry was a list of the types of game ideas I want to have. (Seems like a cop-out in terms of actually generating ideas, but even looking back on it now I think it’s probably a helpful exercise to clarify the purpose of the journal periodically.
  • 4 of the 6 ideas were about a tile-and-meeple board game prototype I made that I still think shows promise.

2019-06

  • 6 entries, 1 from a dream
  • Made a lego copy of Thrive
  • Low volume, but high quality this month. Every entry (except the dream) was an interesting idea that I continued working on (or at least thinking about) in some way.
  • Last entry was a game with transparent pieces with arrows on them that I prototyped and play tested a few times. (As well as continued to think about.)

2019-07

  • 11 entries, 1 from a dream
  • Only 2 entries before 7/23, which is when I decided to begin trying to write an entry every day again. I probably felt guilty about the creative dry spell.
  • Notable entry that included lots of the pieces (mechanics) of a game I’ve been thinking actively about this month (in December, so 5 months later). What’s interesting, is that my thoughts on this game lately have been inspired by Innovation (Innovation is a Carl Chudyk game that until this month I haven’t played in many years. I’ve been playing it turn-based on BGA.). But when I wrote this entry, I definitely wasn’t thinking about Innovation.

2019-08

  • 25 entries
  • Many (at least 3) of them about a engine-building game I’ve since prototyped, tentatively called “Black Box”. The basic idea (and theme) came from a conversation with Adam Rehburg and Ryan Lambert in the car on the way back from GenCon.
  • Had the idea of playing games via FlipGrid.com (still haven’t tried this)

2019-09

  • 25 entries, 1 from a dream (not mine!)
  • Several play testing notes, including Black Box, Pyramid Tiles.
  • But also some notes from games I’d played, including Cabal (https://www.walkingshadow.org/cabal)
  • I prototyped a game with 18 identical cards for a ButtonShy game design contest. Didn’t do anything with it.
  • Wrote down a game idea that was from a dream my kid had. (That was not my only entry from that day.)

2019-10

  • 20 entries
  • A few entries about a game idea that I think shows a lot of promise, but I haven’t prototyped yet. (It’s got a unique hook that I’m not ready to post publicly yet.)
  • Some ideas / entries for ALT.CTRL.GDC that I never took the time to prototype

2019-11

  • 31 entries, 2 that feature ideas from dreams
  • One notable entry with a chess variant / VR hybrid idea. The chess variant could actually be playable on a tabletop, if I gave it a little more thought. The VR does make it slightly more interesting though probably not required.
  • Several “new idea” entries, probably a higher ratio of those to “continuing ideas” entries than previous months.

2019-12

  • 17 entries (so far!)
  • [Update: total for Dec. was 29 entries. I finished the year very strong with several new game ideas, including a small-hex-grid game I’ve since prototyped, and definitely want to get to the table soon. At protospiel in Jan, at the latest.]

Since I got serious about this project again in July, I’ve also been keeping track of my “streak”, or number of consecutive days I remembered to write in the journal. My longest streak was 25 Days, 29 Entries, and it ended on 2019-11-10.

I’m not sure if I’ll continue to keep track of the streak, but I’m definitely going to continue trying to write daily. The actual title of the document is “Game Ideas”, but I definitely want to treat it more like a journal, and I’m formally giving myself permission to wax on about the design of other games I’m playing, or anything else game design related. (Although the goal is still to have at least one new “design idea” in each entry.)

Finally, I was surprised by the number of ideas I wrote down from dreams. I do also have a dream journal, and it barely ever gets written in (I’m guessing only 1-5 entries a year). I wonder if any games have actually been made that started out as an idea from a dream. Maybe I’ll have to make one.

why I prefer not to teach kids visual scripting

I’m actually pretty adamantly biased against visual programming (sometimes referred to as block-based coding, or visual scripting). I’ll elaborate.

First, it’s important that you understand visual programming to be generally more limited in scope and capability than most (though certainly not all) text-based computer programming environments. Most block-based coding frameworks are written “on top of” some other coding environment, and will have only as many features as the programmers of them have bothered to (or had a budget to) implement as a subset of those features and capabilities of the original environment. But it’s also worth noting that the original APIs they are coding on top of will probably be changing as fast (or likely faster) than they have time to implement in the block-based equivalent. So even if the desire is for 1-to-1 feature parity, they will likely always be a subset. (Worth noting that as far as I know, no block-based coding environment has been written in a block based language, they are all coded in some other text-based language environment.)

So why is it bad that it’s limited? This is just for teaching right? Well, my argument is mainly that I believe we tend to prefer to do things the way we first learn to do them**. It seems like most proponents of block-based coding are in education, but I don’t think that the folks teaching it, while they are obviously well-intentioned, realize that there are a limited number of practical applications of block-based coding.

Obviously context matters here. If you are teaching a specific tool that exists for a specific purpose to someone who only wants to be able to do that thing, then maybe that’s fine. I’m mostly opposed to teaching kids (or more even adults) more generally the concepts of coding by teaching them those concepts using visual-coding or block-based coding.

I think it goes like this: if you are presented with the choice of teaching a kid to drag some cool looking blocks around a screen versus getting them to type some (possibly esoteric) syntax into a text editor, then drag and drop seems like the obvious choice! And I can even see an argument that teaching coding concepts, it might seem like decoupling them from a programming-language specific syntax seems like a good idea… but I think most people, when moving beyond learning the initial concepts, are going to prefer to do it the way they first learned it. And that’s where the problem comes in! if the way they first learned to code was with blocks, they’re going to be used to (and possibly prefer!) a fairly limited way of coding.

Code is text. Text is code. “visual coding” is putting a graphic design on top of text. You might argue that all programming languages are built on top of other programming languages, and that’s true, and I’m certainly not arguing everyone should learn assembly before they learn C. But I will argue that you should learn Python before you learn a VPL.

As an aside, I struggled to find a good metaphor for this article. The closest I got was this: It’s sort of like communicating with Emoji. You can definitely get some meanings across, but if you are going to be nuanced about it, or have something very specific you need to communicate, it’s definitely not going to be good enough. But if you never learned to spell, and only learned emoji, you would be at a serious communication disadvantage. This metaphor breaks down pretty quickly though.

**BTW, if it turns out you have (or know about) evidence that I am wrong about this basic premise, I’d love to hear about it. It fits with my understanding of human behavior, but I’m certainly no expert on human psychology!

Spiel 2019

This year I attended my first ever Essen Spiel, the world’s largest board game convention.

Bucket list item: Check.

I came back with this pile of games

…as you can see, they are mostly (but not all) abstract strategy games. And for the most part (with a couple of notable exceptions) they are games that I am unlikely to see in a store here in the states. I haven’t played them all yet, but I have made a dent, and I’ve quite enjoyed Control V, Nova Luna, Hetrix and Stackers so far. My family played a game of Miyabi, and my wife even declared she approved of the purchase!

I was demoing and exhibiting with Adam’s Apple Games, who had, months ago, during the kickstarter, hoped to have Thrive there for sale, but alas, there have been manufacturing delays, and it now looks like it’ll be next March (probably at the earliest) before we see the final production copies. You can see me here standing next to the 3D printed prototypes that we’ve been showing around for the last year or so.

Spiel is more like a trade show (they refer to it as an expo) than most of the other board game related events I’ve been to. Comparing it to Gen Con in particular is interesting, because at Essen there are really no “events” at all. Some exhibitors might post a list of events they are having in their booth, (signings or tournaments most likely), but the convention itself has no designated spaces for events, and doesn’t post a schedule. At Gen Con the expo hall is maybe 1/4th of the designated convention center space, and probably 1/2 of the total space is purely for events. (Many of which are ticketed and cost additional money.) Another difference is that most people expect to actually play games in the exhibitor booths. So most booths, even the smallest ones, have a demo table (or a dozen!), and folks sit down at them mostly to play entire games. Although many of the larger games at the bigger publisher booths (but not all) were just shorter-length demos, which is usually what you get to do, (if anything!), on the show floor at Gen Con. But of course Gen Con has all that additional space for events, most of which are just scheduled times to play specific games.

A lot of people attend Spiel, this year nearly three times as many as attended Gen Con. (If Wikipedia’s numbers are correct, 209k vs 70k.) But for that, it never felt significantly more crowded than Gen Con to me. Yes, there is more physical space, certainly, but I think another factor could be that more folks attend Spiel on day passes than Gen Con, and so you have fewer people at any given time. Certainly Saturday and Sunday did feel very crowded, but I saw very little shoulder-to-shoulder, wall-of-humans that is common walking the expo floor at Gen Con.

You don’t see stuff like this at Gen Con.

You can’t throw a stick without hitting a designer. Not thinking of the attendees so much, but as I walked around the convention, the folks staffing the booths were quite often the game designers themselves. This was definitely not as true in the larger booths, but the smaller ones it felt very common for the designers to be present, and if there was only one person staffing the booth, I’d guess it was 50/50 whether that person also designed a game being shown.

It was super multicultural. There were definitely publishers there from all over the world. I personally met folks from Australia, Korea, China, Spain, the UK, Ireland, and of course Germany. But as large as it was, not all the US publishers were there. I can only speculate why, but certainly some of them don’t think a cost/benefit analysis holds up, but I also think it’s just plain impossible to go to all the events all the time. I’m fairly certain you could find a board game event somewhere in the world to go to every weekend, if you tried hard enough.

I’m definitely glad I went, and I would do it again. I really enjoyed wandering around the show floor and seeing all the new games.