Here's why I stopped teaching Unity first.
My confession as a teacher who loved how easy it made (the wrong) things.
Dear Future Game Developer,
Tools like Unity and Unreal are fast, powerful, and convenient. They make it easy – essentially automatic! – to...
• Release on a variety of devices and digital shops.
• Incorporate animated graphics into your games.
• Show off modern effects for lighting, cameras, and particles.
• Re-use chunks of well-designed code.
• Add to your game from a huge store of parts.
• Render high-poly models and high-res images.
• Use realistic physics-based collisions.
Despite those advantages I've witnessed too many new developers shortcut to these tools only to then struggle. Their games feel broken to play.
The gameplay even works as intended: when A hits B such and such happens. Jump button jumps. But there's something missing. Something smells.
These are smart, determined, passionate people working with one of the best tools in history. So what's with their awful, unfinishable pile of half-games? The problem is in what they can't see.
I'll elaborate. Here's why I recommend you use an engine like Unity second.
But first, an important disclaimer, lest I give anyone the wrong idea:
I'm not anti-Unity. I've used it. And taught it. A lot.
I've taught Unity in multiple university courses. I've led and been on dozens of teams that finished games with it. I've founded two clubs that together create a handful of new Unity games every year. I wrote a positive review of Unity for the Tools section in Game Developer Magazine. Tens of thousands of strangers got their start with Unity from introductory videos I made.
I've even used Unity (and Unreal, too) as a professional game developer.
I am a Unity advocate. I don't oppose Unity. I oppose starting with Unity.
As a private game development trainer over the past year I've helped dozens of people make their first games. In all but one very unusual case – he's a senior professional programmer – people who skipped to Unity for their first game programming eventually put it on hold to return to code-only fundamentals.
You probably should use Unity. It's amazing and I love it. Just don't use it first.
Here's what people pushing Unity as Step 1 aren't saying:(Including me in 2012, back before I knew any better. Sorry y'all.)
Remember that list of bullets I opened with about the incredible things Unity and Unreal make easy or automatic for you? Fancy lighting, tons of devices supported, animated high quality models and such?
Here's the problem: none of those are useful in the hands of a beginner.
Here's the bigger problem: those distract from what's useful to a beginner.
Here's the biggest problem: Unity and Unreal hide and overcomplicate and try to completely handle for you exactly what a beginner needs to learn.
It's kind of like putting a graphing calculator in the hands of someone taking intro math, and thinking that means they can simply skip learning how to do all the basics on paper. We all know that isn't how it works. To leverage the power of technology it helps tremendously to first gain a solid understanding of what it's doing for you.
These tools are really designed and intended for intermediate and advanced developers who already know those concepts from games that they've programmed before using Unity.
Beginners benefit from knowing about how to code core input, space, angles, motion, and collision. That's tough to learn inside an engine that automatically tries to handle your input, space, angles, motion, and collision.
Instead of learning to make these things you learn to ask Unity to do things for you, unsure how to do things your own way.
Most developers reaping the benefits of these engines have programmed code-only games. They know what the engine does for them. They know how to override it to set their games apart. This gives them a huge advantage over developers who can't see it.
Tools and engines save you time by making tons of assumptions. Without an understanding of those assumptions you're left with a default, bland, generic feel and world. Code-only practice first, without engines, helps a lot.
1,000 people every month begin this way instead...
Start ridiculously simple, start completely (truely!) in 2D, and start classic.
"But Chris," I hear, "why not use Unity or Unreal to make simple 2D games?"
Unity and Unreal were purely 3D tools for over 8 years before adding 2D support. Their 2D is in many ways more complicated to use properly than their 3D capabilities. Even then they're still hiding a ton of huge assumptions in how your game works – assumptions you want to know how to override when doing so will make your game look and feel different.
There's actually a really easy, straightforward way to:
✅ ...Finish a project tonight.
✅ ...Practice in a progression.
✅ ...Know every line of code.
✅ ...Follow a clear recipe.
✅ ...Make all your own art.
✅ ...Learn the fundamentals.
✅ ...Avoid tool assumptions.
And just what exactly did I mean by "start classic," anyway?
Learn the basics by being unoriginal!
I know, I know, that's a dirty word. Among gamers and developers clones are seen as The Man's creatively bankrupt sin against underappreciated artists.
I agree! I was a victim of cloning in the marketplace when a knockoff outperformed my innovative entertainment app. Mine was the result of 219 days of daily prototyping. Theirs was the result of seeing mine in the charts.
I'm not endorsing unoriginal as a business strategy. I'm recommending it as a learning strategy. Why? Because it's how you learned everything you know.
When you were new to math, you were solving problems many other people solved. Nobody learns math by first spending 3 years stuck on an equation no one has ever done before. That's what math Ph.D.'s do, not how beginners start.
If you learn to play piano or guitar, you first learn to play unoriginal songs. Beginners learn how to play it exactly. With experience comes skill to riff.
People new to cooking follow recipes. Closely, at first. Master chefs deviate.
You begin small and unoriginal, but with each new project you ratchet up the size and how much of your own style you mix in.
If you don't yet know how to write code, historical practice projects are simple enough that you can pick up most of it as you go. If you already know how to program but never tried coding games, you'll tear through these projects even faster, seeing that with little guidance you're ready to make games.
Speaking of the (initial total lack of) coding complexity:
Keep your mistakes in your code at first.
Many errors in Unity or Unreal happen from incorrect drag-and-drops, checkboxes in hidden tabs, or misunderstanding the engine's complex built-in features. When a new developer can't tell whether an issue is in the code or hundreds of widgets it's a nightmare to fix. If you're confident in your code it's easier to trace errors.
When you begin by programming 100% of your game as code you get total control. Errors that happen must be someplace in your typing, never in the tool's options. You fully understand what's going on because the only things happening are what you make happen, and exactly as you make everything happen.
And, importantly: without any libraries, add-ons, or engines. Those are all trying to do too much for you, too. It helps to learn the basics by working, at least at first, with just the graphics canvas and your code.
With HTML5 there's no complex environment to set up so you can start tonight, basically now. You can code and run your games with what's already on your computer: a text editor and a web browser. Because HTML5 is browser-based your code and games are automatically cross-platform.
You won't need permission or approval process hold up from Apple, Nintendo, Sony, a crowd of KickStarter backers, the bank loan agent, or the gate guardians of Steam Greenlight (which, for your first practice projects, fighting those barriers isn't worth the hassle anyway) to create and share whatever, whenever, with whoever.
Here is how I started. Except better, easier, updated and tested.
When I began learning this way – I started back before shortcutting to Unity was even a consideration – I heard that same kind of advice from more experienced developers: remake classic genres first as practice. Even knowing that's exactly what I needed to do, I still had to struggle to stitch together scraps to create my own steps out of dozens of books, forums, and fragments of examples from incompatible sources.
To help my private training clients I updated and streamlined the journey I followed. I adjusted every project in the sequence to focus on practicing specific skills, modernized it for a newer development platform, and turned it into a digital textbook (500+ pages on six genres) that I use to teach this material.
Now I've taken it further, capturing my private training approach into hours of instructional video. A textbook simply works so much better when it's taught by a teacher (it may work even better, still, when the teacher's the one who wrote it). The approach is now straightforward, affordable, and available to anyone.
The video course recreates exactly what I've been doing in one-on-one private instruction over Skype to start most of my clients. (Some of whom moved on to using Unity to create more original and ambitious 3D games. Others also moved on to grander projects but chose to stay with HTML5 for now. Fortunately HTML5 is a modern platform, too, legit in its own right.)
It's a strong foundation, and a launching point for you to gain comfort with gameplay code. It opens doors to begin making many more advanced kinds of games. It trains you in a process to learn easily in a natural progression.
If you choose to tackle Unity or Unreal next there'll be less magic in what they're doing for you, so you can step in and redo things your way when your game would benefit from doing so.
This material used to be 1-2 months of weekly training, 4-8 hours or more of private instruction. Now that it's recorded (well, not just recorded, but completely adapted for video) I can offer it at a fraction of my rate.