Get the latest Education e-news
 
  • Reasons for Modest First Projects and Incremental Learning

    [05.15.14]
    - Chris DeLeon

  • 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 doingexactly 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 practiceand 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).

    A Composer That Hasn't Played

    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.

Comments

comments powered by Disqus

UBM Tech