Monday, December 2, 2013

Notch, WebGL, Dart, and ramping up quickly

Just a little something I thought was worth pointing out. @notch, the creator of Minecraft, has been posting updates on his latest toy project to his Twitter account recently. I've found this very interesting because he's doing a WebGL app in Dart, which just makes me all sorts of happy. Ignoring that, however his tweets illustrate something that I feel is very important.

This was a week ago:
We've all been there, right? "I got SOMETHING on screen! YAY!" But then...
Two days later and he's gone from "Triangle on the screen" to "Blocky environment, mocked up UI, and text rendering".
Some hangups on the math, and now there's basic collision detection!
And sprites.
And then, hey, let's swap out the entire lighting system on a whim! Why not!

So, to recap, in the space of a week Notch went from rendering one triangle to being able to walk around a deferred lit environment. In a language that he's only just started with, no less!

Now, I'd love to claim that using Dart and WebGL has something to do with being able to iterate so quickly, but in all honesty it's going to be far more accurate to chalk that up to Notch being an experienced and skilled developer. (I do believe the web, by it's very nature, allows for fast development iteration. But that's a different story.)

No, the real reason I point all this out is not to promote any particular tool/language/API but to discourage something that I see time and time again: Over-Architecting.

I can't tell you how many time I see hobby developers saying "I'm building a game!" and what they actually have to show for it is a really complicated system for loading meshes and shaders. It's all well and good to think about long term goals and engine structure and such, but if you're going to build a game then please build a freaking game! Don't build an engine that you will someday build a game on top of, because you will never get past step one.

(And, for the record, I'm just as guilty of this as anyone!)

Now, I haven't seen one line of Notch's code. I have no idea if it's well structured or spaghetti. I would make an educated guess and say that there's a lot of the basics in this project that have been ported over from the Minecraft or 0x10c code. The point is that regardless of the coding styles at play this is a project that went from nothing to basic world interaction in a week, which is a great jumping off point for experimenting with actual gameplay.

That's awesome, and I kind of feel like that's the sort of velocity that you should strive for when you set out to "build a game." Establish a goal of some point of basic, minimal usability and do whatever it takes to hit that point first. Then iterate the crap out of it!


Well, this post seems to have become fairly popular. I'm worried that people are taking away a message other than I intended, so let me clarify:

By no means am I encouraging bad coding practices, nor am I implying that Notch is trading speedy development for clean code. It's perfectly possible to do both, it just takes experience. I am trying to discourage people from building out a bunch of infrastructure that they don't actually need. This is both a personal bad habit and one that I see echoed in many forums, blogs, and tweets across the web. Worrying about making sure your shader system efficiently handles every imaginable effect before you have any meaningful game interaction is probably putting the cart before the horse. Unless, of course, you are actually trying to build a "game engine". Then by all means, design away! But at that point you shouldn't delude yourself into thinking that you'll end up with a game on the other side.

(And of course none of this applies to professional game studios. We're talking about garage developers here. The rules change entirely when you have a building full of employees and a few million in funding at your disposal.)

If you are a beginner and just want to build a game, I strongly suggest looking into Unity or something similar, as they've done all of the hard architectural stuff for you and you can focus on the game mechanics instead.


  1. Wow, that's really impressive. Almost every time I start developing a game, I have to fight the urge to make an engine / set of tools to make a game.

  2. Making a game with Dart and don't want to start from scratch? May I recommend some of these resources:

  3. I believe this to be terrible advice. Just because Notch can create a game in a few days doesn't mean you should throw good coding practices out the window. I recommend to find a balance between features and architecture. When you work too much in the "now" you lose sense of abstractions and code reuse. Bottom line is if you intend to work on your project for a long time (a few months or a year) take the time to design your code properly. This doesn't mean write your own game framework from scratch but it does mean taking the time to find the write places to write code so you can reuse the same concepts in the future.

    1. "Just because Notch can create a game in a few days doesn't mean you should throw good coding practices out the window."

      That would, indeed, be terrible advice, and I'm glad that's not what I said. :) I could have probably expanded on the idea a bit more clearly though.

      I'm not suggesting that developers should try to imitate Notch on any particular thing, including timelines. The fact is that plowing through a project that fast is a product of experience, and not a matter of being sloppy. (Notch himself said that with the exception of one file he felt the code for this project was pretty clean.) The fact that I used his tweets was a simple matter of it being a timely example of the point I was trying to make.

      That point, ultimately, is that you should be working towards something concrete and not spending a lot of time architecting super abstract interfaces for functionality that you might need one day but don't have any clear use for right now. There is, as you said, a balance to be found between tossing design to the wind (bad) and spending all of your time drawing diagrams on whiteboards without producing anything of value (also bad, and what I happen to struggle with more.)

      This post was more self-motivational than anything else, and I'm sorry if I muddled the message somehow.

  4. Speaking to my soul, buddy. Good article. :-)

    Just yesterday I started looking at Unity, this pretty much drives the point home, eh?

  5. "is probably putting the horse before the cart"

    hmm, isn't that what you normally want?

  6. Notch has spent the last 48hrs developing his Ludum Dare 48 game "Last Minute Christmas Chopping" using WebGL and Dart. Watching his stream was very impressive

  7. Let me play devil's advocate just for fun. Here's a stereotypical timeline at a large studio

    1. Dev makes prototype from scratch
    2. Producer thinks it's awesome. Looks far along. Production starts immediately
    3. Game is 9 months late because there's no tools for the rest of the team to use.

    The problem with starting from scratch is it ignores that in many games there's a shit ton of little things that need to be there in order to ship. Starting from scratch throws away all that work that's been previously done. 3d exporters are hard, animation libraries (good ones) are hard. Level editors are hard. Networking libraries are hard. Online game hubs are hard. Localization is hard. By hard I mean it takes months to get them right. I could list probably 3-30 man years of stuff depending on the game.

    Now of course if you don't need that stuff great but most games do need a large subset. Font libs/tools, localization libs/tools, game state save/load libs, cross platform graphics libs, cross platform audio libs, etc etc.

    That's not to say you should start writing that stuff before writing your game. Rather it's to say that more often than not you should use an existing system (Unity for example) and save yourself man years of work.

    The problem is whatever system you choose often has a learning curve itself and that learning curve is enough that most programmers want to go directly to what they know (ie, start from scratch). But, I'd argue that learning curve is orders of magnitude smaller than the man years of other stuff you sign up for by starting from scratch.

  8. Great post. We are tempted to build that 'awesome reusable game engine' and then crank a new game every month with the fruits of our labours. I am one of those 'I'm building a game guys' and I am focusing on the game.