I first started programming in 1983 (read about my programming history here). I don’t remember what I programmed on the Ti-99/4a, but I do remember one of my first programs on the VIC-20 was flying birds program, straight from the book that came with it:
It wasn’t long after that when I started making games. Sadly, none of them have survived my various moves across the country, however my friends still remember playing the games that I made – they were pretty fun for the time.
Back then, memory and CPU cycles were scarce. I sometimes had to program parts of the game in machine language just to make it run fast enough. I often had to remove spaces from my code so that I could squeeze just a few more instructions into it. I once coded a full-screen 3D torus that took over 2 days to render! Patience was definitely needed, especially when loading programs from tape drives.
I didn’t use the same words that we use today, but at the time I really was an indie game developer. All of the artwork for my games was created by me, one pixel at a time, and then coded into decimal values and entered into the program code. All of the sound effects were basically trial and error, playing around with the 6560 VIC chip and its 4 channels of sound. Beeps, boops and white noise.
So given my background, modern game development is quite different and I’ve found myself relearning many things:
1. There is no shortage of memory or CPU cycles
My old habits are hard to break so I am always conscious of how I store data and what scope my variables are in. But in recently trying to figure out how to save game state between screen transitions I thought “what if I just serialize the whole game board and write that to a variable?” So I coded it up and tried. Success!
What wouldn’t have worked years ago worked just fine today.
2. I’m not really that good at art
I never really was, but the limited amount of pixels that we had to work with decades ago kind of hid that fact. For another game still currently in development I found a graphic artist on Reddit /r/gamedevclassifieds and hired them. Wow. What a difference. For a few hundred dollars I got game art that completely blows away anything I could have ever done.
3. I’m also not that good at sound
I play guitar, piano and drums. I have no problem playing music, but darn I really can’t compose it. So I’ve been hiring sound people for my game soundtracks, and they’ve been doing a great job. And as it turns out, I’m also not that great at sound effects. For Wabbit Wars I had my usual beeps and boops until D. W. O’boyle came along and recorded cute little rabbit voices saying things like “I’ve got an onion with your name on it!” I loved it, and the game has a lot more character because of him.
4. Free to play is the new shareware
I saw the rise of the shareware distribution model and was fascinated by small developers giving the first episodes of their games away for free (and of course I loved playing them too) but until the advent of high speed electronic distribution and social media and there really wasn’t such thing as a viral game. There were very popular games, but not truly “grandma is playing it” viral.
Apparently I didn’t remember the lessons from the shareware days. The race to the bottom in mobile pricing seems inevitable looking back now, but in 2009 I didn’t think so. So the mobile games I made then were all paid. Now, I’ve just recently learned how to do in-app purchases and will only publish free mobile games going forward.
The spectacular viral hit Crossy Road
On this topic, I think “free to play” is good. Very good. It allows people to try out software before they decide to make a purchase. And when it’s done right, like Crossy Road did, it isn’t predatory at all.
5. Collaboration got a lot easier
In the 1980’s the only way that I knew how to collaborate on game development was in person – getting in the same room with someone and jamming. Sometimes one person would be at the keyboard coding while the other watched and gave feedback (pair programming, anyone?) I remember winning a programming contest with a partner and we were overjoyed at the grand prize of free pizza – but looking back now, the real prize was working together.
In the late 1980’s email and chat came along, and although communication became easier I still found collaboration to be most effective in person. Then in the late 1990’s I started using code versioning systems, and also started working with others by contributing to open source linux software projects. I was still an indie game developer, but my day job was exposing me to the future of collaborative development.
These days it’s not only easy but also quite fun to share code (looking at you GitHub) or even share working solutions that others can debug and contribute to. I love jsfiddle for JavaScript, it’s brilliant. Technologies like the Unity web player allows distribution of alpha development builds out to testers and it’s a substantial improvement over Flash game distribution of times gone by.
Moving forward…
There are of course too many things that have changed in developing games over the last 30 years to even attempt a complete list, but these are the things on my mind today. Game development is still exciting, and I have to admit that embracing free to play means I can say to my friends “try my game” without feeling guilty in asking them to purchase it.
Want to collaborate on something? Hit me up! Twitter is best. Artists, sound people and game designers are all welcome. And feel free to leave a comment, I read them all.