#notgdc

Assets done for a game called Night on the Galactic Railways as part of the NotGDC Game Jam. A tribute to Night on the Galactic Railroad film and book design-wise.  Play it here.

Dynamic vs. Static Generation

During the week of GDC, Ben Porter started NotGDC, a non-event for game developers who couldn’t make it to GDC. His contribution was this essay about procedural generation (a topic that he knows a thing or two about).

I’m personally not sure if I like the terminology, since “dynamic” gets overused for a lot of stuff, but the distinction between just-in-time/run-time and pre-generated but still procedural content is an important one. Run-time generation gets a lot of the press, since it’s obvious to the end-user, but construction-time generation has been a quiet workhorse in a lot of production pipelines.

Indeed, a lot of new techniques start out as artist tools and only later get re-purposed for real-time use. But because players seldom see them, there’s not as much awareness of just how much of game development is really tools development.

https://medium.com/@eigenbom/dynamic-vs-static-procedural-generation-ed3e7a7a68a3#.3uirqymwh

I wrote this for Ben Porter’s fun #NotGDC “event” on Twitter. I’m taking a year off from GDC but got ALL JELLY reading THE TWETS about people saying smart things at GDC. If you’re wondering how I have any authority to talk about this subject, look no further than the Sky Rogue Steam Workshop!

Let's get this out of the way: adding mod support to your Unity game is a fucking chore.

In most games, with most engines, to modify game files you need to do the following:

Find the archive(s) containing game assets (this might not even be necessary)

Edit the assets

Replace the pre-existing archive(s), or if the game supports it, tell it to load yours instead of the main ones

This is not really possible in Unity, unfortunately. Why is that?

The tools to do this are scarce; here are ones I've found:

https://7daystodie.com/forums/showthread.php?22675-Unity-Assets-Bundle-Extractor

http://zenhax.com/viewtopic.php?t=36

The assets they extract are highly optimized assets for particular platforms, which are often not easily editable

So in the end, you need to add modding support yourself. Bizarrely, there is nothing on the asset store directly related to doing this for you. I SHOULD PROBABLY DO SOMETHING ABOUT THAT, SHOULDN’T I?

There are currently two dominant ways of adding this support to your game. Like with everything, each has pros and cons.

Roll your own asset management system (load assets directly from disk)

Pros:

It works exactly how you write it

Unless you really make a mess of it, it should be the easiest for modders to use. You might not even have to write documentation!

Cons:

You have to write it all yourself

This means asset importers: mesh importers, texture importers, sound, script, everything

You have to write your own editor, or hope your modders are okay fiddling around with text files

Modders will be restricted by the boundaries you give them. Expanding those boundaries will always require more work on your part.

Use Asset Bundles

Pros:

You don't have to write your own importers!

You don't have to write your own editor!

Cons:

Your modders have to learn how to use Unity; from personal experience many are intimidated by it

You need to either write your own "glue" code or share practically all of your code

Sometimes they just don't work and I still haven’t figured out why

I can count the number of games doing this on one hand. Google will probably not help you when you need it.

ROLLING YOUR OWN

If you want to go this path, you should start doing it the moment you start making your game.

Unity has a few tools for importing assets from disk; they don't really seem intended for this but they work just fine.

Import PNG textures with Texture2D.LoadImage (https://docs.unity3d.com/ScriptReference/Texture2D.LoadImage.html)

Import .ogg audio with WWW.audioclip (https://docs.unity3d.com/ScriptReference/WWW-audioClip.html)

Beyond that, it's not hard to find an .OBJ importer for Unity; there are several to choose from. Some are slow. Some don't seem to work with all .OBJs.

You can use JSON, XML, or YAML for "gameplay" assets; several libraries exist for C#. You will not be able to serialize anything but basic types like int, string, and lists, and might have trouble saving and loading highly nested objects.

With these you can get started with your mod support. To reduce the amount of friction between the mod assets and Unity itself, you should probably make your own parallel GameObject / Component system which will save basic transform data and hierarchies, along with the components on an object and their values. You'll need to lean heavily on C#'s reflection abilities for this. If you really want to go "whole hog", I would advise that you implement your own game assets with this system, not only to let modders make total conversions for the game, but also to constantly test the system and expand it as you need more functionality from it, simultaneously adding features for your modders.

ASSET BUNDLES

You’ll want to download the Asset Bundle Manager from the Asset Store (

https://www.assetstore.unity3d.com/en/#!/content/45836

) before you get started, unfortunately it was released before I started adding my own mod support, and is intended to be used with a newer asset bundle API which I haven’t yet upgraded to, so I can’t give any specific advice or tutorials for it.

You get a LOT of things free following this path because your modders are using Unity itself to make the mods and the bundles they export are supported by Unity out-of-the-box. I’ve found it easier for modders if you distribute your SDK as a Unity project directory and not as a .unitypackage, something that they can open in Unity and get started right away with. The extra complexity of Unity itself means you’ll need to actually write documentation, with screenshots, to make it easier for more people to mod your game.

However, you’ve got to create and distribute an “SDK” for your modders to load in Unity to create these bundles. You've got to share your scripts and potentially the source files of other game assets. I would like to point out that this is probably not as bad as it sounds; I doubt anyone would clone your entire game and sell it but I also don't want to be proven wrong. You can build all of your scripts into a .DLL, but without extra obfuscation, a decompiled C# .DLL is practically the same as the source code, without comments and whitespace.

There's a middle ground, but it makes your support a bit more complicated: Write a bunch of "empty" versions of your game scripts, just the ones which modders need to use to create their assets. By "empty" I mean they lack all of the functions and just have the public variables which get serialized by Unity and appear in the inspector. You'll need to write some glue code to convert the "empty" versions of components into real ones when you load in the bundles; use C#’s reflection to read from one component and write to the other.

If you want to support users writing their own C# scripts, you’ll need to do a little extra work, but thankfully Unity has documented that:

https://docs.unity3d.com/Manual/scriptsinassetbundles.html

However, to actually let modders do things that operate with the scripts built into your game, you’ll need to either include those scripts in your SDK or create an API to do that; no small feat. I don’t have any personal experience doing this yet, but Cities: Skylines has such an API and you may be able to figure out what they’re doing by taking a look at their documentation:

http://www.skylineswiki.com/Modding_API

This is still a topic I’m actively developing things for, and I’ve been talking to other devs the whole time so this isn’t comprehensive at all, but I hope it gives you a good starting point. As a bonus, here’s some reasons why you might want to add modding support at all:

Mods add a lot of value to your game. If you have a heavily system-driven, simulationist, or sandbox game, mods practically create several sub-games for you. I bought the original Half-Life specifically so I could play the Counter-Strike mod (before it was a standalone game); this could become true for your game as well.

Mods grow your community. It gives players a path for becoming heavily invested in the game and add a little bit of themselves to the game. More investment means they talk about the game more, then people get invested in the mods themselves and talk about those. People talking about your game is what makes up your community.

Mods let you add licensed content to your game, by proxy, and not get sued. The Arwing from Star Fox looks pretty fitting in Sky Rogue. So does the Swordfish II from Cowboy Bebop. I couldn’t add either of these myself to the base game, and I’m really glad other people have. It sounds trite, but I’ve heard of players specifically buying the game because of these particular mods.

You can just dip your toe in and make some minor commitments for gains which can mean a lot: Guacamelee lets you customize the player avatar but nothing else.  The Long Dark crowdsources its localization by implementing each language as a community-created mod.

One of the most important ways to get information into our shaders are textures. Textures are read via "texture samplers", they allow us to read from textures super fast and deal with stuff like filters and mipmaps for us.

To start implementing textures into your shader it’s beneficial that you know how to use properties in shaders, you can find a tutorial for that here: https://ronja-tutorials.tumblr.com/post/172170158512/properties

When we write shaders, we usually want to be able to change parameters on a per material basis. Properties allow us to do that in unity. In this simple example we’re just going to make color of our unlit shader adjustable.

For this tutorial you should know how to make a super basic unlit shader, you can find a tutorial for that here: https://ronja-tutorials.tumblr.com/post/172104877882/basic-unity-shader

Here I’m gonna explain what you have to do to make a unity shader show anything. You’ll end up with a object with a single color, but we can add onto that later. If you find you have troubles understanding everything, I recommend you read the tutorial on hlsl language basics: https://ronja-tutorials.tumblr.com/post/172421924392/surface-shader-basics

The interresting parts of Unity shaders are written in HLSL, Microsoft’s High-Level Shading Language. In this post I will explain the basics of HLSL we'll need to program shaders. If you already know how to program in other languages, a lot of this will seem familiar to you.

This post will explain some basics, you don't have to understand everything here, the following posts will explain how to apply those basics so if you feel like this is too boring/abstract feel free to look at the other tutorials and come back when you know what this is for and you need a refresher.

To understand this you don't need any previous knowledge, that means if anything is unclear, please message me so I can clear things up and the post is easier to understand in the future.

.

by Rowan Crawford // @Sumaleth // for #notGDC 2018

I began making Cerebrate, a puzzle game based around an electronic circuit simulator, at the beginning of 2010. I had sold my half of an internet software company about a year earlier and so had the funding for what I thought was enough money to make several small iOS games, and to finally, finally, get myself a career in videogame development (after trying on and off since the late 1980s).

I ended development  on Cerebrate in mid 2015, with the game 'largely' complete but in a non-playable state and with a lot of work still left to do. Money had run out and it was time to change tack.

The teaser website for Cerebrate is still up, for the curious: http://cerebrategame.com/

That tack change should have come at least 2 years earlier, it's clear to see with hindsight, so there's the first thing on this list of things I learned while making and not making Cerebrate; I waited until it was much too late to change course. Why? For two reasons; I didn't know what to change to, and at no point during the development of Cerebrate did it ever seem like it was more than 4-6 months away from completion.

I was constantly asked, over those years of development, when it would be released and I'd always say "another four months". And I'd always mean it. I didn't have the experience to make a sensible estimate so I think this value comes from a place of "well, it couldn't seriously take more than four months could it?". It was only towards the end of those five and a half years that actual, reliable gut estimates started to creep in and a voice deep within would scream back;

    "THERE'S AT LEAST A YEAR OF WORK REMAINING"

(Whoa, so that's 200 words already? I guess I can probably need another 200 more words so let's cram this out...)

contextless decision-making

I didn't start Cerebrate from a blank slate; I had coded a complete game for the Commodore 64 in the early 90s (in assembler) and had worked on a handful of shareware games, mods, and game levels in the years since. I had also been working with PHP and CGI/Perl for my software work in the lead-up to this switch to game development, so, yeah, I wouldn't have called myself a programmer but I thought I knew "programming".

But something I learned was that game development had changed, oh had it changed...

I learned about Xcode and the Objective-C programming language before starting development on the game by watching videos and reading tutorials and books. I had wanted to make the game in C++, because that's what games seem to be programmed in these days, but iOS games used Objective-C so that's what I learned.

I think it was sometime after the first year that I read something about pure C "structs" and began to migrate towards a more C-orietated programming style, learning C along the way -- and if you're reading this thinking wait, you learned Objective-C before C? then yes, therein lies one of the biggest lessons learned; you don't know what you should be learning until after you've discovered it, at which point you always wish you'd learned it earlier.

Cerebrate's code base, as it sits today, awkwardly straddles a fence between C and Objective-C in a manner that, I suspect, would make any serious programmer angry.

Cerebrate uses my own game engine, and learning how game engines work is something else I learned in an ad hoc manner. I could probably write a decent engine now but Cerebrate does not have a decent engine. It's efficient at runtime, but a chore to use, which makes it slow to use, which makes it inefficient at development time. I need to rewrite it in C++, un-ironically.

And if you are one of the 98% of readers wondering why I didn't use Unity right from the start then let me answer that right now; Unity3D was new at the time that I had to decide, and I wasn't convinced that I was going to give me the control I thought I needed. Had I known what it was going to become, however...

There were other game engine systems available but I didn't know enough about engines, or programming, or anything really, to make a meaningful judgement. I can look at them now and say of course they were better than anything I could produce in anything less than some number of years so of course I should have picked one -- any one -- and just started making a game with it. But, as I was very aware at the time, I was in the position of needing to make a big, important decision without any context or information upon which to make that decision, so I chose the option that I thought would give me the most control and, ultimately, teach me the most.

I had absolutely zero context for any of the early decisions; can I make this game on a Mac Mini or did I need something bigger? How much memory do I need for the system? Is the game idea I have suitable for an iPhone? Is the game idea I have small enough as a first project?

(Retrospective answers: no; all of it; no; oh hell no! *laughter*)

Okay, 800 words already. Time to start wrapping this up; final 200 words!

duke nukem forever syndrome

I learned OpenGL ES 1.1 to develop the game engine at the beginning of the project but as time moved on, new iOS devices were released, and the device technology advanced I had the opportunity to rewrite the engine using OpenGL ES 2.0. This also meant learning GLSL and shader languages in general.

I learned, immediately after getting glsl to render the game successfully, how to make Doom3-style shadows work using OpenGL ES 2.0 and glsl. Well, "immediately" is generous; it took the best part of a month to understand and implement, in the absence of even a vague understanding of how to debug an OpenGL application on iOS, the shadowing system that had been worked out by John Carmack.

And then, once these shadow were all finished and working, I learned that it wasn't really the look I was after so I deleted it and added textures to fake shadowing under everything. I learned about prioritisation right around then.

I repeatedly talked about Duke Nukem Forever when discussing Cerebrate with people at that time, as you might imagine, aware that I was having the same problem that plagued game's (then unreleased) development; technology was outpacing the development speed of both our games.

I've talked about the lack of context being a problem when making decisions on this project but DNF was all of the context I could have hoped for and yet I always made the same decision they made. I felt like I needed to keep rebooting the project or risk being a 2010 project released in 2011, or a 2011 project released in 2012, ad infinitum. None of which sounds awful until you compare the hardware specs and games from those two years, and my whole business model, if I'm allowed to call it that (SIT DOWN LIAM!), was based on the intension to stand out.

The appeal of iOS development, to me, had been that we now had this small hardware ecosystem that we could self-publish in and reach a large, keen audience. But by the time I bookmarked development on Cerebrate at least 13 additional iOS devices had been released, each with progressively better and different hardware, countless iOS operating system updates (and each one of those bastards broke my game), and hundreds of games were now being released on the app store each day. The appeal and confidence was gone.

I learned that I should have made the game for PC desktop from the beginning.

what's the hotkey for learning?

Software, so much software.

It began with Xcode, which was at once eye opening and bewildering. This was not like programming for the Commodore 64!

There was so much to love about Xcode but also so much to hate. I learned that the tutorials, at least from those early times, for making iOS games never told the whole story. Or at least, not enough of the story for someone trying to make a serious game. As an example; I was using Xcode for something approaching 18 months before I learned that I could step through the code while the game was paused. This blew my freaking mind once that realisation came into focus. You don't know what you don't know, and you don't know that there are things that you should be using until after you've accidentally stumbled upon them 18 months later.

I still don't use source control. I never heard of this until towards the end of Cerebrate's development so I naturally developed my own solution. (Maybe debugging and source control should be used in the first tutorial of every programming system anyone ever writes? Just a thought.)

Blender, Inkscape, Gimp, Photoshop, Instruments, GlyphDesigner, TexturePacker were all picked up and learned in some scattered series of steps over the years. I learned, soon after purchasing Photoshop, that I really should have purchased Illustrator instead, and also that I should have waited a little longer for the release of CC because the Photoshop I purchased for more than $1k was never to be updated with new features again.

I never did get my head around code signing for iOS apps so that's one thing I can't say that I learned. I got something of the silhouette of a gist, let's say.

Okay, last 200 words, here we go.

okay, here’s the elephant

I learned about fibromyalgia. Technically speaking, I didn't learn what it is because that is still not known, nor what causes it because that's not know yet either, but I learned what it feels like and what effect it has on your life. I don't recommend it.

Fibromyalgia effects your body's ability to regulate nerve signals, so every nerve signal is potentially processed as a pain signal.

I felt the first symptoms around when I was about to sell my interests in the internet software company that I had started, when I was trying to put a full stop under Internet Software Developer and transition to Game Developer. It was almost a full year before I could use a computer seriously again. That was how long it took to hear that I had fibromyalgia and that what I'd been feeling for the past year was probably never going to go away.

I learned a lot about the medical profession; some of it positive but my main takeaway from that time is that most doctors are like tech support workers new to their job, bluffing and stalling their way through each appointment, referring you to someone else who is in exactly the same position as them self. The amount of time and money I wasted during that year feels criminal, though I need to keep in mind that fibromyalgia was, at the time, a relatively new condition in the medial journals and it still can't be tested for; it's a diagnosis of subtraction. Rule out everything else, shrug your shoulders, and call it fibromyalgia.

With that medical preface out of the way I'll use my last 200 words to talk about what I learned about trying to be a game developer with a disability, and the one unexpected up side.

To get work done with fibromyalgia means learning a routine; you work for 20 minutes then you rest for 10 minutes, then you work for 20 minutes and you rest for 10 minutes. You do this for as much of the day as you can, sleep, and start afresh the next day.

You learn to deal with the side effects of medication. You learn that everything you do that isn't working starts to feel like a waste of your time.

You should also learn to take all of these restrictions into account when estimating production time requirements, but I don't think I ever did. I think I still estimate time based on my old routine of 10 hour work days. That's another thing that I never managed to learn.

So, production...

...slows...

...do...

...wn.

what to do in one's down time

And you find yourself waiting a lot. I discovered early on that I could no longer read physical books  so I started watching films. I ticked a lot off from that '1001 Films You Must See' list, all cut up into 10 minute segments which is an odd way to watch films I have to say, before realising I was wasting this down time. I began to use that time to learn as much as I could.

And this has been the one upside of fibromyalgia that I mentioned. I had an opportunity to learn a lot about a lot of things. Lot.

Game design and programming were the first topics on the plate. I watched hundreds of hours of computer science lectures, game design talks, read every web page I could find. I bookmarked everything, rated it all, and kept notes in small spiral bound notepads. I then transferred the notes to organised, categorised, referenced text files so that I would never need to remember anything that I'd learned; I could just look it up!

I eventually stopped transferring the raw notes to the text files, and then stopped the note-taking altogether. Both were immensely time consuming and certainly contributed to Cerebrate's slow development pace. Though it would be impossible to overstate how much I learned during this period.

I learned about games, and even whole genres, I had never played -- genres I'd never even heard of; I learned of the history of videogame development and the early pioneers; rendering and engine programming techniques; game design and programming philosophies; and terminology used by people working in these fields (from kishōtenketsu to hygge). I read more articles about whether videogames are "art" than anyone should ever read (which is to say; > 0).

A few areas of design were particularly interesting to me as my knowledge grew, such as the relationship between the player and the player's character; moral and ethical game design; interconnected gameplay and narrative (ludonarrative sonance?); and ideal ways to tell narrative in videogames. I could have written a #notGDC piece about any of these topics, though of course I'd have needed more than 200 words so they're not really suitable for this format.

As time went on my interests reached out into to other fields. I read and watched a lot about science (light is my favourite topic), philosophy, colour theory, animation, and typography. (Remember when I said I  can no longer read physical books? And yet; I still buy books about typography -- there are at least half a dozen scattered around my floor at this very moment. I don't know why, either.)

On the programming  side I fell deep into such delightful topics as physics, proceduralism, simulation, tools development, security, AI, and UI/UX.

Cerebrate, and my earlier internet software, are essentially tools and part of my work history is in UI/UX, so these two items from that list were natural progressions of existing- and Cerebrate-related needs. The dive into AI, too, was brought on by Cerebrate when an attempt to add an AI creature proved frustratingly difficult. I never did go back and attempt that AI challenge again, with new knowledge in tow, but the knowledge is there now and one day I return and I will defeat it!

simulation, math, and all that good stuff

Cerebrate, as mentioned, is a puzzle game based on an electronic circuit simulator and so to make Cerebrate I first learned how to write a mixed-mode, non-failing, real-time circuit simulator. That sentence, I suspect, doesn't quite encapsulate the amount of stuff I had to learn to write this simulator so I'll break it down.

Circuit simulation, it turns out, is a lot like physics simulation except that while physics simulation was essentially a solved problem for game designers (you can mentally add as many asterisk as you need to make the use of "solved" in that sentence credible for you), even at the time I started Cerebrate, I wasn't able to find any existing circuit-simulation libraries that let me do what I needed for a game.

Now, I had done two years of Electrical Engineering at university some 20 years earlier, so I wasn's tarting from -273 degrees here, but I remembered very little of it. I needed to re-learn all of the math, then push on past what I had learned in my time at university to understand what all of the papers and books about circuit simulation were talking about.

It made absolutely no sense to me at first, but over time I started to grasp the process. I wrote the first simulator in PHP (which I later found to be producing incorrect results, but the process was on the right track and that is what I needed at this stage).

I learned about Graph Theory by rediscovering it myself. I had seen it in the books and papers but didn't know how it related to what I was doing so I never pursued it. But in the process of writing algorithms that processed the circuits -- for tasks like selection and simplification -- I'm sure that I re-discovered small corners of Graph Theory; things that a mathematics student would probably learn in the first week of the topic at university or college.

I learned that re-inventing the wheel is easy to accidentally do when you don't know that what you're doing is already a thing and that it has a name that you could google if you knew that it had a name and what that name was. Reinventing the wheel may be what I spent most of my programming time on Cerebrate doing.

game design redux

Early after I had a working circuit simulator, and had added a rudimentary UI, I learned something that could quite easily have killed the project there and then; electronic circuits don't lend themselves to puzzle design. You'd think they would, but they just don't.

Electricity, I learned, is not at all like physics; it's behaviour and movement is not intuitive. A loop of a battery, some wires, and a switch (and some resistance for the pedants) is intuitive, but once you add anything more complicated (and interesting) it begins to feels like you're wrestling with water.

Yet, I still felt that there was still something interesting to explore there, regardless, so I continued to work on the game.

It wasn't until a talk by Jonathan Blow and Marc ten Bosch titled Designing to Reveal the Nature of the Universe (Indiecade, 2011) that I saw an angle for the game; a way to make it a puzzle game even though the scope for puzzles was limited. I learned that not every level needs to be a challenge, for example; it need only reveal something interesting about the nature of the game's world to be worthwhile. A progression can be developed from that framework, and that was perfect for Cerebrate. I had direction again.

I learned that game design philosophy ideas can, in some sense, be dangerous. It was a blog post of Jonathan Blow, again, that lead me to a brief talk by Chris Hecker titled Please Finish Your Game (GDC, 2010).

If you're familiar with Blow's work then you'll know this idea which, put simply, is to explore your game's mechanics completely. Don't leave anything unused. Don't add some idea for a couple of levels and then never return to it again; explore the idea to the complete breadth, width, and depth of what it can do and use everything that is worth using; everything that is interesting.

This was an idea that took deep root in me and pretty soon my fun, quick little puzzle game idea had 60+ levels, two modes of circuit simulation, narrative and sandbox game modes, and a game design that began with the player pressing a red button and ended with them fixing -- without instruction -- the core of a CPU.

Where "pretty soon" really means "over the course of several years". This single idea drove me to make the game as apposed to just a game.

Speaking of pushing back completion, I probably just need another 200 words so let's DO THIS!

might be more than 200 words

I deliberately, knowingly avoided any thoughts of production techniques, marketing, PR, and really any thoughts of business in general for the longest time. I didn't want to need to know those things. I had game ideas, I had a todo list, and I thought that if I just kept working through that list that I would finish a game. And I thought that if I made an interesting, polished game that it would at least make money back that I could make another game, even if something smaller, and if not enough for another game then it would be one hell of a great line item for my CV.

But at some point I had come to learn that I couldn't develop the game faster than the hardware and the market moved. I saw that the market was very different than the one I had conceived of the game in, that it had become a risky proposition; or at least that I no longer had any grounding upon which to base confidence. It had become a gamble; I was gambling.

I was reading articles that taught, without equivocation, that success now relied on things like a social presence, online and off, neither of which I had. Production was already slow and I didn't want to divide my time with other tasks. I certainly didn't want to start promoting the game.

But everything I read and watched gave the same advice and so I relented, by attempting to acquire a booth at PAX.

My application was rejected, so cosplayed at PAX that year as a Mobile PAX Booth to promote my game and start playtesting it.

I learned, or rediscovered I should say, that social events are my weak point; my Achilles heel; my kryptonite; the aspect of my persona that I placed no levelling points into. Social interaction is the one thing that I absolutely, assuredly cannot learn.

But, turning back to PAX, I learned enough from that weird little adventure to say that there was still a lot of work left to do on Cerebrate and that I was very lucky to not be confirmed for a PAX booth (to whomever rejected my request, I owe you a box of Cadbury Favourites!).

I learned, around that same time, that IGDA Melbourne was a thing and so I joined and went to a couple of their social events. I also started tweeting, started "following" people, started meeting people. I learned that Melbourne's game development scene is vast and vibrant, and that the are groups of people working on all the many and varied types of game within this single city. All of it interesting and inspiring, and I wish I had time to participate proactively in all of it.

remember all those things I'd ignored?

I joined a weekly meet-up called Get That Game Done, created by Liam Esler (Baldur's Gate: Siege of Dragonspear, Icewind Dale: Enhanced Edition, GDAA, etc) whom anyone who has read this far will likely know. Over the next year and a half I learned from these meetings as much as I could about production, marketing, PR, and business in general.

Liam was incredibly generous with his time and knowledge, as too were occasional special guests Lauren Clinnick and Katie Gall (Lumi Consulting) who brought with them all the knowledges of things marketing and PR, and game designer Alexander Bruce (Antichamber) who always came in with such an intense level of game business craft that it made the rest of us look like we were screwing around with Lego.

I learned things in that environment, and reinforced it by reading and watching anything I could find on the internets. And while I wouldn't say that I ever gained a love of these roles, they are now as much a part of my thinking as anything else I do.

the other side of the road

It was Crossy Road that finally showed me a way out of the hole I had dug. Too late, as it happened, but this was the game that taught everyone, I think, that the F2P business model wasn't as rigid and necessarily-bullshit as everyone thought. There was room to experiment with it, room to have a bit of fun with it.

I had watched the F2P business model take over the mobile gaming market but I wasn't ever even a little bit interested in making those sorts of games, or of modifying the games I wanted to make in such a way that they'd work within a F2P framework -- I had clung on to premium games success stories, like Monument Valley and Metamorphabet, thinking that if I could just get those last 4 months of work completed...

Crossy Road got me thinking freely again. I dug out the old game-ideas list, looked for anything small and F2P'able, and started to learn Unity.

Which meant learning another programming language, C#, and a new IDE, Unity; but it was ridiculously fun to dive into something new again as it always is. I rushed out a couple of prototypes, showed them around in the vague hope that I might be able to find funding (lesson learned: nope, don't be silly), and tried to find freelance work in game development.

That was two and a half years ago and that was the last time I touched Cerebrate. It sits there, dormant, waiting for me to tap it on its shoulder and whisper, it's time. But that moment, when I can unthaw Cerebrate and start redeveloping it as a PC game, is not going to be any time soon.

I learned, in that flustered rush at the end of Cerebrate, that even with five and a half years of UI design and implementation, high-level algorithm programming, puzzle design, narrative design, shader programming, and art design directly behind me, without even including everything else I've done in my professional career (animator, screenwriter, caricature artist, technical writer, website designer, modder, journalist, etc) it's worth all of exactly nothing if you don't maintain an up-to-date portfolio of your work to, you know, prove that you can do those things! And I didn't!

Even that partially-complete Cerebrate should have been a portfolio itself, in some sense, but my transition away from it had been so sudden, so frenzied, and followed almost immediately by the spending of my very last saved-up dollar, that I hadn't had a chance to prepare Cerebrate for the task.

So I'm back working on internet software again, making use of what I learned about the role of production from Get That Game Done, in an odd sort of coincidence, building up the bank balance once again for the next stab at that game development career.

I have a collection of small game ideas waiting to go, I'm keeping in-practice with Unity, and I have a level of business acumen that can now be measured as at least some. I have learned enough that this next time I will do it right.

etc

I'm going to have to cut this article short right here, I'm sorry to say. It would have been nice to finish it, to talk about all of the other things I learned while making and not making Cerebrate, and I think with another 200 words I'd probably be able to finish it proper, but I've run out of time.

If you read this far then I hope you learned something.