Reasons for Modest First Projects and Incremental Learning

Mar 30, 2014

I asked another question to the community with @HobbyGameDev on Twitter recently. For the most part the responses were incredibly illuminating about what challenges new game developers were experiencing. I love these kinds of questions and responses since it helps keep me firmly connected to people’s real needs.

Although I was able to field a number of exchanges within @reply tweets, the most important one to address that couldn’t fit in that space is perhaps this exchange:

I want to be clear that I am in absolutely no way intending to draw any negative attention, attitudes, or ill-will toward our good friend in the world, Orange Rectangle (or O.R., for short). I asked my question with the specific purpose in gaining a better understanding of the challenges people were experiencing, and O.R. then offered an answer in good faith to help me. I attempted to offer some real details (those numbers are from Uncharted 2, by the way) in the sincere hope that this might help lead to a startling realization.

It did not. Instead O.R. dug deeper into the trench, now on the defensive. Then O.R. lobbed a grenade, suggesting that the problem here must be that I just don’t know what I’m talking about.

If I thought O.R. was just trolling, I’d simply ignore or block them to prevent any further attention being stolen from the many people out there who are really interested in making videogames. However I’ve met and spoken with enough people face-to-face sharing a mindset similar to that of O.R. to believe this is worth addressing directly. That this is still a fairly common way of thinking for people getting started out seems to me a sign that it hasn’t been suitably explained, or at least not yet in a place that’s easily found by those who are looking.


Dear O.R.,

I’m not saying you can’t or shouldn’t. Maybe you’ll pull it off. That’d be awesome. More power to you.

I suspect many people doubted Notch when he started work on Minecraft. Although by that time he had already been programming for 25 years. People were probably skeptical of the team that made Angry Birds. That may have just been extrapolating from the 51 games that Rovio made before that project became a new standard for mobile gaming. The success of Super Meat Boy was not guaranteed. However Tommy Refenes had been making games for 18 years before that, and Edmund McMillen, Tommy’s collaborator on the game, worked on 14 finished games before Super Meat Boy (including its free Flash precursor, Meat Boy).

Even with their accumulated experience, these now famous developers still didn’t make games with the look and feel of a modern Call of Duty or Uncharted. From a technical, team size, and content creation standpoint, Minecraft, Angry Birds, and Super Meat Boy are tremendously less complicated than either a Call of Duty or Uncharted sequel (let alone a brand new intellectual property).

Many videogame developers at some point bite off more than they’re ready to chew, for at least one project, and can sometimes take away from that experience some helpful concepts for later. For me that was Guinea Pig back in 2004 (screenshots here and here).

A screenshot from Guinea Pig, for which my engine used skeletal animation (authored by a custom tool), clothing/skinning, blood/bullet decals, real-time fully destroyable terrain, dozens of weapons types, parallax scenes, dynamic fire systems, hi-res “mode 7″ semi-3D aircraft effects…
 

So, with that in mind, why not just attempt the dream game first, and if it doesn’t pan out, just learn some lessons in the process?

Here are a few reasons that I think should at least be considered.

Why Not Start With Uncharted/CoD

I’d like to make a case here for why those tutorials don’t start with a Call of Duty or Uncharted style game (let alone a variation with world building and other additional features), and instead focus on games like Pong or Asteroids.

In Daniel Coyle’s The Talent Code: Greatness isn’t Born he talks a lot about deep practice, or edge practice. As a takeaway from his multi-year international study of what world class experts in a variety of disciplines consistently do to get there, he explains:

“…you can capture failure and turn it into skill. The trick is to choose a goal just beyond your present abilities; to target the struggle. Thrashing blindly doesn’t help. Reaching does.”

Or, if I can reframe that in terms of a more widely recognized system of incremental learning: no matter how strong, flexible, and quick someone is, there are still steps that they need to progress through in order to earn a black belt in karate. Skipping over essential steps means instead of productive edge learning atop a solid foundation, a person instead tends to wind up with sloppy, ineffective actions detached from the many lessons figured out by prior generations.

While I do not claim to be a world class expert, as Coyle’s subjects are, I have enjoyed some recognition for my commercial videogame work, which started more than a decade prior by doing exactly the same kinds of simple historical game remakes that I consistently encourage others to try when starting out. By starting small and moving toward increasingly complex games, a solid foundation of applied design principles and practical coding habits can be formed incrementally, with lessons picked up along the way that are appropriate in size to be learned from.

This Pong remake was some of my first experience with AI. Around the time I was playing (and modding a bit for) Quake 2. I wasn’t crazy for retro games – I didn’t even play Atari’s original Pong until 8 years later – but I was interested in creating games that I could finish and strive to make well.
 

Over the years I’ve now seen a number of people massively overshoot their means on an early project and fail spectacularly. In most cases that unfinished game is the last one they work on, never fully recovering from having dug a pit of embarrassment and fighting through considerable frustration every step of the way. Getting some practice before diving headfirst into these kinds of undertakings can help steel us to the complications that they entail.

For example, by the time I bit off more than I could chew on Guinea Pig, I had already completed more than 15 other smaller games in the years prior. That steady momentum beforehand gave me the ability to pick myself back up and promptly get back up to full speed on new projects when that one didn’t pan out.

This progression of foundational skills was also a central philosophy to both videogame development clubs I helped start: before someone has been a lead or solo developer for a game of early 1980’s-gameplay complexity, they’re typically not ready to lead a team of others on a game of late-1980’s gameplay complexity, and so on. This begins with late 1970’s complexity: Snake, Breakout (not Arkanoid yet, that’s mid-80’s!), Asteroids, or Space Invaders.

My first graphical game was based on the late 1970’s game Snake. Again: not because I grew up with it – I was born in 1984 – but because in terms of game mechanics and programming it was a realistic place to start.
 

For those developers that truly are extraordinarily efficient and clever, who say “that’s so easy, why bother?” I have two responses: (A) that’s grand, then you’ll have no problem knocking it out in 30 minutes, or in an evening at most, after which when you come back with it completed you’ll have impressed and earned the trust of more potential collaborators. And: (B) even if you know how to get started, and know that you know enough to work your way through it, going through the actual process of doing so will involve sorting out some details, processes, unexpected complications, and chunks of code that will together speed up and simplify working on the games you take on later.

Being able to do something and having actually done it are not the same thing. In particular, after you’ve already done it you’ll have expanded the domain of what you’re ready and able to do next.

Being Unprepared Isn’t Bravery

As my friend Nicholas Brown commented:

“Shooting high and learning from it is nice but at a certain point you’re trying to shoot down an airplane with a bow and arrow. It’s just not going to happen and you probably won’t get anything useful out of the experience. Saying ‘that project is out of my scope/skillset’ isn’t fear, it’s good sense as a developer.”

There is a certain amount of fearlessness, unreasonableness, and boldness that successful entrepreneurs, innovators, and cultural leaders of all kinds have had at their core. However, the fact that some amount of fearlessness is a factor in success does not automatically mean that an even greater amount of fearlessness linearly correlates to greater success, nor that it’s the only factor. Bold leaders still need a viable strategy, considerable experience and connections in the relevant domains, and a certain dose of patience and discipline underlying their persistence and determination.

At the heart of Coyle’s research in The Talent Code mentioned earlier is the idea that we can learn most from those experiences which are just beyond our reach. That’s at the core of deep, edge practice. When we extend ourselves greatly beyond our past and present proven capabilities, there are often too many convoluted ways to make mistakes for us to figure out how to make sense out of what isn’t going right, let alone to learn from it.

First Projects Are Always Rough

We tend to learn most rapidly when we’re still very new at something. Anything about the field can be absorbed as new learning. We quickly overcome the awkwardness and inefficiencies in dealing with whatever development environments, programming languages, and content tools we’re working with. If you put a few months into learning how to paint landscapes well, your work at the end of that time would likely bear no resemblance or fit to the first ones attempted. Because of that rapid learning, going in this case from one new painting attempt to another gives practice and opportunity to rethink the initial decisions, and will likely work out much better than just spending all of those months retouching the very first painting started.

As Coyle (again, from The Talent Code) explains about the famously talented and accomplished Brontë sisters in relation to their work as novelists:

“…the myth Barker upends most completely is the assertion that the Brontës were natural-born novelists. The first little books weren’t just amateurish — a given, since their authors were so young— they lacked any signs of incipient genius. Far from original creations, they were bald imitations of magazine articles and books of the day, in which the three sisters and their brother Branwell copied themes of exotic adventure and melodramatic romance, mimicking the voices of famous authors and cribbing characters wholesale.”

Because our first work is inevitably rife with beginner errors from learning as we go – even world famous authors first wrote amateur junk – insisting on making an idealized dream project as your first undertaking is unfair to the vision, condemning it to be rife with beginner errors. This is instead an ideal time to experiment a bit with modeling the proven past successes of others (those that are reasonably achievable within our means), including simple historical cloning as a form of initial practice and not as a shady business scheme. The Brontës started that way.

I’d say try getting some of the junk of your system first on titles that can be finished far sooner, aren’t as personally important (read: not yet highly original), and won’t involve pulling others into the risk involved (even if not risking your and their money, then at least out of care and respect for their time in something that has a reasonable chance of not finishing or finishing well).

You Can’t Compose Without Playing First

When someone wants to play piano, do they begin by immediately composing original works? I don’t doubt at all that in the history of all civilization there are people who have tried to do that. Generally, though, we have not heard of them or their work.

We start with learning a bit about notes, sheet music, and scales. We build up to childishly simple sequences like Mary Had a Little Lamb. We move up, through consistent and focused practice, to trying to merely perform well some the more advanced classical works far before trying to compose our own.

The reason we see so many introductory materials about games like Pong and Asteroids – including the Code Pack Bundle (my own approach following that path) – is because those are the Mary Had a Little Lamb of videogame creation, a tried-and-true way for someone new to game development to get oriented and learn to perform full, simpler classics before trying to become the next Bach or Mozart from day one.

Building an Aircraft Carrier… First

Where the above music analogy breaks down is that composers are often able to write music primarily alone. While that is true for a subset of videogames, it is not the case for the size and scope of videogames that you’ve identified as your target.

If someone is interested in making a boat and decides that the kind of boat they wish to design is an aircraft carrier, that’s necessarily going to require a massive scale of teamwork, money, experience, earned trust/credentials, compromises, and a lifetime of work leading up to that point. It either won’t be the first ship they work on, or the rushed result will involve so many compromises that it will not come anywhere close to what is typically expected of this ship type.

While it’s true that we don’t have many of the same material constraints and labor challenges as ship builders, what we are unavoidably faced with are literally millions of design, artistic, and technical decisions, from the very large to very small, which we have to make about everything in the game.

Faced with all of those decisions, making them well at every step either means having the experience from enough variety of past projects to make informed tradeoffs between alternatives (which is why teams generally want professionals experienced in videogame making, not just people who “can program” or “know Photoshop”), prototyping like crazy to find even a few small innovations that work, or adhering fairly strictly to conventions.

However, note that even companies filled with experienced, full-time professionals creating massive games that do adhere to most conventions of their genre still manage to go through $20 million just to get their game done and complete. These companies are in the business of maximizing profits and minimizing costs, with both internal and external pressures to figure out ways to do more and better work with the lowest possible expenses.

It still costs them $20 million or more to make what may appear to be a formulaic and relatively straightforward followup to an existing franchise (note that the actual changes and additions involved are often quite complex, but the differences may be difficult for someone who is not on the team to fully appreciate).

An Idea is Only as Good as Its Execution

One of the other common themes that arise in advice from experienced developers for others just starting out is along the lines of “ideas are a dime a dozen” or “no one cares about your great game idea.” This is in regard to what you’re calling your “secret” that you suggest will, alongside world building, set your first game apart from Call of Duty and Uncharted.

My entries presenting my take on this include Stop Arguing About What Makes a Better Game and Start Before You Have an Idea, which covers an idea I often explain to others as:

“I’m going to make the world’s best painting. I have an idea way better than the Mona Lisa. That one’s just a picture of some girl.”

Most successful games aren’t a particularly genius idea. Conceptually they’re usually pretty blatantly derivative but are polished in their execution to an amazing degree. When the idea is at least unusual, perhaps one that has been done before but not well enough yet to achieve widespread commercial significance and recognition, at best that concept serves as a marketing point to get people talking about it. But people generally don’t keep playing a game, nor recommend a game to their friends, based primarily on whether a game has an interesting idea, unless it also has world-class execution and refinement. Provided it’s got world-class execution and refinement, an interesting or original idea is often not even needed.

Pick A Fight You Can Win

Sometimes there’s a confusion that because one or two indie games succeed financially in a genre previously thought dead (point and click adventure, for example), or with a very weird type of game (much of what’s found in IndieCade or IGF), those games have been proven to be economically viable after all.

The underlying misunderstanding though is that what may be a tremendous amount of money when split only 1-8 directions among a small team of indie developers working out of their homes or a tiny shared office does not even show up on the radar of the kind of money that AAA companies burn through in only a few months of salaries for massive teams comprised entirely of experienced developers, legal/business personnel, and support staff along with paying for sprawling office complexes, retail distribution arrangements, television/billboard advertising budgets, etc.

Part of the way this all holds together is that even though a few individuals (out of the many, many more trying) might make enough money to pay their own costs and then some, it’s still often far from being something that the big studios can take seriously as a business opportunity.

In 2010 I made a strange iPad entertainment app that paid my rent for 18 months. That registers as a medium success – weirdly putting me somewhere in the upper percentile in terms of return. While it clearly didn’t make me wealthy (my rent at the time wasn’t much), many more developers lose considerable sums of money or generate very tiny revenues in the range of fewer than dozens of dollars from ads, virtually non-existent sales, etc. Also, as a fair warning: the App Store was definitely a lot less of an over-saturated mess in 2010 than it is now. (Speaking of which, back in 2008 I developed a game for the app store that earned considerably more than that… for the publisher, which is how I learned a lot about being the weaker party financially in a negotiation.)

Anyhow, for perspective, a massive publisher pays their CEO more money than that 2010 app’s total earnings in what calculates to about 24 hours of their time. That’s not including the salaries of 9,000 other people, the costs associated with massive facilities, or the remaining mountains of money expected leftover for annual profits, etc. They have truly staggering ongoing costs to keep up with, which means they can’t afford to take risky chances on little weird stuff, or on genres that are no longer desired by mainstream players. They deliver on what they have solid evidence to think will make a sizable return on their investment. Projects that don’t meet that goal get eliminated. They’re a business.

This is why when we see advanced indie developers succeeding commercially, it’s usually not by doing better at what the big companies are in position to do well, but instead from some combination of strange projects (with regard to their execution, often not in the main idea; i.e. tons of personality in an otherwise relatively simple experience), retro genres that the AAA companies haven’t been able to justify for 10+ years due to the shrinking level of market demand for such games, or the intersection of both (meaning tons of personality in a retro genre that has otherwise lost most of its market significance). With the rare exception of some mod teams that quickly get swallowed up into the machine and vanish for years doing polish work, indies stick to guerrilla tactics in niche domains that the huge companies can’t justify meddling in.

It’s not a matter of purely creative vision that Minecraft is built out of 1-meter cubes textured with pixel art, instead of having the look and feel of Uncharted or Call of Duty. It’s small team resourcefulness.

 

(For more along these lines, read up about Blue Ocean / Red Ocean Strategy.)

Funding Will Affect Design

Getting funded does not mean that you have the freedom to design your perfect game. When money gets involved, it tends to influence what gets made, even when sometimes only out of some crude evolutionary feedback loop where the games that do well in a given market space tend to soon be followed by variations from competitors.

But what about something like KickStarter, in which customers prove that they’re there before development even begins? The space is filled with people that, because they’ve never had to work with a real budget before, tend to not know how to schedule and plan a commercial project.

If KickStarter sounds like freedom, it’s worth looking up Code Hero, which raised $170k, well past their $100k target. I’ll spare you the web search, and share this update from last year. Effectively, they ran out of money long ago and are now an entirely volunteer effort. Here are their KickStarter updates.

Where I’m Coming From

Although I started as a hobbyist, returned to being a hobbyist, and help other people get into videogame making as hobbyists, what I’m suggesting about the nature of huge commercial-scale videogames is not just guesswork.

I’ve worked professionally as a game designer on the size of games and teams that you’re talking about: games that take years, 80-200 full-time professionals, and tens of millions of dollars. I’ve also worked professionally as a game designer at other commercial scales: at a casual games start-up, in a gameplay R&D company, and as an iPhone game developer both independently and through publishers. I am familiar with at least a cross-section of commercial videogame development.

More importantly to this exchange I have also, with zero budget, served as a lead or solo developer on more than 85 completed freeware games with 3-18 month production schedules, and hundreds of same-day playable prototypes. Some of those were for class projects, some were created in clubs that I established, and many were just developed on the side.

Being in a position to compare those professional and nonprofessional experiences, I can say with total certainty that I have found infinitely more creative freedom in the projects that have no budget or funding than I’ve seen in working on games with a big budget.

That applies no matter whether I was being paid steady salary, hiring/paying/leading a team of others, funded by outside investment, or even when completely self-funding projects and theoretically having total directorial control. Games that cost money to develop have a certain obligation to prioritize earning (at least) that money back, which places certain inflexible outside demands on the work.

Make Finished Games. Without Funding.

There are ways to make videogames that don’t require getting anyone else’s approval, taking anyone else’s money, or handing over veto control to your design ideas.

It takes time and a lot of work. There’s no easy shortcut to it. But it is a way.

That way is to start small, building your way up from modest beginning principles based in time-tested classic designs, toward the point where you’re prepared to do your more grand and elaborate game ideas justice, so as to have to ability to realize them without making compromises in service of financial obligations.

In other words, the way is to make videogames for free for awhile, incrementally advancing your skills and design understanding with each new project.

If however you choose to still push on the route of seeking substantial external funding, especially without any track record yet of completing any simpler games, I wish you only the best. Good luck.



Subscribe by e-mail to receive an update every month of all new HobbyGameDev articles, videos, and game development resources.



26 Comments

  1. McFunkypants says:

    Finally, an article that explains what I’ve tried to tell a hundred beginner gamedevs filled with the naive optimism of the Dunning-Kruger effect. Thanks so much!

    Now I can send em here, on their way to greatness. I made http://www.onegameamonth.com specifically to encourage everyone to get those first dozen training games out of the way and to celebrate the huge accomplishment that hitting the finish line on a game project (no matter how small) really is.

    As for me, I’m about to hit my fortieth tiny game and I’m pretty much ready to receive my “overnight success” =)

  2. Bill DeVoe says:

    Really good write up. I agree with you that everyone tackles a project they’re really not ready to do and then learn some great things from that experience. My first effort (still on my backlog of things to do) was a sprawling multiplayer magical questing game. A little too much for a single person first attempt. I then dialed it back and made some smaller games that explored some specific features and that worked far better.
    There are people who can work singly and pull off amazing things (thinking Banished by Shining Rock and Minecraft). But those are few and far between. I think, though, that the Kickstarter revolution has everyone believing that if they can just get X they can get millions to do Y. And it very often doesn’t work that way. We hear about the successes and think “ooo – that could be me” but those people generally are the established developers (like DoubleFine). And we hear about those successes because they’re anomalies.
    I think everyone should go into this as a way to be creative and do something for themselves. If you’re in it to get rich, you’re in the wrong industry. There are occasional breakthroughs, but again – those are the anomalies.

  3. Rob Solomon says:

    I don’t think anyone who has done any significant development would disagree with what is written here. The issue is conveying this to a beginner. They simply don’t understand why learning Pong (or other classic games) is relevant if your long-term goal is to make a large-scale AAA game like Call of Duty.

    This is what was suggested to me by “forcing me to learn Pong or Asteroids first”.

  4. jeffdr says:

    Excellent article.

    My first game project actually did get funded, and I worked with a team of about ten people, but all the lessons above still applied. The game/engine I wrote was Darkest of Days (http://en.wikipedia.org/wiki/Darkest_of_Days), and it by most accounts sucked, but we did pull it off and ship it. So I feel this sort of makes me the living example of what O.R. was wanting to do.

    I would still advise him against it. I wish to hell we had decided on something smaller in scope to make instead. We did learn a lot from that big ~3 year project, in my case most of it technical aspects of engineering projects of that scale, but one thing we certainly did not learn was how to make that game any good. It was a pretty much a guaranteed failure from the start, and I could have been spared untold worry and hardship had I known this earlier.

  5. Mac Morrison says:

    Yep tottally agree. I’ve spent MANY years making games – on zx spectrum (a few published ‘properly’ or on mag mounts) then java and flash web games.

    All were nice and simple.

    It’s taken me years to get round to making a mobile game, and basically i had to scale back things and make something really simple and ship it and learn from it.

    First off make a game thats playable in under 2 weeks, ship and move on.

  6. Tom says:

    I’m struggling with a response to this post. I agree completely with your thesis, Chris, yet I realized halfway through your article that I have lived through an exception to it. I was a narrative designer on the independent ARG The Wall Will Fall, which ended up being one of those cult games. Prior to building this game, only three members of the team had played an ARG; one had built one. That game was pong, and we were aiming for Minecraft.

    I feel like I shouldn’t comment further until I can put into words what it was that made my team’s absurdly overscoped game the non-failure it was. I am in the strange position of not wanting to recommend an experience that, in many ways, was the most rewarding of my professional life.

    There must be a lesson in there somewhere. Let me know if you’d like me to try to coax it out.

    • Chris DeLeon says:

      Congratulations on the success of The Wall Will Fall!

      For what it’s worth – and by all means if you disagree on this point too please feel free to clarify – I don’t see the experience you’re referring to as contradictory to what I’ve aimed to explain. While I recognize that the relation between Pong and Minecraft in your comment is used as an analogy (and if anyone is guilty of leaning on analogies it’s of course me) what I’ve covered here isn’t really intended to apply to ARGs because I know nothing about ARGs.

      The focus of what I do and help others do is the development of videogames with real-time gameplay, usually in continuous simulated space. Furthermore my focus is on a technical gameplay design (rather than, say, narrative construction) for such projects – game designers on other types of games tend to lean on very different skills and traditions than those that I follow. These come primarily from a history of timed button-based reaction to continuous motions, shallow use of themes, and automated “rules” (which work rather differently than rules) that traces through console, PC, arcade, and before that, back to pinball games. I’m of the semi-heretical camp of gameplay designers who believe that the design and development of these things is often not strongly connected to the creation of games more broadly: board/dice games, card games, sports, playground games, parlor games, interactive fiction, tabletop RPGs, ARGs, and so on.

      I’m not at all meaning to imply that any of those kinds are simpler, only different and far outside of my own experience – just apples and oranges, or ballet and sculpture. Even though I’ve spent more than a decade developing tons of real-time videogames, I am far, far less qualified to work on any ARG, interactive fiction, or board game than those of my friends who have spent even a few months (let alone a year or two or more) studying and creating those respective game types. I appreciate that the skills involved are of a different variety, and I honestly don’t mean to claim any understanding of how someone ought to go about mastering those, except to say that I would probably not advise programming Asteroids or building 3D combat levels as a way to prepare for making those other types of experiences.

      It was not my intention in this entry to speak about games as a broad category, but rather to address the specific idea from that tweet. I should perhaps have been more clear in marking my boundaries!

  7. Tom says:

    No worries! I understand that your post was intended to apply specifically to video games. I was the one generalizing your point to apply to ARG’s, because I have heard the same discussion on that side of the fence. I think the logic of your argument applies just fine in the ARG world. The mechanisms are different–we talk about things like geocaching and augmented reality and phone trees, but functionally it is analogous to a room full of blocks in Zelda.

    I’ve been asked by aspiring ARG designers how big they should scope, much like this conversation, and I always advise them to be realistic. That is, they should be more realistic than we were. What I was struggling with in my post is that my advice is to do the opposite of what I did, when what I did was great for my career. I don’t recommend this route because I had to put in two years of unpaid work around the clock, sometimes forgetting to eat, to make it happen. I don’t recommend the lifestyle it requires to build something from nothing… and even with everything we poured into it, we had no guarantee anyone would play.

  8. Collin says:

    I obviously can’t speak for the guy that inspired this post, but I found it quite fascinating and helpful. Thank you for writing it, and I’ll be following up on the links you referenced.

  9. […] read an interesting article on Chris DeLeon’s blog on the value of deliberate practice when learning game development. This makes perfect sense and I agree completely, having read extensively on the subject of […]

  10. Colm says:

    I can see why people bring grandiose ideas to gamedev – you need some inspiring reason to try and build something amazing, something new.

    I try and tell people not to give up on that idea as ‘too big’, but instead to put it off. Do a few gamejams (finish something in a day!), take part in 1GAM as Christer points out above (finish something in a month!). Essentially – get used to finishing.

    Then go back to your big idea.

  11. Robert Boyd says:

    Great article. The only thing I would add is that even with the beginner steps, you can tailor them to your ultimate goal. I wanted to make RPGs so my early projects were text games & miniature NES RPG parodies. :)

  12. Michiel says:

    Great advice and a very well written piece! After many abandoned projects we figured we’d do a “simple” turn based strategy game to actually finish, and even that ran away from us… It’s been three years now since we started on Powargrid, but we’ve come a long way, and we’re definitely gonna finish it this time! And it’s still a heck of a lot of fun :-)

  13. bcell says:

    Perhaps it’s useful to pay attention to the psychological profiles of people having such unrealistically huge goals for their first game. To most that I’ve talked to seem to have hints of some kind of superiority complex, being convinced that they are so much smarter and better than others. In some cases it’s a compensation for feeling inferior in other areas of their lives, sometimes it’s just their young age, and perhaps even the fact that they’ve played too many single-player games where they are always “the superhero” has influenced their view of the world. After 10 years of experience in game development, I look back at my first failed project which took away 3 years of my life and remember starting it with somewhat more realistic goals. However, for all my intelligence I wasn’t able to account for the exponentially increasing complexity of interacting parts within such a huge project. A game with 40k lines of code is 4 times harder to debug and polish than that with 20k lines of code, just as rough example (doesn’t always apply). So even though there are admittedly some truly exceptional people out there, beside their need to be superheros, it’s almost impossible for a single human to visualize the complex system an actual CoD-sized game can become, and all of the intricate interactions in the technical, design and “logistical” points of view. That’s something they have to learn on their own. I sure wish I read this article when I was a noob.

  14. Amro Hasan says:

    you are neglecting a viable new changer to the obvious here. That is the availability of great game engines for indie developers for free or a very little amount of money such as Unity3D, UDK or CryTek. The history you are referencing here did not offer such magnificent games development tools such as these and each gaming studio had to build their own game engine. Add to that the availability of plug-ins for these game engine. So now an indy developer can work on Unity and purchase a worth of $1000 of add-ins varying from Character controllers, Camera controllers, Shaders, Environments and other assets. The output is amazing! if not comparable to AAA projects, but amazing enough to support the claim that a first-person shooter with state of the art output is very possible.

    Do not make it easy for people to fail… You are telling them: “It is OK to fail, you can’t do it!”

    • Chris DeLeon says:

      Nearly 20 years ago I was doing a bit of with modding the Doom, Command & Conquer, Quake, and Descent engines for no more than the cost of the retail game. Moreover the assets required for those games were of considerably lower complexity than the assets required for a decent looking game to be made in a modern 3D engine – even at that much lower content fidelity that route proved too steep a ramp for me trying to get momentum starting out. While it’s true that CryTek, UDK, and Unity3D leapfrog over many formerly imposing technical challenges, they do so at the expense of often opening up enormously more challenging content obligations than what people encounter when finding ways to work cleverly within low-fidelity 2D development environments. I’ve generally found that the people who think they’re going to save themselves a ton of time by using UDK or CryTek are often just as likely as the person I was replying to to find themselves soon stuck, embarrassed, and in too far over their abilities to complete making something worth playing (there are some extraordinary exceptions, but for that matter there are extraordinary exceptions of people starting in all kinds of ways that don’t necessarily make those reliable points of entry for others). Unity admittedly seems a good bit more accessible than UDK or CryTek, and doesn’t suffer from that issue nearly as badly, however it’s still in my belief and experience working with many others a platform often best utilized by intermediate or advanced developers that first developed a solid foundation by learning game design fundamentals in a platform that doesn’t automate or assume by default so much about how the gameplay systems and representation work.

      • Cobus Greyling says:

        With respect Chris, the groundwork for your response to Amro Hasan is founded upon the fact that you were outgunned(if you will) by the “low complexity” engines of C&C, Quake, Doom and Descent.
        This would’ve made perfectly credible sense had you not stated you did this “nearly 20 years ago” – meaning you were no older than about ten years (assuming you are now 30).

        Even if “nearly” means 15 years ago(begging the question why you didn’t just say 15 in the first place), you were still a juvenile 15 years old, not even having finished high school yet. Unless you yourself are the exception that you imply comes along so astonishingly scarcely, how can we believe the rest of your response to hold any validity, being grounded in such a shaky foundation?

        I don’t mean to disrespect you or “take you on” by any means, but this was a flaw I could not help but overlook.

        I am obviously also with Mr Hasan on the whole notion of modern engines creating a large entry point for indie developers(still, limited by money in terms of an asset store(in terms of Unity)), but moreover with him on the point of “Do not make it easy for people to fail…”
        Personally I think this article is more driven towards programming a game(or running a minimally sized team) and should refrain from being too directed at the very wide term of “game developing” in general, since that could be composing music, giving in-house legal counsel, doing artwork, or, programming.

        Everything you said made absolutely perfect sense- with regards to Programming, or tiny teams. Even if you don’t encourage gamers to dream and get their votes back into a world of gaming where the produce is provided almost exclusively by multi-million dollar corporations, it would still be advised to perhaps refrain from sounding too negative to the point where you discourage potential developers be they programmers, mere content designers or even musicians.

        What I’m saying is : just because you have not made several games before, it doesn’t mean much if you are say, a musician, hoping to contribute to the musical sphere of a game. Or an artist, contributing conceptual art. Or a content designer, or Legal counsel, or matters of the Business sphere like Marketing, or Social relations, and the list goes on.

        What I think people should take from this is an obvious lesson: if you are not trained as a lawyer, do not give legal advice. If you have not composed accepted music in the past, do not attempt to sell music. If you are not a skilled programmer, do not write code for games(thus, build it up incrementally in those spheres). But there are a million ways for people to get into game development, and I feel this post does a good job of discouraging anyone who could be a professional in a variety of fields bar programming to participate in the process of making a game.

        • Chris DeLeon says:

          Hi Cobus. Thanks for taking the time to share your thoughts on this.

          There are two points that I intended to make regarding the game engines from 20 years ago, which I must not have done a very good job of explaining clearly, as neither has anything to do with my age then or now:

          (1.) The opportunity to work with commercial-grade engines is not, as was implied in the post that I was replying to, at all a new development in game making history. The major difference I intended to relate between then and now is the extent to which those old game engines required far fewer people, and much less specialized people, to author enough content for, because…

          (2.) When 3D world maps were still authored as tile maps (moving on to overhead 2D vector maps for Doom), when everything got drawn to a 640×480 or even lower for display, high resolution textures couldn’t fit in the available memory or disk space anyway, and when music was still handled as MIDI, content creation was comparatively simpler, faster, and relatively harder to screw up for a nonspecialist.

          The higher fidelity content is, the easier it is for someone to shoot themselves in the foot getting it wrong, and the more room there is for someone that has focused their speciality on doing that one particular aspect exceptionally well. This was the point I hoped to make by emphasizing that even with modern engines, existing franchises, and seemingly formulaic design, games at the fidelity CryTek and Unreal are built for still tend to cost tens of millions of dollars (or in the case of some indie games, cleverly design the whole game around having no animated characters, or only a handful of textures, etc. and those games still take many years to complete).

          For example, when sounds were hardware beeps instead of digital recordings, a sound specialist generally was not needed to create those sounds. This is part of why many very early videogames (say, Atari Adventure) didn’t have or need an artist aside from the developer, then as fidelity improved we progressively saw a distinct need for an artist, then a few artist generalists, leading up to today when on a team of 100+ people there can contain an entire art department in which someone’s speciality is specifically cleaning up 3D character animation from motion capture data to be applied to someone else’s model that someone else rigs and someone else textures.

          That I wasn’t born when Pac-Man was new does not mean that I’m therefore unable to comment intelligibly on how and why animating Pac-Man requires a lesser level of art training than animating Nathan Drake. That I was a teenager when creating new sprites and levels for those old game engines means I have some direct experience with what that fidelity of content involved, however in hindsight maybe it was my mistake to even communicate that I had past experience with what I was talking about, since anyone that has ever made art or levels used in a game can easily make the same deductions without even having worked with those particular games.

          But I think we’re losing sight here of what this was about in the first place: trying to create something with the look and feel of Call of Duty or Uncharted, plus world building and other added features, as a very first game project. I stand by absolutely everything that I said in the entry about why that’s very unlikely to turn out well, or even to struggle coherently enough to be learned from.

          > I feel this post does a good job of discouraging anyone who could be a professional in a variety of fields bar programming to participate in the process of making a game.

          Man, I’m honestly very sorry that this was the message that you took away from this. That was definitely not what I was intended to do.

          My sole focus is on helping more people get into creating videogames. I’ve seen a lot more people find joy and success by figuring out ways to do that first by beginning non-commercially and alone or on small teams. That’s the approach that I encourage because I’ve seen it work for many people. It’s not the only approach, but it’s a reliable one. And it ultimately leads to many other non-programmers having more professional and nonprofessional opportunities to get involved in videogame development, too.

          Many of these people I write for are hobbyists videogame developers (there’s the “HobbyGameDev” bit). When a solo, small team, or simply rushed (due to lacking much spare time to either study, practice, or make progress) developer doesn’t have access to a sound expert, I encourage them to use something like sfxr to create beeps and bloops to fill in for the sound because that’s good enough to let them keep moving forward. I don’t do think that by doing so I’m putting audio professionals out of a job – developers still this inexperienced aren’t likely to create any lucrative gigs for specialist professionals. Instead, it lets them continue improving and getting practice doing systems game design, gameplay coding, and thinking at least enough like a producer to gain experience completing projects they start. After some years of that – or at least in this scenario I’m proposing, in which someone should have experience before being responsible for the time and financial risks of others – a developer is then far better set up to create a quality of gameplay that could be an original commercial game and may be worth hiring an audio professional for.

          I and many other developers have taken precisely that route to creating professional opportunities for artists, musicians, audio specialists, lawyers, business people, and people in other roles.

          It’s also a process that helps create opportunities for many people of different specialities and interests to get involved with making games. Granted, there’s still at least one developer in that process though. An engine does not somehow obsolete the need for competent programmers and systems game designers. But without an experienced developer involved on a project (and all I’m really addressing here, in response to that opening tweet, is one reliable path for that developer to gain practice with applied design and production difficulties), there’s not much otherwise for an isolated 3D rigging specialist to do in terms of making a game. Slapping together a few thousand dollars of Unity Asset Store components isn’t going to fix that problem, it’s probably just going to yield a badly designed mess, for the same reason why we don’t write novels by rearranging paragraphs various strangers wrote. The details matter, a lot, and getting the details right is going to involve someone that’s a developer.

          Moreover: part of the point of what I do and write about is that especially at a hobbyist level, I believe anyone can (and maybe should try) create everything needed for simple games. Just as it’s a level of art that a non-artist can tackle, it’s a level of game design complexity that a non-designer can comfortable work with, and, I believe, in a modern development environment also a level of programming that a non-programmer can figure out well enough to do some interesting things with. Along this process, someone may identify a particular aspect that they enjoy most and do especially well, in which case perhaps they can steer their career that direction going forward. But your impression that I’m excluding people who don’t program is kind of missing that if someone isn’t a programmer it’s because they haven’t programmed yet. Your impression that I’m discouraging anyone from doing anything professionally by simply trying to encourage people to first practice their skills nonprofessionally when safe to do so (I’m addressing hobby game developers here at HobbyGameDev, not surgeons or lawyers) is… something I can’t quite figure out.

          I’m not telling anyone that they shouldn’t do anything, I’m only trying to encourage people to consider preparing themselves accordingly before taking on something massive. I apologize that I didn’t explain well enough the point I was hoping to make here to make a satisfactory case for you.

          However you personally decide to learn and do things, good luck!

          • Cobus Greyling says:

            Hi Chris, thanks for the response. You’ve cleared up a lot of my uncertainty and I apologize that I largely read the wrong messages into what you were saying and did so out of context.

            I misread the entire fact that this article is primarily something to address hobbyist game developers with(in itself implying small teams or solo projects). Which is obvious enough for me not to have an excuse.

            But with regards to discouraging professionals, I did not mean that to imply any profession at all, I meant any gamer who could make use of his profession within the field of game development, like again, Law per se.

            Regards

  15. Great article Chris, indeed; this is sound advice; on the other hand I was never OK with building small games when I started (I wanted the equivalents of Uncharged and CoD).

    It was because of this, I tried and failed at a lot of large projects; but eventually succeeded with an RPG (Morning’s Wrath); that was well beyond the scope of a small team.

    I continue to this day biting off way more than I can chew; just because it seems to be the only way I can really be satisfied.

    So I think it really depends on the kind of person; and if you’re willing to slog through the mud of failure, rather than increment on a tower of smaller games.

    -Raymond

  16. xesf says:

    Really interesting article. Thanks for sharing.

    I can tell for myself that I have experience this before. Starting small,
    not overcomplicating and get simple things done first are important steps
    for learning curve and for keep us motivated to do much.

    While developing Snails Video Game (link on my user) with a work college that
    takes 2 years to accomplish (yeah that long), I was forced to stop due to lack of motivation.
    Back at that time, I’ve make a Asteroids Clone for Playstation Vita just for the accomplishment
    satisfaction, because I couldn’t see the end of Snails.
    Snails project started small, with prototyping, but end-up a huge game for only 2 peoples
    with full-time jobs and wife+kids.

    We both now understand that we should go small first, building up reusable code/engines and gradually
    create what end up of being Snails. I don’t regret on doing it, it was a great project that
    teach me a lot, but I do need something quicker to get me motivating and be able to finish stuffs.

  17. […] Hobby Game Dev states what should be obvious, but often isn’t: don’t run before you can walk, don’t bite off more than you can chew, don’t try to make Call of Duty for your first game. […]

  18. Tamara says:

    Thanks to several articles on your site of which this one and Degamifying were my biggest inspiration I’ve started on a game and am blogging about it. The game will take a few months to develop (not weeks nor years). It’s about my biggest game-interest (monsters). So thanks, for the guidance that finally put me on the right track :)

  19. Luis says:

    If it weren’t for starting and usnterstanding object-oriented languages with Alice, Processing, and then jumping to ActionScript (with a lot of help from Flixel and FlashPunk) Unity would be as hard to use as pure, straight programming to me.

    Although I now use Unity for everything, there’s also a steep learning curve that most beginners seem to miss or (wilfully or not) ignore: designing a game isn’t quite the same as programming it. In fact, correct me if I’m wrong, many design steps still seem to be taken outside the computer. On paper, in a whiteboard, on post-it notes stuck on a corkboard. Starting small also helps you learn the nuances that don’t necessarily involve programming. One thing that helped me in that aspect was finding about Ian Schrieber’s Game Design Concepts online course and the book he wrote with Brenda Romero. http://gamedesignconcepts.wordpress.com/2009/03/31/what-is-game-design-concepts/ Although due to time and work pressures I wasn’t able to finish the course, I did many of the exercises in my own time.

    Still, I got a lot of work ahead (I became seriously interested in this circa 2008, then dropped it for a couple of years out of frustration, and am currently getting back to it), I put out every little thing I learn out there (and get lots of derision to it from, quelle surprise, beginners who want their first game to be a grandiose AAA contender) and try to keep my hopes up through doing stuff. HobbyGameDev is a useful resource for this. Thank you!

  20. […] first article is ‘Reasons for Modest First Projects and Incremental Learning’. It explains why you as a beginner should keep your projects small and not immediately go for your […]

  21. […] involved than I thought it would be. My impression is that this is a fairly common experience (see Chris DeLeon’s post on first projects for more on starting […]

Leave a comment

Comments Form
  • Your email will not be used for any purpose other than to update you in replies to your comments. Your website address will be shown as a link from your name with your comment. Your profile photo is auto-magically provided by Gravatar.

All contents Copyright ©2014 Chris DeLeon.

Site production by Ryan Burrell.