One thing I’ve discovered about myself is that I’m a sucker for timed competitions.
Over the years, I have tried my hand at a strangely-large variety of these things: Writing a 50,000 word novel in under a month in the National Novel Writing Month competition (NaNoWriMo), creating movies with friends from scratch over the weekend in the 48 Hour Film Project yearly competitions, entering several game jams on Itch.io, and participating with coworkers in multiple 2-day “hackathon” events held at my workplace.
At a few of these competitions I or my team won or did well, but most were lost. In every case though, a good time was had in the doing of them. What was the appeal here? Several things. Limited time means limited commitment, and it’s easier to really devote yourself to something completely, if you know there is a finite end to it.
When we were active in the 48 Hour Film competition world for instance, I would have no trouble getting anywhere from 15 to 30 people involved helping out, for free. It was not that hard, because it started on a Friday night and was over by Sunday night, so no matter what, you knew you would not have to be involved for that long if you decided to be part of it.
Not many of those 7-minute-or-less movies made in 48 hours were really any good. Ours mostly stunk (linked one above is no exception) but the time constraint is also a great leveler. It put our team, which consisted mostly of engineers who had no real experience with movie making, closer to par with teams containing film students, video professionals, and others who had better equipment.
A common theme across all these timed things is, reduced expectations. If you are asked to write an entire novel in a month, people know it isn’t really going to be a master-work. Same is true for a game made from scratch in a few weeks, or a movie made over a weekend.
The unreasonableness of the situation has the effect of setting one at ease; knowing that what is being asked of you is in its essence unrealistic, and that any honest-effort approximation of a good result can be considered a win.
Finally and very significantly, there is the strange alchemy that happens when you are trying to get something done, but have to overcome some fundamental limit or obstacle. Limitations force you to be creative. To find a different way around a problem, which can lead you in new, unplanned, and interesting directions.
For the contests I mentioned above, this ‘obstacle’ was limited time. Spending 35 years as an engineer probably has something to do with why a time-constrained competition is a comfortable limitation for me; working under time constraints, and sometimes unreasonable time constraints, is familiar and part of the job.
But beyond time constraints, there are other situations where limitations help the creative process - or conversely, the lack of limitations makes the creative process harder.
Everyone has probably heard the old adages about there being “nothing scarier than a blank page / blank canvas”. Starting something new often triggers choice paralysis, a condition where having too many options at your disposal demotivates or inhibits you from making progress. But really, choice paralysis can occur at any stage of a project, where there is no clear direction you are constrained to follow.
Just Give Me a Smaller Machine
My own personal experience with the “choice paralysis” phenomenon goes like this:
When I went to college in 1982, I brought along my prized possession, a Commodore Vic-20 Computer I had bought using money I made in my summer job. I was one of two people in my floor with a computer of my own, but it was just not a powerful enough machine to be useful for any kind of school work. It was thus mostly relegated to playing games, and for my own hobby hacking and BASIC programming.
The stock VIC-20 only had 3K of memory available, with a tiny bit more if you use the expansion cartridge (which also added better sound). I had gotten pretty good at BASIC programming while using a neighbor’s TRS-80 system, so I decided to make my own game, patterned after the “Star Trek” mainframe game I had previously played on our High School’s DEC PDP-8 computer.
This was basically a text-based game, but you had a grid map display in the form of a long and short range scan, showing star systems, bases, Klingons. In my version, I added on some (text) dialog from characters like Scottie, saying “She’s gonna blow!” when your ships shield strength got low, as well as white-noise explosion effects and screen shake, thanks to a special register on the VIC that let you set the vertical offset of the display. This could be randomly set to make a shaking, explosion-like effect.
You could shoot Klingons with photon torpedoes or phasers, go to a base and get repaired, and a bunch of other things, but ultimately it got harder and harder to survive and you eventually died. It was not a bad game, it had decent balance to it and was fun to play. It took a huge effort to fit it into available memory though, and I had to strip out comments, spaces, and so on. I found many tricks to get more memory to squeeze in cool features.
I showed the game off to my friends and people on the floor, and everyone had a try. One of them, Karl, was really fond of it. Once he was playing it and I had to go to class, so he asked to stay in my room and finish the game. So I left him my room key and went off, returning several hours later. Karl was still there, still playing my game. I had created something addictive, at least for one person.
I never distributed or sold this game, it was not really practical to do so given it was in BASIC and stored on a cassette tape. But for the longest time this was my benchmark for success, a game I wrote that others enjoyed.
A few years later, Commodore released the Commodore 64, a much-improved system that (despite the “64” name) offered about 39K of usable memory for BASIC programs - still more than 10X that of the VIC-20. The C64 also featured improved speed, graphics, and sound, and floppy drive storage. I used yet more summer paycheck money to buy one. The limitations I ran into on the VIC were now gone in my mind, and I was anxious to create a newer, better version of the Star Trek game.
Perhaps I could build a non-text graphic display of the sensor screen, or perhaps I could read and write sector information on the floppy, and create a huge universe. More weapons, more ship types. I could actually try to write a good Star Trek theme music background for the game. There were a million potential options.
Diving into the programming, I went in all these directions, all at once. Different tasks would pull me away from the main game writing. I would get distracted by them, or run into obstacles with new things I did not understand. It started to get frustrated, because I wasn’t making visible progress on the game, and I was spending time on what I considered to be minutiae. I was also spending more time playing games on the C64 than writing them, and the gap in quality and sophistication of games I bought versus things I could write was obviously widening. Another demotivator.
In the end I wrote some cool stuff for the C64: a random map generator, a D&D battle simulator, a voice recognition system. But all of them smaller projects, and I never completed the Star Trek sequel or anything close in size or scope, on that bigger, better machine. The power and freedom that this new computer brought me had ironically reduced my ability to write the game I wanted to create for it.
A few more years forward, and the same story repeats. I had a job out of college and could afford a Commodore Amiga, as my next machine. It featured hardware sprite support, more memory, more storage, faster CPU and many other advancements, including windowing and a true operating system.
But I never wrote a single line of code on the Amiga, despite many ambitions to do so. Just starting a project on that platform seemed monumental and daunting.
It was not the end of my game programming hobby, but it was certainly a pause. It took a few years until I started writing code at work, learning C and developing software in the Unix environment, that I got back to it as a hobby. Working on small programs, and also learning about breaking up big projects into pieces was a helpful way to create limits and prevent getting overwhelmed.
I started getting interested in creating mobile games for Android, and also in developing games and software for the Raspberry Pi. Both platforms come with some built-in limits in capability that you must deal with.
There has been a strong interest in recent years also with retro-games and retro-game development, and I think one reason is, the limitations imposed by the retro style make it appealing to work on. The “Planet Busters” game shown at the top of this article was an entry in an Itch.io contest to develop for a retro platform called the Clockwork Pi GameShell. A Raspberry-Pi powered handheld system, targeted towards retrogamers and retro game developers, with many input, display, and cpu limitations to work around, or more positively: work with.
Another example of this retro phenomenon made popular a few years back is the Fantasy Console. Usually a software system or emulator designed to replicate very limited hardware capabilities of older computer systems. A notable Fantasy Console, Pico-8, is still in wide use today as a retro-game development platform, and is a frequently used target system for Game Jams.
At least one game that started life as a limited fantasy console game went on to greater things. Celeste, a best-selling platformer available on many platforms, started life as a Pico-8 game. It was created by Maddy Thorson in four days as part of a Pico-8 Game Jam, but now has top critic ratings and is available on Steam, Nintendo Switch, PlayStation and other platforms.
An extremely talented team developed the current version of this game, but I cannot help but wonder if this game would have ever seen the light of day if it was planned as an ambitious, multi-platform title from the start, instead of one persons attempt to create an entire game in 4 days.
Whether it is a time deadline or something else like a hardware restriction, limitations can make people creative, and free them to beat expectations. Sometimes that is just what you need to get started, and then move on to greater things.
NanoWriMo for instance can point to multiple stories of people who wrote a (reasonably bad) novel in a month, and then went on to a successful book release later. The constraints of the contest let them overcome their choice paralysis, and freely write. But then once they had something real accomplished, they could do the harder parts of editing, fixing, rewriting, and publishing it.
Much of what I covered here is not new. I’ve included some links below on articles that discuss the phenomenon of constraints aiding creativity. But in the complex world of programming the idea of working with constraints as an aid, rather than hinderance, is always worth keeping in mind. Are you stuck? Overwhelmed on a project? Maybe there is some way to apply a limit, to un-limit you.
Final note. While I enjoy timed competition and things like working on limited or retro platforms, I don’t mean to suggest somehow that either of these are the best ways to create limits for yourself. Your “helpful limiter” might just be the briefly-mentioned idea of breaking a big project into smaller ones. Or, perhaps you have some more abstract limiter in your world that you can use to keep you motivated and creative.
In an upcoming article I’ll talk about Unity, a modern game development platform that at face-value should check all the boxes for a choice-paralysis-inducing experience. It is complex, full of features and options, and has been used to produce an intimidatingly-large number of commercial games.
While these things do make it a challenge to use, I have also found it allows me to move the bar in terms of what limitations I want to take on. Instead of cooking up low-level creative solutions of how to beat memory allocation limits or how to write an efficient sprite handler, The power of developing on top of a sophisticated platform like Unity allows me to skip the low level problem-solving, and think about higher-level things like, how can I create a compelling 3D world, given I have no 3D modeling ability and only modest art skill?
In many cases the limit I creatively work around in Unity is cost, since I am as yet unwilling to invest in paying more than a small amount for game assets like models, textures, and music. How could I design a fun game, given what I can just happen to find to work with, or create with my limited skill?
That’s a very different kind of constraint versus what I am used to. The shift to newer software platforms like this has kept things interesting and fresh, and importantly, allowed me to continue creatively exploring the limits of what I’m able to do. And who knows, maybe I’ll even someday get back to my Star Trek game sequel. Anyone got a free 3D Mr. Spock model?
The author’s early Unity ‘AI’ experiments. Teaching my character to avoid going into water. Safety First!
Explore Further
Enjoyed this post? Join our weekly mailing list to get upcoming articles on computer technology history and trends. It’s free!