We're Mare Sheppard and Raigan Burns, and together we form Metanet Software Inc. Metanet is based in Toronto, Ontario, Canada, a city now bustling with energy and game development goodness. But it wasn't always that way! We're here to tell the story of how we got started making games, largely by charting the development of the many iterations of N, taking a few tangents and noting some dev lessons we picked up along the way.
Our story begins back in 1998, when we were both attending University of Toronto. Mare was taking visual art, sociology and computer science, and Raigan was taking philosophy, film, and computer science; we met in first year in Java 101. We started chatting in the lab one day and really hit it off, bonding over a hatred of boring application programming and a love of games.
Over the course of those heady U of T days, we spent a lot of time downloading and playing games from Home Of The Underdogs (a site that had lots of freeware, shareware, and "abandonware" games), playing together or recommending our favorites to each other. There were some that stood out: Soldat, Super Bubble Blob, Puchiwara No Bouken, and Zone Runner were exceptionally fun and inspiring, and you can see the echoes of those games in N.
As we played, naturally we talked about what was fun or special about our favourites, and imagined what went into making them; it dawned on us that many of these freeware games were being created by small teams of just one or two people, several of them students. Just like us! This planted the seed in our minds that you could make a pretty great game with just a few people.
Learning the ropes
We still weren't sure how to go about doing that though, and we certainly weren't thinking about making games as a business. Back then, universities didn't want anything to do with games, and the game development scene was nothing like it is now: it was very hard to meet anyone who shared our interests locally-we didn't know of a single game developer in Toronto! Most of the exciting smaller games seemed to be coming out of Europe, which was beyond our reach, so we just continued playing games and thinking about them.
Luckily, in another comp-sci course, we met Jon Mak (who would later found Queasy Games and make Everyday Shooter and Sound Shapes). He was very inspiring; he showed us game after game that he'd made all on his own in high school, each one of them more interesting and polished than the last.
We became friends and spent a lot of time talking about games. We talked about what we liked, what we disliked, what we wanted to make, and what we wanted to play, and about the technical side of making games as well. Jon explained how he'd solved some problems and how his engines worked, and we showed him some really cool papers we'd been reading and thinking about. As we talked, we were each cultivating new ideas and being inspired by what was being shared; we were accelerating each other.
The fact that those freeware games we'd been playing were each made by only one or two people didn't fully sink in until Jon had showed us the games that he himself had made in high school-we had finally met one of those crazy people who made their own games! When that happened, in person, we really got it: the idea of making games became concrete and accessible. Knowing Jon as a person and seeing the things he'd been able to accomplish made us feel like maybe we weren't so different, and maybe it was possible for us to do it too.
Experimenting in school
We were familiar with basic object-oriented programming from courses at university, and we started learning game programming on our own, thanks to online tutorials, active and helpful communities on forums, and mostly by just trying stuff to see how it worked.
We started working on a series of experiments in Flash, trying to implement whatever ideas we were interested in, with no clear goal except learning. It was really cool to watch little tech demos come together and come to life (or often, fail completely), but at the same time, it eventually began to get frustrating because our little experiments never amounted to anything. We had implemented some simple particle systems, basic ragdoll physics, ray-casting, tile-based collision detection and response prototypes, and rudimentary AI tests, but we still had no idea how to take these pieces and make a game out of them.
Time passed; we graduated from university and spent a few years working at day jobs, scraping by on minimum wage and becoming skilled at keeping costs extremely low. We rented cheap apartments with other students to reduce the cost of living, and worked from home; we used public transit and cycled rather than owning cars; and most importantly, we tried to do everything ourselves. Keeping overhead as low as possible is something we still believe is very important, as it gives you more time to work with ideas. Anyway, we played around with programming projects in the evenings and weekends, and occasionally at our jobs (shh!). Then, in early 2004, we randomly heard about an event called Flash in the Can being held in Toronto, which was sponsoring a contest for Flash games.
Meeting the milestone
The deadline was about two months away, which turned out to be quite important-having a concrete deadline was a catalyst that motivated us to try and actually finish a game, building on our previous programming experiments.
Our initial plan was to make a stealth-based platformer; we had made several tile-based platforming prototypes, and figured we could find something fun to do related to sneaking around, climbing walls, and dropping on unsuspecting guards. We also knew we wanted to make a game about ninjas (because ninjas are cool), so it seemed obvious to us to make the game about sneaking -ninjas are, after all, masters of being sneaky.
With this basic plan, we began to hastily cobble together many of the little experiments we had worked on over the past few years: collision detection, ray-casting for the enemy AIs, and a basic physics simulation affecting the player character (who was a circle, at this point-both graphically and in terms of collision shape).
"Six weeks!" We thought, "that's plenty of time!" We were spectacularly wrong. Instead of six languid weeks of us neatly slotting together finished chunks of code, birds singing at the window as we put our feet up and cheerfully played our new game, what followed was six insane weeks of us frantically rushing to get something done, stunned by how much there was to complete that we hadn't even considered (making levels, UI and menus, saving progress, etc.)-plus we were still working full-time at those day jobs.
This experience taught us how grueling and horrible crunch is; we were burnt out for months afterwards, and we've made a point to try to avoid it ever since. Actually, we learned something else as well: how long it can take to really finish a game even when you've got most of the parts ready to assemble! Take your estimation and double it, and you might be getting close.
Part of the reason development was so time-consuming was that we didn't have a crystal clear idea of what we wanted to end up with, or a design doc; this may sound dangerous, but even today this tends to work well for us-having the flexibility to let the game tell us what it wants to be, and the courage to try tweaking and changing various aspects of it is so important.