I'm hoping to make some sort of (digital, likely mobile) programming game.
Right now, I have a whole bunch of disparate ideas and inspirations. Maybe they'll coagulate into a single cohesive project, maybe they won't. Let's explore them anyway.
(While I'm still poking around with and figuring out BIP, I'm going to try having them each be separate child nodes.)
There are a lot of games and educational tools to help people learn to code. Many of them focus on the idea of programming a robot, or (famously, with Logo) programming a turtle, or some other fiction that boils down to teaching "programming" as "telling someone a series of procedural commands" rather than literally having you "write computer software".
I'm less interested in that than the sort of programming games that try to teach you some form of assembly language, with no such fictional pretense. Core War is perhaps the earliest example, from the early 80s: it's a competitive head-to-head programming game where your program is executed in the same shared memory space as your opponent's; your goal is to stop their program from executing. It simplifies things from "real" ASM programming, sure, but at a high level there's no abstraction in the fiction. You're writing code that operates on blocks of memory, not robots or turtles or wizards. TIS-100, by Zachtronics (the same people who made Spacechem, discussed in "Sandbox vs Directed Goals") follows a similar ideal (even as it's based on a pretty wonky artificial architecture), as do a few other web-based assembly games.
In the first half of the class, we had a homework assignment where we had to use both Scratch and Code.org: create something in Scratch for a specific other person, and then go through an Hour of Code lesson on Code.org.
Frankly, I strongly disliked both exercises.
Code.org felt like I was solving on-rails puzzles with precisely one "correct" answer, rather than giving me room to experiment and play.
Scratch gave me the frustration of and existential horror of a blank canvas. Even with the missive to make something specific for a specific person, I found myself paralyzed by inaction at the face of so many tools in Scratch's UI.
Whatever I make, I want it to live somewhere between these two axes. I'm inspired by Super Mario Maker, the level creation game for the WiiU where you create Super Mario Bros. levels. Nintendo does a fantastic job of scaffolding the player through the process of learning 2D level design. As one example, you start out with a very small set of pieces; the only way to expand your toolset is to literally come back and play every day. Once you've played for three or four days, a truck will show up in-game and deliver new pieces, adding to your toolbox at an approachable and graspable rate. And although the game is a complete sandbox in that it doesn't tell you what to make, the possibility space is bounded by the basic constraint of "you are making 2D platform levels for Mario".
Another example of something that inspires me is the game Spacechem, by Zachtronics. It's a puzzle game, roughly themed around chemistry, but there is no "one solution" to a puzzle. Not only that, but at the end of the level, you're shown statistics about how optimal (or suboptimal, as the case is more likely to be) your solution is compared to all other players. The possibility space for any given puzzle is quite large, and they find interesting ways to egg you on to keep experimenting and improve.
I'm in love with PICO-8 (http://www.lexaloffle.com/pico-8.php). PICO-8 is a "fantasy console", a fictional 8-bit microcomputer designed explicitly for modern indie game development.
The editor has you write code in a modified form of Lua, with imposed restrictions on e.g. code size. It has a built-in sprite editor and music editor, again with intentionally interesting artistic limitations on e.g. color palette, number of musical voices, etc. It's easy to share your games by swapping "cartridges", embedding your games online in a web viewer, or even just exporting animated GIFs of gameplay.
The indie game community has taken to PICO-8 like crazy. There's even a monthly(?) PICO-8 zine where people swap games.
In many ways, PICO-8 embodies everything I'm thinking about for this project. Except for one major problem: everyone I know who's using it is an established indie game developer, because it just sort of assumes you already know how to program well enough to just pick up their flavor of Lua.
What does it mean to make a version of PICO-8 that can be used by people who've never written a line of code in their life?
One large thread of my artistic practice is making interactive art and games that let people physically interact with antiquated technology, providing environments where they are intrinsically motivated to learn the history of the technology that rules the world around us.
In the past, I've made pieces about the 19th-century telegraph and an early 20th-century switchboard. Recently, I've been doing a lot of research into late 70s / early 80s computers. I'm in love with the idea of a time when turning on a computer meant being booted into a BASIC prompt, and there was little difference between being a user of a system and a creator.
I'm really interested in exploring this, although I suspect this project will end up very different from my previous work in this space. My past projects along these lines have all been using repurposed hardware; this likely won't literally be a thing built on a TRS-80 or Apple II. I'd be surprised if it literally becomes a game to teach people Z80 or 6502 assembly.
Maybe instead it captures the idea of role-play and fantasy as valuable to the learning process. If I can get you to want to role-play a character who has these skills, that's a wonderful way to get you into a growth mindset and turn you into a self-directed learner.
In the "ASM Games" node, I mention the game TIS-100. It recently had an iPad port, called TIS-100P. I was very excited to play it, but incredibly disappointed to find it used an on-screen keyboard instead of a more experimental user interface.
This led me to think about what designing a limited coding environment on a smartphone would look like. In context of TIS-100, you're writing in an assembly language that has maybe a dozen instructions. You'd likely need access to a keyboard to be able to write GOTO label names (or the equivalent), sure, but for the most part you could imagine a much more user-friendly UI where each ASM symbol is represented by a key on a keyboard or modal pane that could be tapped or dragged into a UI.
I recall spending most of my middle school math classes not paying attention. Instead, I had my TI-83+, and spent my time making games for it.
I didn't write assembly, I didn't write on my computer. I would just sit there in math class, pecking out TI-BASIC on my calculator.
In retrospect, I have no idea how I had the patience, but I do love how I was able to take such a limited toolset – mostly just text, as graphics programming in TI-BASIC was so glacially slow – and create whole worlds out of nothing. I like that idea of creating a very limited environment in which many things are possible.
My current naive intuition about where this project could go:
It's a mobile game, designed to be played in 4-5 minute spurts at a time. It's the early 80s, and you run a local software consultancy.
The core game loop is that people come to you with little pieces of software they need written, and you bang them out for them. Just little tiny BASIC programs, written in a pidgin, designed-to-be-simple BASIC language. This can serve as a slow on-boarding ramp, starting with very simple tasks and working your way up. The idea is these would be fairly quick, something you can bang out while waiting in line and want a quick distraction.
On top of that, you can write your own larger freeform pieces of software, and there's some sort of online community where you can share them. The fiction would likely be the equivalent of either Byte Magazine publishing source code, or an order-by-mail catalogue.
This is where my mind is right now, but I'm consciously not thinking too hard about it. Now that I've consciously written down all of the inspirations floating through my head, I want to give it a little more time to synthesize before I figure out next steps. I suspect some sort of user research or light prototyping might help, rather than jumping headfirst into this specific implementation idea.
Per Andrew's suggestion, I want to try to suss out what it is about PICO-8 that's so good, and what it is about its design affordances and constraints that make it so compelling.
* Hard technical constraints (lines of code, number of sprites, color palette, etc) encourage you to make lots of small things rather than one big thing you never ship. You can't spend years chasing a white whale.
* The era of gaming being evoked was one of huge amounts of experimentation, as well as one that placed emphasis on individual creators tinkering in their garages. Placing creators in that milieu helps them mentally break free of the bounds of conventional game genres, giving them freedom to experiment with modes of interaction that they might otherwise shy away from in more traditional "game design" contexts
* Having everything be in a single interface (code, graphics, audio, etc), as well as fairly simple tooling (e.g. a friendly subset of Lua as a generic "games programming language"), helps keep you in a state of flow. You don't need to switch applications, or spend forever googling docs.
* Being able to share so easily, from GIFs to a web player to exportable 'cartridges', makes it easy to feel like others can experience your work.
In my "inspiration" tree, there are a whole lot of things I'm interested in. For now, I've decided to focus mostly on two elements:
This is a modern mobile game
I want to focus in on what it means to create an experience that encourages creative learning within the context of a "time-waster" mobile game. I want to make something you can play for a minute or two while waiting in line that accomplishes something "productive", rather than pulling out Clash of Clans or Candy Crush or whatever else. This implies:
* This is meant for adults, who may or may not already be programmers. Kids might play it, sure, but that's not a chief design goal.
* People might spend hours engrossed in this, but it also needs to support a session length of 1-3 minutes.
* Programming on phones sucks. A large part of what I'm interested in is exploring how we can create mobile UIs for manipulating code that are easy to learn but also fast for advanced users. This is both one of the things that interests me most about the project, and also by far the highest-risk design challenge in terms of "this might suck up all of my time and not yield anything fruitful".
This is about teaching through role-play
I want a big design emphasis on the project to be evoking the world of early-80s hobbyist computers. I think there are two important aspects to this:
* The lack of distinction between user and programmer. Rather than the modern HCI pattern of making technology adapt to you, this is technology that required you to learn how it operates in order to engage with it. For something designed to teach you how to program, this is a valuable mental shift; I'm curious in seeing if this sort of fantasy role-playing can help people get into a growth mindset
* The hobbyist spirit of experimentation. This was a time when the "commercial software industry" didn't exist; pretty much all commercial software was built by what we'd now consider "hobbyists" making it up as they went along. This is a really convenient setting to help people feel like their work matters, that the things they are making are as interesting and important as anyone else's rather than being second-class citizens because they're "just learning"
* In a practical sense, this means that the coding interface needs to look like microcomputer code in some form. The UI needs to be touch-friendly, but the physical representation of the code itself needs to look like text in a linear file rather than e.g. a Scratch-esque visual block-based paradigm.
Before I start more seriously thinking about either the high-level structure or narrative aesthetics, I want to nail down the interaction-level design of actually writing code. This thing will live or die based on whether the core act of programming makes sense, has a good learning curve, and is enjoyable.
Currently, I'm imagining using some sort of programming language with a limited number of symbols, and a custom keyboard that exposes these symbols as the raw primitives you're operating on. You can tap a button representing a symbol to insert it into the current cursor position in the text editor, drag a symbol to a specific position in the editor, or drag existing symbols around in the editor to rearrange.
The hardest challenge with this is going to be selecting/creating a programming language with a sufficiently-small number of symbols for this to work, and come up with a sufficiently intuitive way of arranging them in the keyboard. The Android game Hacked (http://www.hackedapp.com) takes this approach, but I find it completely unapproachable due to how seemingly arbitrary the keyboard is. For the sake of space, symbols appear and disappear and reconfigure themselves at different times on the keyboard, in ways that as a new user are still completely baffling to me.
I definitely want to avoid that problem, likely through some combination of creating a more concise language (to minimize keys needed) and a more consistent keyboard layout.
Attached is a rough sketch of what I'm imagining. It's sufficiently low-fidelity, though, to hand-wave over the hard problem of actually designing such a keyboard to actually have everything you need in a comprehensible layout. For more thoughts on that, check out the "What Should This Programming Language Be?" sibling node to this one.
The next important step, I think, is figuring out what the programming language I'm using will actually look like. The things I'm optimizing for:
* Ease of understanding for new programmers. Providing expressive capabilities for advanced users would be nice, but this comes second to providing a smooth learning curve
* An environment (language constructs, std library, stylistic conventions) that slightly prioritize efficiency of symbols and syntax over readability. A limited number of symbols is important for the input method; general terseness of expression is important for a mobile form factor with limited screen space to display code
* Some sort of module system. I want users to be able to encapsulate shared behavior in their own code and share it across their projects, as well as likely eventually be able to pull in code others have written, without resorting to copy-paste
* As mentioned in the grandparent node, one design constraint is wanting the end-to-end experience to superficially resemble early microcomputer code. I think the other aspects mentioned here are more important, but worth keeping in the back of the mind
Let's look at some obvious candidates:
Presumably some pidgin form of ASM, much like used in Core Wars or TIS-100.
* Unbelievably terse on all levels
* 100% in-line with the theming
* Designing our own means we can sidestep the nastiness of actual real-world Z80 or 6502 assembly that arose out of hardware restraints
* Potentially harder to teach, relative to other programming paradigms
* Relatively little applicability to teaching general-purpose programming
* Adding in higher-level constructs for e.g. making games may be difficult
* Code reuse is generally accomplished with GOTO, which is difficult for enabling cross-program modularity
Presumably, again, our own pidgin BASIC, created by taking common BASIC structures but smoothing over the warts of real-world microcomputer implementations.
* Still relatively terse
* Easy to learn
* Has the same GOTO problem of ASM
* Difficult to bolt on higher-level ideas, might teach some bad programming practices (although I'm not sure off the top of my head what these might be, beyond the aforementioned problem of a GOTO construct)
Again, probably a bespoke Lisp designed to be simple
* There are a number of syntax-level problems I'll inevitably run into when creating a language environment (e.g. how does indentation work, do I require users to enter parens or semicolons, etc). Using s-expressions elegant solves many of these problems in one fell swoop.
* Fits into historical theming, if a little bit hand-wavey
* Encouraging a functional, rather than imperative, style early on is a really cool idea. It could also set people up nicely to "graduate" to something like SICP
* Using a language that has a concept of "functions" and such provides a solution for the modularity problem
* Not having much experience teaching programming myself, I wonder if Lisp's syntax and prefix notation might be difficult for beginners
* Most beginner programming environments I've seen tend to rely heavily on the sort of state manipulation that isn't possible in a functional environment. This may be a really good thing, but may require more care. Especially for users who are novice programmers with a little bit of programming in an imperative or OO world.
* More directly applicable to modern real-world code
* Functions and objects both solve the modularity problem
* Designing something terse will be REALLY difficult
* Teaching OO principles is a big can of worms
* If you're allowing people to create their own objects/functions/whatever constructs, how do I represent those name symbols effectively in the keyboard UI?
I suspect the real answer may be a combination of these, but more research is needed. Next steps are:
* For each of (or a subset of) these approaches, try to think out what symbols would actually be required, as well as what a solution for modular code would actually look like
* Investigate more existing "learn to code!" environments, and ideally talk to someone in LLK, about what sorts of programming paradigms are easiest to teach. A concrete question here is "is trying to teach people LISP completely crazy, or actually a phenomenal idea?"
* As this is happening, think about what a synthesis of these ideas might look like. What would BASIC with functions as first-class objects (or even functions without that) look like? Can I create a variant of LISP that has more mutable state without completely destroying the elegance of LISP?
Rather than get caught up in high-level ideas of what a language "should" be, let's take a step back and think about what core-level symbols will be needed.
I'm currently using TI-BASIC as a jumping-off point, but with the assumption that we can bolt functions on as a mechanism for modularity (a thing which apparently existed in some later versions of TI-BASIC.
* Variables (do I allow mutable state?). Strings, integers, floating-point numbers, lists. Leaving out objects probably makes sense. One option is using JS-style type coercion; another option is to be stricter about user input specifying expected types.
* I/O. In its simplest form, a way to print text, and some way to input text.
* INPUT: The simplest way to input text is a BASIC-style synchronous prompt. Eventually something more complex will be necessary, whether that's an event-driven system or letting people create loops and poll, but for the sake of an MVP starting with just input prompts seems sensible.
* OUTPUT: The simplest thing is a "print text" method. Natural progressions include being able to draw text to an arbitrary position on-screen, or being able to draw actual graphics primitives.
* Control flow. Call it if/then/else, for, and while. Again, this might change if we're living in a LISP-y functional world, but increasingly that seems like biting off too much to chew if the idea is to build a prototype quickly.
* External functions. Users should be able to define functions that they can call from elsewhere. Maybe these have to live in separate "files", maybe they can be inline. 68k TI-BASIC requires that functions be relatively pure (they can use some built-in functions that access external state, but no I/O). I don't know if that makes sense yet.
* A few built-in external functions. I don't know what these are yet, but the two that come to mind are getting a random number and getting the current time. Depending on the type system, type conversion functions may be necessary.
I think there are 4 conceptual-level questions to be answered by anything resembling a "prototype".
I still don't know what the programming language can be, but this can still be an actionable step.
My intent is to make a functional proof-of-concept keyboard along the lines described in the "2nd cousin node" (hah) that uses the Core Wars ASM instruction set. I don't know if the game will use assembly, and if it does I don't know how closely it will resemble Core Wars, but this seems like a useful shortcut to take for the sake of throwing something together.
This is a nearly-impossible thing to test without deciding concretely on a programming environment to teach.
However, I'm confident this is possible. The existence of complex puzzle games like SpaceChem and TIS-100 prove quite definitively to me that it is possible to create a staged learning environment to teach concepts in this order of magnitude of complexity.
That being said, I know from experience the way to prototype this isn't "throw something together", it's "throw something together, then spend hundreds of hours playtesting and tuning based on real user data". The way Valve tuned Portal is a good example here.
For the sake of this class, focusing on prototypes where the value comes from the building, rather than from extreme amounts of iteration, feels like the right choice. So even if I knew what language I was going to work with, this feels like a prototype best saved for outside the scope of this class.
This is very tricky to test without a decent investment in a lot of other areas of focus. I could try to come up with a very small slice to test on users – arbitrarily pick a programming language, target it at existing programmers who know that language, etc – but I think the ratio of the value gained to the cost of doing this is pretty off.
I think it makes sense to punt on this for the sake of this class.
This is something I can easily do!
My plan is to make some sort of non-game object that somehow encapsulates the game's world. Maybe it's a cover of a fake magazine a la Byte or Nibble that exists within the game's world purely to convey aesthetics, maybe it's an interactive Twine choose-your-own-adventure that tries to communicate some of the interactions you'll have with NPCs while also giving flavor of the world.
Either way, the idea will be to flesh out a little what this world feels like to inhabit.
Specific thought is going to be given to inclusivity. The early 80s, around when I'm thinking this will be set, was the period of time when numbers of female programmers dropped drastically. I want to make sure this is a thing that's appealing to a wide audience, not just history nerds like myself. My instinct is that playing into a sort of chibi 8-bit "cute" aesthetic, much along the lines of the iOS game Tiny Tower, is both a natural fit for the aesthetic I'm imagining and something that's been proven to have wide appeal.
(Attached is a screenshot of Tiny Tower)
This is a game designed for adults who play games on their smartphones, with or without programming experience.
If I draw a (completely false) spectrum between "casual gamers" who tend to only play free-to-play mobile games as time-wasters, and the sorts of gamers who look for in-depth, complex puzzle games on their phones, the ideal audience spans across this spectrum.
Demographically, the "casual gamer" group tends to skew female. Although I wouldn't say "designing for women" is a chief design goal, it's certainly important to keep in mind, since reaching this already-predominantly-female audience can also be a great way to encourage women in STEM.
The mobile ecosystem is full of games designed to be played as quick time-wasters when you're in line, etc. (In practice, they tend to be played both in this way – 2-3 minutes at a time – but also in 1+ hour gameplay sessions). My big-picture hope is to provide an experience that plays a similar role for people, but in doing so plays a more positive and productive role in their lives in two ways.
1. I do a lot of work with games that teach real-world skills. In general, these tend to be obsolete skills that are no longer in use (e.g. operating a telephone switchboard), but providing something that fits into this "casual game" slot that can actually teach people to code is really interesting to me.
2. Often, social/casual game designers talk about players in context of some of them being 'creative', and being interested in builder games such as Farmville or Clash of Clans because they enjoy being able to express themselves through the things they build. However, those games actually offer very little in the way of opportunities for meaningful personal expression. I'm really interested to see what it means to provide an environment where people playing these sorts of games can actually create their own personally meaningful games and other pieces of software.
This already happens in e.g. Minecraft, but even though Minecraft has a "mobile" version, it's philosophically not designed to be the sort of "mobile game" I'm describing.
They're learning to program.
It's unclear yet what this actually looks like. The three options are:
1. Some form of assembly. Likely something resembling Z80 or 6502 assembly, but intentionally simplified to abstract away a lot of the incidental complexity associated with programming actual vintage hardware based on these chipsets.
2. Some form of BASIC with more modern language features (probably just functions as first-class objects) bolted on. The game "else.heart.break()" would be a good example of this model.
3. Some form of LISP. If the goal is to enable the creation of games and other sorts of programs that heavily rely on the manipulation of state, this is likely the wrong choice.
The game will follow a pretty straight-forward "close-started, open-ended" approach. Much like Minecraft's Survival vs Creative modes, the game functionally has two different modes:
1. As someone running an independent software shop in the early 80s, customers will come to you with pieces of software they need you to build. Theming aside, these are essentially standalone puzzles that will take 2-3 minutes to solve, building on each other to teach new programming concepts. Starting from the beginning, these will teach you how to program.
2. An open-ended "creative mode" where you can simply make your own programs (probably with a focus on games), and a way to distribute these programs to other players of the game.
While the puzzles will be fairly linear, the hope is that they will be open-ended enough to afford multiple ways to solve them, particularly in the later stages. The hope is that the close-started linear nature of them will help new programmers get on track, but the freeform nature of both later puzzles and the "creative mode" will give people room to tinker and explore the programming environment and the tools at their disposal.
On a literal level, it looks like editing software.
In practice, a lot of this probably depends on the meta-structure. Presumably, doing the "puzzles" will yield some form of currency ("your customers paying you"), which will tie into other mechanics (building up your software empire, etc). This may also tie into distribution, and figuring out how to get your games to other players (can you spend in-game money on marketing, for example?). Part of distribution will also be being able to read and "remix" (in the Scratch sense) other people's programs.
At a high level, there are two aspects to this play. There's the literal ability to play and tinker with code in an editor, and then there's the element of fantasy make-believe in the fiction of the game. The hope is that role-playing as someone in this specific time and place will help encourage creativity and give players the freedom and the direction to express themselves (and learn in the process) in a way they might not if there was less fiction and make-believe embedded in the same mechanical structures.