Just finished new fighter model.

This is a bit controversial topic. As a general rule we should create full documentation before we start development. This helps in many ways. Helps us to structure whole project and avoid many pit holes. We may think about many problems we may encounter and avoid them before we write single line of code. Writing documentation gives us a full vision about what exactly we want to create and this can not be overrated.

But what if we are not sure if what we want to create will be any good. I’m not talking here about quality of software, but rather about its essence. We want to create a game, that has not been done before, and as such it may sound fun on paper, but will not be as fun in real life. So how to approach this?

What I have decided to do is write skeleton application with full functionality but limited content and without fixing bugs that are not major. This way I can push development quite fast, and see if what I have in mind is something I would like to play.

As this is not a first project I have worked on, professional and private, I know how big role good documentation can have. In large projects it tells development team what they should be doing. Every member can focus on small part without knowing whole projects, by just reading documentation of portion he has to do. In private projects it keeps project on track. When you start writing a creative project like game, you have lot of different ideas. If you have them at start, when nothing has yet been done it is great. When you have them in middle of project and they require throwing away 2 months of work, because vision changed it is not that great. It may have worked for Disney’s Frozen, but in small project you don’t have money to throw away on another “I have a great, beyond great idea”. This is where documentation comes in. You have to write documentation before writing code, and once you document your idea for a product, game in this example, you have to stick to it. It is very tempting to implement your great idea, but in reality, until project is finished you have nothing but ideas. Finished product without your great idea is better than a stack of great ideas.

Now, this comes to my project. What I implement is always documented first. I can find some logic problems and fix ten beforehand which saves me time. Gives me documentation for what I have created for future reference, which I have already used just to refresh how some part works. If I change something in code, I allays update documentation first. I have written complete overview of my game, so that I won’t stray, but I have not written all details. I think, that right now I want to test if my general idea of how gameplay should look, will in the end create fun and engaging game. For that, I don’t have to have full documentation of races, and even campaign. If gameplay is weak, great campaign won’t help that much.

There is one more reason, why I don’t create full documentation at start. I have lot’s of experience with business applications, but I have little with game development. I am learning a lot, but it is still not enough to create good full technical documentation. I have never finished a project using Unity and there are many things and limitations I may be not aware of. Creating skeleton application should allow me to find most of them, and at that point most of technical document will be already written.

Someone told me, I should just create mockup and don’t try to create working prototype. Write something that would show, how game will work and look. I could have done it this way, but if I want to write this game I have to learn. I won’t learn unless I try to make best I can and to try to grow as my project grows.