Not so long ago, I stumbled upon a speech given by Jonathan Blow at UC Berkeley CSUA. Jonathan is best-known for his game Braid. The speech is so unusual, interesting and full of useful advices for an indie game developer so I decided to make a synopsis of the speech.
Being a professional game developer for 16 years, Jonathan has developed a programming aesthetics. The aesthetics is different from the one which we learn during our studying. Below I outlined the main points of the aesthetics.
You should be extremely effective at getting things done, because the gaming industry is a time consuming field. Jonathan had been developing his game “Braid” for 3 years. There are about 90 000 lines of code in the game. Despite of the fact that number of lines of code is pretty useless metric, it is still quite tangible metric to help us to understand the work that had been done.
There are statistics that tell us that an average developer writes 3250 lines of code per year. Probably, these statistics are from the industry where people are not very productive, but we will use it anyway. Let’s calculate how long it will take to write 90000 lines of code.
So, if you need to write 90000 lines, it will take 28 years. Obviously it is not good. You can try to be a twice more productive but you have to be 10 times more productive to achieve your goal.
You could speed up development by producing less-quality code, but there is a limit about how bad the code could be. There are certification processes for different platforms and those processes prevent the ability of code to be very bad.
Moreover, you should be extremely effective at getting things done, because as an independent game developer you need to do not only coding, but such things as:
- Game design
- Level design
- Art direction
- Audio direction
- Business development
- Marketing / PR
- Financial management
You need to improve yourself continuously. There is a stereotype that you can learn programming or some technologies and after that you can settle down and stop learning new stuff. If you think so, you are wrong. In the reality you need to improve your processes, the way you work and learn new techniques because everything is developing and you need to be up-to-date.
As the matter of the fact that you should be extremely effective and simultaneously learn new techniques to improve yourself, you need to be careful about these techniques. The general observation that Jonathan has about human nature that it’s easy to see benefits of an idea developed for benefit’s sake. At the same time it is very hard to measure subtle negatives chained to this idea (which often outweigh the benefits). With the methodologies and other there are negatives that are difficult to see.
One of the things you should be careful about is the code optimization. Impulses to optimize code are usually premature. It looks like people come to this industry with the idea that they can optimize code. Like “I can optimize code and make really good code”. Usually code optimization is lot more difficult than they could have thought.
Optimization is often about starting with an assumption that particular code change can give particular improvements. Those kinds of assumptions are changing over time and your optimization may become pessimization, when it ends up being slower, as well as being buggy, hard to maintain, etc.
Another reason why optimization is bad is that most part of code is not performance-sensitive. It's about 6000 lines of a code are performance-sensitive out of 90 000. Remember that you have to be effective to write these 90000 lines of code and don’t waste most of your time making the code worse. If you want to optimize something, it's probably wrong.
Be careful about data structures because data structures are premature optimization. This refers to non-trivial data structures. Using the right data structure to store data efficiently in particular situation you are currently working on, may be a waste of time. The situation can be changed over time, so the optimization may become useless.
Be careful about complicated algorithms. Almost all applied computer science research papers are not good for your purpose. These algorithms require more effort to implement. Moreover, they propose adding a lot of complexity for a very marginal benefit. Pay off usually is about 10% - nobody cares about it. If you got an impulse to use a complicated algorithm, it is probably a bad idea.
You also should be careful about writing a sort of generalized systems solving a wide range of different problems. There are situations when you need to write a specific system to solve a problem. Many programmers think that it is pretty much better to write a generalized system. The generalized system supposed to handle a wider range of different states because programmers think that they probably will use that functionality later. Actually the generalized system is worse than specific one, because you probably don't need this additional functionality. You spend time implementing things you don't need. Generalized systems also are less self-documented than specific systems. Being a good programmer involves keeping as much as possible larger structure in your head at once and the relations between everything. So you see exactly what a particular entity is doing and what its role in the bigger structure. So you see this structure very clearly. If you look at generalized system you don't know what role it plays. It's less specific.
Be careful about adding new systems. This should only ever be a last resort. There are connections between systems and you know that one system calls another system and if there is more than one connection, then complexity of program grows superliner. Every time you add a new system you add a superliner complexity to your program as a whole. Deleting code is always better than adding code. If you add systems, make it as few as possible; make it talk to few systems as possible.
In the end you should be a good indie game developer. As a good indie game developer you should be able to get things done quickly and robustly. You should make things simple. You should have a broad knowledge of advanced ideas and techniques but you shouldn't be too eager to use technology you learned and apply it everywhere. If you want to use the advanced algorithm or advanced data structure, use them only when it is genuinely helpful and when it benefits a project as a whole. And that is hard. It's harder than being smart. It requires experience at some degree. Remember your mistakes even if these mistakes are hard to admit to yourself.
No comments:
Post a Comment