[jokoon]

I remember being at a private game programming school, there was a school project to make a game with unity 2 or 3. An entire class was using it.

Things were synced using subversion.

I never really jumped in that. I did not continue at that school.

I really think a video game is something that should be made with your custom tools. A good smith makes his own tools. Of course if you want to save time, you can use an expensive, well-made tool, but it will be at the expense of something else.

I'll always remember at that school, quickly arguing with a guy, that in C++ a vector is just a linked list.

Game programming is often highly technical, and often much more complex than what you're expecting it to be. That's why you should not neglect your tools and highly concentrate on making choices that fit your work.

[scott_karana]

> A good smith makes his own tools

The problem is, this can be taken to infinitely far ends.

Editor annoys you? Modify it to your desires. Don't like the compiler? Write your own. Get sick of the programming language? Invent your own. Get annoyed with how the OS does something? Change it or invent your own. Bump up into x86's limitations? Start on custom FPGAs.

Ten years later, you might still have 0% completion on your videogame, and indetermine completion on your ever-fractaling toolchain. (And this isn't just a thought exercise; I remember a HN submission earlier this year that was nigh-identical to what I describe)

I would rephrase what you said as "A good smith knows his tools and their limitations, and knows when it's appropriate to make his own tools". Even when talking in analogy... a smith's apprentice would not presume to make his own tools before experiencing his master's, and even further I suspect most smiths did NOT make their own anvils, or mine their own steel... ;)

There's also a healthy serving of "Worse is better" in this line of argument.

[jokoon]

Yes it's true, but I would not take the smith tools argument that far.

You could say there's a spectrum of low level/high level tools you will either work with or build yourself.

Most low level tools are now quite good enough. The more you go high level, the more will deal with specific cases that will restrain your ability to do thing the way you intended. Like the article said, Unity will fit for very small teams and very simple games, but it will be hard to do anything really complex.

I think compilers, languages and engines are better suited for more use cases than an editor like unity is. It's a dilemma of flexibility versus speed and ease of development.

ease of development/flexibility:

ease<|--#-------------------------|>flexibility

ease<|-----#----------------------|>flexibility

ease<|----------#-----------------|>flexibility

ease<|--------------#-------------|>flexibility

ease<|------------------#---------|>flexibility

ease<|----------------------#-----|>flexibility

ease<|-------------------------#--|>flexibility