What people believe you need to do to be an independent game developer

Aspiring game developers are starving for advice. I recently attended a meetup of game developers where an individual gave a formal presentation about how to become an indie. The presentation was thoughtfully crafted and well delivered, and it was entirely structured around imperatives
—the things that you, the audience member, need to do if you want to be a successful independent game developer. The audience ate it up and asked for more. They were looking for the golden key that would unlock paradise.

There are two problems here, one overt and one subtle. The overt one is that there is no golden key. There is no set of practices that, if followed, will yield success. I imagine most of the audience knew this and were sifting for gold flakes. However, it was also clearly a mixed crowd, some weathered from years of experience and some fresh-faced hopefuls. I hope the latter were not misled.

The subtler problem was made manifest during the question and answer period when it became clear that the speaker was not actually a successful indie game developer at all. Their singular title had been in development for three years and had just entered beta. They had no actual experience from which to determine if the advice was reasonable or not. The speaker seemed to wholeheartedly believe the advice they were giving despite not being in a position to draw conclusions about their efficacy.

Once I saw the thrust of the presentation, I started taking notes about the kinds of advice the speaker was sharing. 

•  Document everything, and specifically create:
• Story and themes document
• Art and design document
• MDA document
• Have a strong creative vision
• Be a role model for the work environment you want
• Consider these pro tips for hiring staff:
• Use a report card to score your candidates
• Look for ways to get to know what it would be like to work with them
• Try collaborating with them as part of the interview
• Always have a back-up candidate, not a top candidate but someone you know you could work with
• Being their best friend does not mean you should work with them
• Thank people for their contributions and efforts
• Use custom tools to help you work better
• Use the Asset Store in Unity
• Use tools to help you test
• Automate as much as you can to save you time
• Learn to prompt so you can use generative AI
• It allows an artist to be a developer by removing coding barriers
• LLMs can replace tedious use of YouTube, Google, Reddit, etc.
• When pitching to publishers, have two versions of your slide deck:
• pitch slides: the version you send
• pitch presentation: the version you present
• Take budgeting seriously
• Budget for specific deadlines
• Don't spend your own money if you can get money from someone else (e.g. publisher)
• Get a job so that you can support yourself until you can get funding from someone else for the game project
• Quoting one of his professors: "To make money, you need to spend money, and to spend money, you need money."
• Don't get distracted by others (e.g. on social media)

These aren't the things you need to do to be an indie game developer. These are the things that an audience believed you need to do to be an indie game developer or the things that someone with a modicum of experience thought would be worth telling indie hopefuls. It seems to me that this is the advice you would get if you spent an afternoon collecting advice by searching the Internet. It's helpful for me to have a list of what people are likely to believe from consuming popular advice. Sometimes advice is popular because it is accurate; sometimes people tell you to make your game state global.

Three other things jumped out at me about the presentation. First was the unspoken assumption that one would be using Unity. There was no indication from the speaker that this was even a choice, and none of the questions reflected on it. Second, the speaker acknowledged the importance of automation and automated testing, which was great to see. Third, no one pushed back regarding the use of CoPilot or other LLMs to help with coding, whereas I suspect there would have been a riot had he suggested using the same tech to generate artwork. There's a study in there.

Serendipity

As mentioned in yesterday's post, I was at Meaningful Play 2024 a few weeks ago, and I'm finally processing the many pages of notes that I took there. 

Sabrina Culyba gave the morning keynote on that last day of the conference. She spoke about serendipity in game design, sharing a compelling story about the development of Diatoms. The talk was brilliantly prepared and executed. She summarized research findings around serendipity that shows that the following factors can affect its likelihood:

• Having a prepared mind
• Openness
• Being connection-prone
• Belief in serendipity

These are really interesting, and if I didn't have a pile of other research projects in the hopper, I'd be curious to dive into the literature here. The first item sounds like a variation on the maxim, "Luck favors the prepared." The second sounds to me like the eponymous Big Five personality trait that tracks with creativity.

I don't have much else to contribute to the discussion, but it's a neat idea that I don't want to waste away in my notebook.

Fantasy heartbreakers

 I am currently reading William White's Tabletop RPG Design in Theory and Practice at the Forge: 2001-2012 after having met the author at MeaningfulPlay. This excerpt from Chapter 3 made me shout with delight at having a name for a phenomenon.

A fantasy heartbreaker was [Ron Edwards'] term for an independent game that contained interesting innovations, usually without realizing that they were in fact innovative, but whose designers had failed to fully examine their underlying design assumptions—thus producing games that were highly derivative of D&D, whether or not that was actually a design goal of the game—and who were either naïve or overambitious in their expectations for success in the marketplace. (p.93)

Ron Edwards' original post on the topic is cited, but I haven't made the time to read the source yet. White's summary was enough to excite me and want to share it here.

Paper!

I have a pile of things to grade, seemingly unlimited committee work to complete, and major decisions to make. I am having a bit of a stressful week. But you know what I just did that made me so happy that it's worth taking the time to write a blog post?

I graded something on paper.

My new coworker Travis Faas shared with me a format he uses for peer critiques during his game programming class. It's something I want to draw into that class. Today, in CS222 Advanced Programming, my students were to showcase their two-week project submissions. I've traditionally done this in an unstructured way, something like an academic poster session. Just a few minutes before class, I thought to myself, "What if I tried out that crit format here?" I literally did not have time to lay out even the simplest of templates, so I just grabbed a stack of blank white paper and headed downstairs to class.

I told the students that, during their showcase, they had to write at least three outcomes from their discussions. I suggested (following Travis) that these could take the form, "I learned X," or, "Y is something I want to learn more about." I also foreshadowed that there would be a secret final step.

As always, they walked around with real interest in what each other had done. This time, however, they paused after each station and jotted little notes on their paper. What might otherwise be fleeting thoughts were tracked, held on to.

Once we were done—and gave out the Audience Choice award, of course—I gave them the final step: to write down some action that they plan to take next that relates to the outcomes of their discussion. I gave them two or three minutes to do this before collecting their papers.

Both of my Tuesday/Thursday classes had major deadlines today, so it was quiet during office hours. I sat down in my chair, grabbed my favorite pen, picked up the stack of papers, and read through them. On each, I gave a little, hand-written affirmation, encouraging students or providing tips on how they might move toward their goals.

Paper! Wonderful paper!

I am looking forward to turning back their papers on Thursday. I wonder when the last time was for them that they had such a human experience as handing a teacher their ideas and then waiting, waiting without a chance of hearing from me about them before our next meeting. No anxiety about checking grades. No notifications. Quiet, from which comes a chance for peace. 

Paper!

Grading rather than improving

I talked too much today. I had back-to-back 75-minute class meetings, first of CS222 Advanced Programming and then of CS315 Game Programming. Both times, I spoke almost the whole time. I would much rather have had structured exercises to help teach what I wanted to show. It wouldn't have been that hard to set them up, just an hour or two each of setting up a template project that demonstrates what I want to show. I don't have an hour or two for each meeting for each class. I have filled my allocated class time with grading. This is partially due to the new grading system I am using. I'm having a lot of back-and-forth with my students. Turns out that getting them to mastery is a lot harder than giving them partial credit. I believe it's bearing fruit. But it's also taking all or more of the time I can give to a class. 

I am not sure what the path forward is. I will do less grading later as both classes move from individual lessons to large project integrations. Then, however, it's too late: we will have passed the point in the semester where a strong introduction is better than 75 minutes of my talking.

CS222 and CC17

It has been many years since I have required my CS222 Advanced Programming students to read chapter 17 of Robert Martin's Clean Code. This chapter is entitled "Smells and Heuristics," and it contains a wonderful collection of common code problems and potential solutions. This year, I had my students read the chapter just before starting our two-week project, and I gave them the challenge to pick three items from the reading that were particularly interesting to them. These were fun for me to read, displayed thoughtful reflection on programming, and to top it all off, were easy to grade.

Some of my favorites showed up in the students' responses, such as the advice to extract conditionals into named functions, to replace magic numbers with named constants, and to avoid selector arguments. Feature envy showed up more than once, which surprised me. Students recognized that some of their previous courses actually habituated them to these smells rather than their cleaner alternatives.

I need to remember to keep this assignment. I plan to ask my students today whether they think this chapter would have made a good introduction to our reading rather than a capstone on it. Because the chapter is so accessible, it's possible that reading it first might help them get better faster, and to do so before they get into the trickier distinctions such as SRP (Chapter 10) and the distinction between objects and data structures (Chapter 6).

Docs is code

Clint Hocking's birthday blog post led me to look at the EXP tabletop roleplaying game, and in turn, that got me looking at AsciiDoc and the Docs as Code movement. I understand completely the arguments that AsciiDoc makes against Markdown. Regular readers will recall that I experimented with converting my course plans to GitHub-hosted Markdown and almost immediately backed away from it: Markdown almost immediately requires a polyglot approach for anything significant. However, I don't see AsciiDoc nor Docs as Code as addressing what I consider the most important tool for technical writing: the ability to embed scripts.

I have been using lit-html for years (and Polymer before that). What it lets me do is separate the structure of my writing from its display. For example, when I write an assignment for my students, I might conceive of it as having a list of objectives. In Markdown, AsciiDoc, or even HTML, I could easily represent that information as an ordered or unordered list. Later, however, I might decide to change the representation, instead showing it as a definition list, or making sure the name of the objective is bold, or generating unique links to each individual objective. In any of those plain markup environments, I have to do this by hand or, worse, with a regular expression.

What I don't see from Docs as Code, although I admit I haven't done more than a cursory search through their materials, is the observation that docs is code. If I separate my model and my view, I gain a robustness that any journeyman programmer understands. For example, using lit-html, I can create a simple JavaScript data structure that represents a goal, with a name and a description. Either or both of these can be html templates, not just strings. With that structure defined, I can create a list of them for an assignment. Now, on my first pass, I show them as list by iterating through the list and dropping the data into list items in an ordered list. When my requirements change—as they always do—I can modify my script and make the same data into a definition list, section headings, etc. If I need to change the actual definition of an assignment goal, I can make that change explicit.

Of course, the whole thing is in version control with sensible commit messages.

I have taken a similar approach in the past to build documents using LaTeX, coordinating the execution of multiple scripts through GNU Make. That works when LaTeX is needed for document output, but it feels less elegant to me than being able to generate the HTML directly from the Javascript.

If you know of an approach in the AsciiDocs or Markdown vein that gives the same level of robustness as what I can do with lit-html, please let me know.