Everything I Learned Making and Not Making Cerebrate (in 200 Words Or Less)
.
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.
Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā -==-