Programming differences between two hours and four weeks

This article is translated from the simplicity Oriented Programming article.

I found an interesting phenomenon during my years at warsztat, a Polish game development organization. We often organize some programming competitions, which are usually divided into two forms. One is personal action, generally only two hours, and the other is long (several days/week ). As an additional requirement, the former generally only allows the use of basic APIs (SDL, OpenGL, etc.), while the latter generally does not have restrictions (various engines can be used, udk/unity, etc ).

The results were a little surprising. Many people prefer to participate in short competitions. However, no matter whether the game was developed within two hours or within four weeks, the excellent parts of the game are horizontally the same. Why?

1. The four-week development period does not mean that the development time is 672 or 224 hours. In some extreme cases, the four-week competition is the same as the two-hour competition, that is, the last two hours of the four weeks are working.
2. Many games are actually creative. In fact, the idea you have come up with in four weeks may not be better than that you have come up with in ten minutes.
3. The development process of the two-hour competition is under great pressure. Most of the time is used to improve core functions (because there is no other ).
4. On the other hand, in the long-period Competition Project, people initially only focus on some irrelevant functions. Once you begin to think about adding an interface component, making it a built-in MP3 player, or making the interface colorful, your project will start to fail.

This is perhaps the most important lesson we have learned. If you need to finish something quickly, the Code may be poorly written, but it may be very short, concise, and flexible. If there is no time constraint, the complexity of the program, the functional items and the defect rate will be a level. The workload for future maintenance is not reflected in.

In four weeks of programming, you can perform fast iterative programming several times, each of which improves the core functions of the game. However, if you take some unknown feature functions into account at the beginning, writing this feature and modifying bugs will take most of the time. It is true that you can write a large number of assets tests over the past four weeks, but is the core game entertainment design good enough?

Finally, I would like to give you an absolutely valuable C (++) Advice: when new features are added, start with the smallest core features:

1. Global functions-if you need to display scores, do not hesitate to write void displayscore () immediately (). If your game is played by a single player, save the score as a global variable. Let's see, you have saved at least 10 minutes to write getter, setter, and the communication time designed for the module. You do not need to do this. If the game is played by multiple people, you need to record and display scores for each person. However, if your game is not played by many people, you have no reason to display any scores of any people. Believe me, you will encounter more complicated problems than displaying scores.
2. If your functions require shared code or helper functions, organize them together, preferably in a separate file. Always think about static functions and variables-in contrast to the static state of "oo", the static state of the file is visible. This is good because you can put all the operations related to fonts in one file and put all internal data in static global variables. Helper functions can be made static and open to the outside through shared headers (if you write simple code, organizing work will never take you too much time ).
3. The function is promoted to a class only when necessary. Remember, classes mean objects, objects mean the relationships, and mutual relationships mean the complexity. Is your game design so cool as to leave a lot of time to process code?
4. Only when the above is not good enough, design patterns or other novel things can become your target for help. Never go to this step.