I've wanted to make games for perhaps as long as I've been programming - perhaps even longer. One of the first things I wrote when I was learning to program (on my mum's Palm V) was a basic Breakout clone, and when I first started web programming, some of the first things I wrote were simple business simulations using my cutting-edge, shoddy PHP skills.
Of course, along the way I discovered that I was pretty decent at writing websites and their backends, and it turned out that was a part of the industry that was fast-growing and paid really well - not to mention the instant feedback and fast iteration you got from the Web ecosystem.
I enjoy fixing large problems and designing complex systems more than I ever did; as my experience level has grown, I find myself fixing and designing things that a younger me would have found impenetrable, and the idea that I'd be writing code that handled billions of dollars worth of transactions would have been terrifying (and quite frankly, still is, in the best of ways).
Throughout it all, though, I've always wanted to make a game. What that game was, and what I wanted from it, have changed over the years, but I've now finally got one out of the door - Slam went into Steam Early Access yesterday, and while it's not totally finished, people are paying money for it and I don't feel like I'm ripping them off, so I call that shipping.
It's taken a long time, a lot of dead ends, and a lot of work to get to this point. I want to tell you about some of the reasons why, and some of the places I went wrong. Because, as it turns out, making games is really hard.
Ideas
I like to think that everyone has at least a couple of ideas they think would make great games. That's probably true - there's a lot of really interesting ideas in the world - but what makes a game enjoyable isn't the idea, it's the execution.
The game I always wanted to make was a giant, multiplayer world, full of content and exciting things to discover. This is kind of a reflection of my take on the world; I love discovering new places and seeing new things, and so I wanted a game that reflected that, that gave people the tools to make worlds and systems and gave me the tools to explore and enjoy it.
Of course, what I'm describing was perhaps the original intention for Second Life, which was revolutionary in its time but ultimately has ended up being a note in the margin of gaming history; the creation tools were too complex, the client experience too slow and clumsy, and there was no real framework to build around (though, to the community's credit, they made a lot of it).
The game that first showed me the glimmer of hope - that there was a way to do this that could be massively successful - was Minecraft. It seems obvious now, of course, but back when I first encountered it in 2010, it was still a relatively young game, pre-1.0 and with a small but rapidly growing community.
Back then, there were only around 100 multiplayer servers you could connect to, but you could log into almost any one of them and come across something interesting, a creation someone had built. To my horror, though, griefers and server crashes were often just destroying days of work, and so, naturally, I thought I should engineer a solution.
Preservation
The Minecraft protocol was obtuse, and the Java files that made it up were obfuscated, but the community had already decoded most of the protocol and so I set to writing a Python client that would log into a server and download the entire map - this is easier than it sounds, since back then worlds were finite and relatively small.
I set up the script to go through the online server list, log in, and archive the worlds it found a couple of times a day. Initially, it just produced files you could load into a normal Minecraft server to play, but after a while that became time-consuming and so, using my newfound protocol knowledge, I wrote a server too, and dubbed it The Archives - you could log in, request a world, and load into a copy of it at any of the points in time I had copies of.
The key had been finding a trick in the client code where you could reset the world and stream in new chunks without disconnecting - essentially allowing you to load the player into a series of different worlds dynamically, which The Archives used to let you zoom through the history of servers.
Of course, I couldn't stop at read-only copies, and so I also built an actual read-write server as well, complete with basic water physics (that was often hilariously broken) and started building a small community. I switched the archiver to opt-in, as well - some people didn't take kindly to being shown how their personal worlds were open to the internet at large - but the world-switching technology also powered the main server, so I could give every user their own world (that nobody else could edit - pretty impressive at the time).
I eventually released the server software as open-source, and a good number of groups switched to running it; at one point, I think, it was beating out the offical server software for number of servers live, though not for very long.
I slowly drifted away from the Minecraft community and from The Archives, but not before I'd had a taste of what it was like to enable and create huge virtual worlds. By the end I'd implemented a procedural terrain generator (as Minecraft had just gone to infinite worlds), and the feeling of opening up the game and standing on top of a mountain my code had created played directly into that feeling of building worlds that I'd always had.
Ambition
Of course, this all led to me trying to write a game, rather than just a server for an existing one. And I don't mean a small or easy game - I had foolishly decided from day one I wanted to build something big, exciting, and expansive.
Of course, I was one person with a pretty poor knowledge of game development, and time and time again I tried to build something that even came close to that vague idea in my head. One version was a giant collaborative space-station; another was a nation simulator where people voted, made laws, and did jobs to keep their own nation afloat.
At one point I even had a basic networked world, where you could place items, move things, and even had portals between worlds (both a hangover from my Minecraft server work and my love for the Stargate TV series). It had basic dead reckoning for movement and a few other tricks I'd picked up along the way, and if you looked at it the right way there was something there.
But, while programming backend servers and clients was perhaps possible for a student with far too much free time (and believe me, I tried), time and time again I ran into the two roadblocks I coudln't solve with my programming skills; design and content.
Weaknesses
While I'm a pretty decent 3D modeller, I'm not a good texture artist, sound designer, composer or graphic artist. If you look at my early projects, they all have one thing in common - I get excited, build the start of a game engine, and then realise I have no chance of making the thing look nice at all and give up.
Even if that wasn't the problem, the sheer scope of what I wanted to make was always too much - sure, a basic engine is one thing, but doing all the interaction, UI coding, input handling, animation and more was a lot of work, and I nearly always hit some kind of plateau.
The key, of course, was to make something smaller - and, importantly, to use an existing game engine rather than starting from scratch with Python and some basic 3D bindings.
It took me a while to realise; my first reaction was to think that it was the multiplayer, networked aspect that was overcomplicating things, and so for a while I took to trying to make a single-player game - but of course, I went for a tycoon game with lots of simulation and full 3D rendering and a lot of other needless things.
After switching that between 3D and 2D, web-based and Unity-based, running an airport and a space station, I eventually realised that the problem wasn't in my engine choice, or presentation style - it was that I was trying to run before I could walk.
Slam
With that in mind, I went in search of a deliberately simple idea. I wanted something that had simple gameplay - in fact, not only simple but a known quantity, so I wasn't trying to tread fresh new ground on my first attempt.
After going through some ideas - basic arcade games, that kind of thing - I settled on a sliding-block puzzle game. It's pretty easy to program the gameplay for (though a Breakout clone would have been easier!), and I thought puzzle design wouldn't be too hard; have a few mechanics, build puzzles around them, and perhaps have an automated solver to help things along.
Graphically, I went for a simplistic 3D style; I knew enough about shaders and lightmapping that I could model something using flat textures and throw enough ambient occlusion and lighting on there to make it look nice; using the graphics code to do some of the work for me, to some extent. Doing 2D art that looked as decent would have been a lot more work given my skillset.
Writing the core game itself went relatively quickly; I made lots of pieces, wrote a script to place those pieces into a Unity scene and lightmap them, and then the basic movement logic to move them around together.
I tried out some mechanics and picked four of them - magnets, laser walls, teleporters and sliders - implemented them, and designed basic introductory levels. That made up the lower end of the difficulty curve that was meant to introduce each mechanic before combining them with others to form more and more complex puzzles.
Levels
Unfortunately, while the gameplay design and implementation for a puzzle game is simple, designing the puzzles is not; it's surprisingly hard to sit down and design intermediate and dificult puzzles, even when your design-play-change loop is down to around 30 seconds, as mine was by the end.
The automatic solver I wrote helped make sure I didn't make levels that were meant to be complex but could be solved in three moves; unfortunately, due to the nature of the solution space, the solver rapidly becomes incapable of finding solutions longer than 13 or 14 moves (as you add a move the number of options triples each time).
For that reason, it's also not easy to write a level generator, unless it's written in such a way that it works backwards from a known solution string. I've tried a couple of times, but at this point I suspect it will be easier to just keep doing what I have been - sitting down every evening and designing a puzzle or two, slowly filling out the game towards the goal of 100 levels I had promised (both to myself, and on the Greenlight page).
While this was going on, I was polishing the parts of a game that you often don't think about at first - input, options menus, adding some sound and music, fixing the inevitable bugs, adding save games and level selection screens, and plenty of other stuff.
My goal was to have most of the game (bar the level set) in a close-to-finished state, and then release the basically complete game engine along with the 40 or so levels I'd got to onto Steam Early Access. It was a way of making a watermark for myself as well as hopefully getting some community feedback on how the levels progressed.
Release
That's roughly where I am today. There are some more improvements I'd like to make to the game - things like adding a little camera shake when the blocks hit, fixing the graphics options to have all resolutions selectable in game - but all of that is polish, and the game fundamentally works. The Early Access release has 38 levels, with a decent number of easy and hard ones, but with a somewhat inconsistent difficulty curve.
All I have to do now is make another 60-odd levels - that will take some time - and apply some last bits of polish. When that's done, I'll upgrade it to a full release on Steam, and publish to the App Store and Play Store as well, since as a puzzle game it works pretty well on mobile platforms (bar a few input changes for touchscreens).
The key thing, though, is that I've learnt a lot. The process of bringing a game from concept to a point where you can sell it is long and arduous, even for a simple puzzle game. I feel a lot more happy with all the stuff I didn't have experience with before, and I've how to adapt some of my automation skills from the web arena into game development - things like making your build process totally streamlined, and how to encapsulate things properly.
I never went into this project with the intention of making money or having a big hit - sliding block puzzle games are hardly going to set the world aflame. What I wanted was that sense of completion, of seeing something through to the end and calling it done, something that we often don't get to do on the web development side of the fence.
Even better, though, I don't have a burning desire to dive straight into a huge project straight away; instead, I find myself thinking about small-scope games that are a little more unique or a little more deep, which is kind of where I wanted to be.
I still plan on making my giant sprawling multiplayer game one day, of course. Just have to work up to it, and ignore all the server code I keep writing for it when I'm bored.
Slam is now available on Steam Early Access