“It is possible to become world-class in just about anything in six months or less. Armed with the right framework, you can seemingly perform miracles, whether with Spanish, swimming, or anything in between.” - Timothy Ferriss
What’s the most efficient way to learn game development?
How can I make my designs concrete?
Well, game dev definitely has something to do with coding, my younger self concluded.
So I, a non-coder, set out to learn coding.
And I got it—kinda. Enough to know some basic syntax stuff. It’d be the equivalent of knowing all your high school French vocab, buuuuuttt…not knowing how to string a sentence together.
It’s a weird plateau—where do you go from there? Any student who has studied a foreign language (and any programming language you pick up is just that, a foreign language) has faced this problem. They know enough to be dangerous, but not enough to communicate what they want to communicate.
So I recently cracked open Timothy Ferriss’ Four-Hour Chef, and, yes, it’s going to help us learn coding. It’s designed to help you learn anything—as efficiently and effectively as possible.
Without getting lost in the weeds, I’ll just bring out the most important concept from Ferriss’ book (though I highly recommend you check it out—it’s packed with meta-learning tips and practical know-how; everything from braising steak to memorizing Japanese kanji to building a fire with a bow drill).
But Ferriss boiled his master plan for how-to-learn-anything into two succinct acronyms: DiSSS and CaFE.
So below you’ll find out what those letters stand for, and I’ll attempt to answer them with a bent towards game development.
I’ll write another blog post on how I came to the decision to learn C# for game programming, but most of what you’ll see below is language-agnostic.
Our real question here is: how can we get a programming language to deliver our game design ideas?
DiSSS (Deconstruction, Selection, Sequencing, Stakes)
Q. “De-construct what you’re learning. What are the minimal learnable units, the LEGO blocks, you should be starting with?”
A. I’m going to answer this question broadly. What broadly applies to any game engine, programming language, or video game genre. And I’ve boiled it down to this:
For any programming language: Strings, Variables, Methods, Conditionals, Loops, Operators, Assignment, Arrays, Passing Arguments, Objects, Classes, Recursion
For the basic architecture of a game: Game Loop (Input processing, updating the game world, outputs), Delta Time, Game Objects (Draw, Update, Draw+Update)
What the pros are trying to get better at: Algorithms, Git
Q. “Which 20% of the blocks should you focus on for 80% or more of the outcome you want?”
A. The question is referring to the Pareto Principle: "80% of effects come from 20% of causes and 80% of results come from 20% of effort."
Suffice it to say, I really puzzled over the answer to this question. It seems like the pieces of code you should understand vary by project. Coding is more like writing or painting than it is like weigh lifting, cooking, or tango: coding is very creative, and there are multiple solutions to similar problems.
So I decided to go about it like C# really is a foreign language (which, as we established before, it technically is).
In Ferriss’ book, he has a little section on learning foreign languages quickly: learn the most frequently used words and learn those FIRST.
So I create a very incomplete graphic that goes over the basic idea of game architecture (how games are set up), and some of the more specific C# concepts that would be useful to know (outside of what basic tutorials normally cover, such as what a string, variable, and array are).
Yes, yes, the shapes mean nothing, the colors are arbitrary, there's a lot missing, it's far from a complete cheat sheet.
BUT--it does give us a jumping off point, with an overall glimpse at how games are organized (before they start looking like Rosetta Stones of incomprehensible text), and gives us a road map for concepts we should study, rather than going by the very vague: "master C# programming and game architecture."
Q. “In what order should I learn the blocks?”
A. In all my Quora spelunking for this blog post, I actually came across a perfect guide—you’ll see me follow it here on site. So let’s all thank Al Nelson in advance:
Al Nelson's advice is like a warm-up for game engines (Unity, Unreal, MonoGame), which I love. We're going back to the basics and working, not on tutorials, but on prototypes. I'll be going through this road map over the next few blogs. Our 'little adventure game' will be created in Twine, as I work on a little project you may have seen listed under My Work: "Imbue."
After that, we can go over those algorithms and key words in depth.
Q. “How do I set up stakes to create real consequences and guarantee I follow the program?”
A. This blog is my stake. It’s got my name on it. I paid for the domain. I’m going to publish underneath this thing. That’s quite a bit of weight! You might consider something similar.
BUT…if things should slide way off track, Ferriss recommends betting a bunch of money on you failing, so you’re motivated, at the very least, to not lose the $500 you promised to shell out if you failed your goal. Aversion psychology.
CaFE (Compression, Frequency, Encoding)
Q. “Can I encapsulate the most important 20% into an easily graspable one-pager?”
A. Why, yes I can (try). See the above infographics above.
Q. “How frequently should I practice? Can I cram, and what should my schedule look like? What growing pains can I predict? What is the minimum effective dose (MED) for volume?”
A. I read recently in Josh Kemp's "No Degree? No Problem!: How To Become A Software Developer in 8 Months" that the sweet spot is around 3-4 hours per day for 6-8 months. And no, blogging doesn't count. Regardless, we'll keep track of the results here on this site. Of course we're going for game developer rather than software engineer/developer, but the basic overlap is learning a programming language and turning out prototypes.
MED: 3-4 hours a day.
Growing Pains: Gotta resist chasing multiple rainbows.
Q. “How do I anchor the new material to what I already know for rapid recall? (Acronyms like DiSSS and CaFE are examples of encoding).”
A. Weekly updates here on the blog, summarizing what I’ve learned, with occasional tutorials.
And that's all she wrote. Next time we'll start looking at some actual code (and eventually we'll put this blog on a schedule, but let's just take Al Nelson's advice and go one step at a time).
Thanks for tuning in!
In Excelsis Deo.
K.W. writes novels, short stories, the occasional ode, game scripts, and (with actual evidence!), this here blog.