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!