Not your problem

You are a dedicated game developer. You want to create and release an amazing game so that the world will know about it. It is difficult, much more difficult than, say, to write a book. The game is an alchemical mixture of art, personal taste, strict mathematics, logistics and design. Very few can create a game alone, while it’s easy to distract, too easy. Or even worse - do what you do not need . You are satisfied, you learn a lot, you do something, but the game does not get closer to completion, which is the goal. Do not forget about the goal ...

The specialists

Professional problems are not your problems.

Are you following on cool experts like @ID_AA_Carmack , @notch and @grumpygamer ? All of them are great developers of successfully released games.

Have you already released the game? No, right? Then the problems of these guys are not your problems. You have a completely different problem that requires your full attention: the release of the completed game. That's all.
')
Your problem and the problems of specialists partially overlap, but just a little bit . So most of them can be easily dismissed.

Problems of specialists

John Carmack: “I am glad that we finally provided support for C ++ 11 in the Oculus mobile code database. There are lots of places where unique_ptr will help a lot. ”

Oh, oh, oh, and I use GameMaker! I'm not a real programmer, I'll throw the whole project in the trash! We urgently need to order six books on C ++ 11 on Amazon.

Stop it! Using smart pointers is not your problem. To release the game, you need to get rid of pointers from the head. How will you build the game? How to ensure her work on someone else's computer? Entire game studios barely cope with this, and in fact their teams often consist of hundreds of people. This is not your problem.

Professionals have many problems: haters on the Internet, fans ask for innovations, fans ask to leave everything as it is, large teams, bureaucracy that occurs in large teams, special bureaucracy that occurs in large teams of coders (Scrum methodology, attitude to employees as resources, planning for , disputes about unwashed dishes in the sink - in general, the problems of specialists).

The very essence

Here are your concerns in order of importance.

1. Come up with a game you can do and
   • Who would appreciate (and maybe buy!) Someone else.
   • Which you can do in less than a month. Yes it is.
2. Find the finished engine
   • In which already created commercial games.
   • In which you can develop games quickly.
   • Which itself is engaged in the assembly.
   • And if you are already familiar with him, then generally excellent.
3. Finish the game
4. Sell ​​it (or lay out)
5. Advertise it
6. Get reviews
7. GOTO 1

If in the selected engine you cannot create a Pong clone in half a day that other people can play for the first time, it means that the choice was wrong and Gru will eat you.

But the problems that are not yours.

1. Creating an engine in C ++
   • Not
   • Nooooooo
   • Nope
2. Rewriting the library STL C ++ so that it does not take up so much memory
   • * Suppressed sobs *
3. Exploring how to build multi-platform builds
   • Learn make
   • Then cmake (make - for suckers!)
   • Then premake (cmake - garbage)
   • Then Jam (pff, premake!)
   • And so he went down deeper into the darkness of the abyss. We know that we will no longer see his face. He is lost to us. Another child of Adam was lost in darkness.
4. Start writing class Vector
   • Hmm, better to look at SIMD operations.
   • Then matrices, quaternions, hell of OpenGL integration for every taste for the six platforms. Oh, wait, it's better to create a general layer of abstraction to support DirectX. And material for metal. And, we need a high-quality intermediate language for writing shaders!
     • No tears.
     • No pity.
     • No hope.
5. Disputes about any garbage on the Internet
   • X is better than Y
   • Library X is better than Y
   • Platform
   • Programming methodology
   • Do I need to aim for 60 FPS (correct answer: no)
6. Shader programming study
   • Was that your goal? Not? Then ENOUGH. Make the game.
   • Do you need some kind of technique? Well, go on ...
     • ... but with caution.
7. Automated Documentation Systems
   • Doxygen
   • cldoc
   • Bury him
8. Localization
   • Nooooo
   • Nein
   • Non
   • ダ ー
   • Take care of it, like everything else, after the release.
9. Optimization
   • “Games are research programming”
     • You throw this code away
     • It will not matter how quickly he moves at the bottom of the waste basket.
   • You will do it until the code becomes fast, or so slow that you do not want to continue.
10. Writing multi volume dizdokov
    • Or drawing UML diagrams (I will tell you a secret: no one does this.)
    • Development through testing.
      • Not.
11. Creating a level editor
    • Resist the temptation
    • If it is obvious that this will save time, create a MINIMUM editor. Do not think that it will be useful in the future.
    • MFC (Here, you better just get out of your computer, take a hammer and hit yourself on the fingers. It will be less painful.)
    • Qt - Nooooo
    • .NET - nope
    • Simple text files with dynamic reload in the editor
      • Amazing but yes
12. XML
    • Not
    • Writing your own XML parser
      • Which works with namespaces!
        • Not
    • SOAP
      • You've gone so far from game development that you no longer see it.
    • JSON, YAML, MessagePack
      • No no no
13. Boost!
    • Put us both to sleep. There is no turning back. This is the point of no return.

There is nothing wrong with all this, but doing such things you will never let go of the game. After a few years of picking, you will have an excellent samopisny engine, but you will stay on the first cell of the field. Create and release a game.

Tips

How to focus on your problems and develop what is important? Here is what you can try.

改善 - kaizen

Everything Japanese is cool, isn't it? Well, if you think about it, you can find a few exceptions. In general, in Japan there is something that is undoubtedly wonderful - this is Toyota. Yes, people making cars! They, like Henry Ford of two thousand, create many interesting business innovations. And after all, we are always ready to talk about business innovation? True?

Well, it's time to wake up!

Toyota popularized a great kaizen method: continuous improvement. In short, this technique can be described as a world view aimed at constantly searching for areas to improve the development process. Minor improvements, albeit at 1%. No revolutions.

Choose the minimum step that can improve the process and bring you closer to your goal.

When I think of kaizen in the light of game development, I ignore the process and consider this method as a question: “What is the minimum possible action I can have for the game getting closer to the release?” This could be a single level creation or a quick cover of all levels at the first stage of refinement. This may be a list of the desired sounds and sending it to the outsourcer. It is important to always move the development process forward.

New page dizdoka not bring the end of the game, as well as an unsuccessful meeting. The final of a line of the code and megabytes of assets come nearer. Only they move the process. You may need to perform other tasks, but you should always take small steps towards release.

Start small

Will it be your first game? Oh, then problems are waiting for you.

Start small! Really small. Little like pong. Choose the smallest game you can make and go through the whole development process with it. Thanks to these torments, you will receive first-hand wisdom, which is inaccessible to people who have puffed over their first game for years.

Of course, this is only an opinion, but also an objective truth: in all respects you will be a superman compared to these pitiful Mudbloods who did not manage to finish anything. Every day they will sadly hoe the fields, and you will rush past them on your dashing troika. (I myself single-handedly released exactly zero games, so I, too, are the stinker with a hoe, brewing moonshine and dreaming of a world revolution that will bring him freedom.)

Choose what inspires you

A goal that inspires you, but not too big or complex! The X factor for any game is you, with your unique views on the design of games, your attitude, which you can express through the game. Do not be afraid to make your own touches.

The more you are inspired by the project, the easier it will be to finish.

Completion is a skill

This is the main secret, something like a cheat code. The more you complete, the more you can complete. This is not a tautology, but the truth: by doing something, you improve your skills in this.

Completion enhances self-confidence and allows you to be rationally ambitious.

Consume less

Reading 20 articles on game development per day seems like a job. Yes, this is work! But useless, unproductive work: you are marking time.

Spend less time on Gamasutra, TIGSource, r / gamedev / (or where cool guys are still hanging out there today) and spend a little more time working on the project.

Give your inner voice and intuition a little turn around!

Share

Tell about what you do, what you feel, what problems you have, etc. Many developers leading the battle with their projects will find words of support for you. In addition, you will receive feedback, and it will make you better.

Conclusion

Stop reading, get down to business!