Make your game easy? Or why dreams often remain dreams
Of course, I will tell you just a few platitudes that I would never have believed myself at the beginning of my journey. And the path is not big and not very successful. Just a little hobby, but after which the view becomes clear, allowing you to say which project has a chance of success, and which obviously fails. Of course, my path is one of those, and now I regret only the time I lost, and my reader can only be wondering what mistakes I made in my time.
Do not do it this way
Ambitions, ambitions and once again ambitions - this is what prevents us from working within the indie team ... don't you believe, or do you think this is purely a subjective experience? Well, see if the series Halt and Catch Fire. But ambitions - this is half the trouble - laziness and not professionalism, complete their work.
Alas, until you have done nothing - it's about you, not about those you are trying to find. Yes, and you will find the same)
')
You must clearly understand that the two ambitious people in the team will already be crowded and you will spend more time talking than developing. This does not mean that you should not discuss the project - the point is how you do it.
Before looking for a team - you should have an idea of the game, what you want to do. It consists of the name of the game, the genre, and the gameplay cycle. And it should be on paper. If you don’t have a name, you think it will appear later - everything would be fine, but you probably don’t understand the game. I will never contact such a project - it is a waste of time. Not understanding the genre leads to the fact that you want to shove everything into the game and it lends itself to that sauce, which will be interesting. The gameplay cycle is one of the useful game design terms - study and come up with, without options. And of course, no dizdokov - at this stage you still can not have it. Now you have a vague idea what you want (it may seem clear to you - but it’s better to understand that this is not so).
We start talking with the team. It is no secret that 95% are looking for partners on enthusiasm and deleted. Never speak in a voice with candidates for partners - time wasted for chatter. And to begin with, find out with whom you are dealing, understanding that it would matter if he had an interest - this is again your time spent.
Adequacy is the most important criterion of the first negotiations - never decide for others, do not tell them what to do, do not set deadlines. Such people will very quickly be considered directors and, depending on their professionalism, the teams will tolerate more or less.
Interested people themselves will do and write will show you what happened. Give people the opportunity to have an opinion, do not raise the tone of the conversation in case of disagreement. You will understand quickly or a person argues because of a dispute or he himself undertakes to do what he suggests. Make it a rule that you can not do - not you and decide how to. As a result, work with those who actually do something. But a lot depends on the role in the team.
This is a very academic approach, that a game designer comes up with a game, a programmer encodes, an artist paints. It all depends on the professional person in the business.
Ideally, the work of the game designer ends where the work of the programmer and the artist begins. If a game designer with superior experience than a programmer or artist (which probably happens only in fairy tales, but still), only then can he distribute the work, set tasks for them, or more precisely describe what a programmer or artist needs to do. Find such a game designer who does not suffer from such ambitions, and can work in the set conditions. His task is to detail the idea, not to change it.
As for the artist / 3d modeler, then if this is your first game - you don’t need it at all, use ready-made models, which are now enough or even make a prototype on the squares, a gray prototype. Instead, you'll need a level designer.
As for programmers, the main criterion is to find those who are not ill with writing, can work with any other code, and use it as parts in their development.
You can talk a lot about teams, sometimes it seems that she pulls you down or out, and you want to go deep. But give the team a chance to work with you. It has never happened before that work with professionals was in vain, try to evaluate their vision. If you decide something, do not argue - walk a week and explore other options. If, when discussing options, you see that your opponent does not make compromises, can you work with non-professionals? Do you need it? But in any case, fix everything you do, version control and backups at least once a week.
If this is your first project, or you have not worked in a team with staff turnover, cursing, but do not understand how this is done in reality, and not on paper - then in 99% you will have a turnover with a vague vision of the project. There can be no other way.
The enthusiasm disappears, but this is how a person works, he can get carried away with something else and start doing another project. This, by the way, is the second reason for staff turnover, the first one, if not generalized adequacy - mentioned above. That is why if you do not fix the documents, do not make comments, speak in your voice - the project does not leave any artifacts and even if you wish, you will never be able to return to it in a year. And this means that you will not have a clear vision of the project)
Did I say that a clear vision of the project is impossible during the development process? Yes. It’s this vision that will come to you if you have experience not immediately and as a rule when you are separated from the development process, and most likely under the influence of something - the game you played, the movie / book or good sex)
And before that, try to implement the complete parts / tasks, not taking everything at once and fix, fix, and then structure what you are doing.
So what does this clear vision of the project mean? This is not how the project looks to you, but how you think this project looks to the player / user.
This is best explained by the principle of object programming from G. Buch .:
When we talk about a clear vision of the project, we should see its completeness in one mental representation, while understanding how each element is realized and knowing that this will not require expansion with further development. That's when we can say our project is complete. You can say that this never happens and always need to develop a project. No, I tell you, and the fact is that we developers define abstractions and fill them with meaning. If we manage to see the beauty and completeness of our chosen abstractions, then we will get a clear vision of the project and the finished game.
You did nothing, but you assemble a team
Do not do it this way
Ambitions, ambitions and once again ambitions - this is what prevents us from working within the indie team ... don't you believe, or do you think this is purely a subjective experience? Well, see if the series Halt and Catch Fire. But ambitions - this is half the trouble - laziness and not professionalism, complete their work.
Alas, until you have done nothing - it's about you, not about those you are trying to find. Yes, and you will find the same)
')
You must clearly understand that the two ambitious people in the team will already be crowded and you will spend more time talking than developing. This does not mean that you should not discuss the project - the point is how you do it.
Before looking for a team - you should have an idea of the game, what you want to do. It consists of the name of the game, the genre, and the gameplay cycle. And it should be on paper. If you don’t have a name, you think it will appear later - everything would be fine, but you probably don’t understand the game. I will never contact such a project - it is a waste of time. Not understanding the genre leads to the fact that you want to shove everything into the game and it lends itself to that sauce, which will be interesting. The gameplay cycle is one of the useful game design terms - study and come up with, without options. And of course, no dizdokov - at this stage you still can not have it. Now you have a vague idea what you want (it may seem clear to you - but it’s better to understand that this is not so).
We start talking with the team. It is no secret that 95% are looking for partners on enthusiasm and deleted. Never speak in a voice with candidates for partners - time wasted for chatter. And to begin with, find out with whom you are dealing, understanding that it would matter if he had an interest - this is again your time spent.
Adequacy is the most important criterion of the first negotiations - never decide for others, do not tell them what to do, do not set deadlines. Such people will very quickly be considered directors and, depending on their professionalism, the teams will tolerate more or less.
Interested people themselves will do and write will show you what happened. Give people the opportunity to have an opinion, do not raise the tone of the conversation in case of disagreement. You will understand quickly or a person argues because of a dispute or he himself undertakes to do what he suggests. Make it a rule that you can not do - not you and decide how to. As a result, work with those who actually do something. But a lot depends on the role in the team.
This is a very academic approach, that a game designer comes up with a game, a programmer encodes, an artist paints. It all depends on the professional person in the business.
Ideally, the work of the game designer ends where the work of the programmer and the artist begins. If a game designer with superior experience than a programmer or artist (which probably happens only in fairy tales, but still), only then can he distribute the work, set tasks for them, or more precisely describe what a programmer or artist needs to do. Find such a game designer who does not suffer from such ambitions, and can work in the set conditions. His task is to detail the idea, not to change it.
As for the artist / 3d modeler, then if this is your first game - you don’t need it at all, use ready-made models, which are now enough or even make a prototype on the squares, a gray prototype. Instead, you'll need a level designer.
As for programmers, the main criterion is to find those who are not ill with writing, can work with any other code, and use it as parts in their development.
You can talk a lot about teams, sometimes it seems that she pulls you down or out, and you want to go deep. But give the team a chance to work with you. It has never happened before that work with professionals was in vain, try to evaluate their vision. If you decide something, do not argue - walk a week and explore other options. If, when discussing options, you see that your opponent does not make compromises, can you work with non-professionals? Do you need it? But in any case, fix everything you do, version control and backups at least once a week.
Flow at a vague vision of the project
If this is your first project, or you have not worked in a team with staff turnover, cursing, but do not understand how this is done in reality, and not on paper - then in 99% you will have a turnover with a vague vision of the project. There can be no other way.
The enthusiasm disappears, but this is how a person works, he can get carried away with something else and start doing another project. This, by the way, is the second reason for staff turnover, the first one, if not generalized adequacy - mentioned above. That is why if you do not fix the documents, do not make comments, speak in your voice - the project does not leave any artifacts and even if you wish, you will never be able to return to it in a year. And this means that you will not have a clear vision of the project)
Did I say that a clear vision of the project is impossible during the development process? Yes. It’s this vision that will come to you if you have experience not immediately and as a rule when you are separated from the development process, and most likely under the influence of something - the game you played, the movie / book or good sex)
And before that, try to implement the complete parts / tasks, not taking everything at once and fix, fix, and then structure what you are doing.
So what does this clear vision of the project mean? This is not how the project looks to you, but how you think this project looks to the player / user.
This is best explained by the principle of object programming from G. Buch .:
concepts of sufficiency, completeness and primitiveness. Under sufficiency means the presence in the class or module of everything necessary for the implementation of logical and effective behavior. In other words, the components must be fully usable. For example, consider the set class (set). The operation of removing an element from the set in this class is obviously necessary, but it would be an error not to include in this class and the operation of adding an element. A violation of the sufficiency requirement is detected very quickly as soon as a client is created using abstraction. By completeness is meant the presence in the interface part of the class of all abstraction characteristics. The idea of sufficiency imposes minimal requirements on the interface, and the idea of completeness covers all aspects of abstraction. Completeness is characterized by such a class or module, the interface of which guarantees everything for interaction with users. Completeness is a subjective factor, and developers often abuse it.
When we talk about a clear vision of the project, we should see its completeness in one mental representation, while understanding how each element is realized and knowing that this will not require expansion with further development. That's when we can say our project is complete. You can say that this never happens and always need to develop a project. No, I tell you, and the fact is that we developers define abstractions and fill them with meaning. If we manage to see the beauty and completeness of our chosen abstractions, then we will get a clear vision of the project and the finished game.
Source: https://habr.com/ru/post/324850/
All Articles