Обсуждение статьи ( habrahabr.ru/post/153933/), часть 2.
> Программирование
> Команда.
В отличие от создателей контента программистов для своей команды найти легко. Это объясняется тем, что при определённом уровне подготовки написание программного кода игры не такая уж сложная задача. Можно найти «бесплатных» программистов, готовых работать ради интереса. А за плату и «имя» (упоминание, как разработчика игры) можно найти программиста, который будет писать хороший годный код. Но… сейчас не начало 2000-х и программисты поумнели. Первым делом адекватный программист попросит разработчика продемонстрировать концепцию и ТЗ. Затем спросит про создание контента или финансирование, которое пойдёт на его создание. Специалисты прекрасно понимают, что незачем вкладывать силы в изначально провальный проект. Если у Вас нет концепции и не решен вопрос с контентом, то нормального программиста Вы не найдёте.
Уже обсуждалось. Из моего опыта – нам всегда было сложнее найти хорошего разработчика-программиста под движок. Но если проект достойный и удастся заинтересовать – то найти и программистов, и художников – нифига не непосильная задача. И просят «концепцию и ТЗ» скорее на автомате, чем на здравом смысле. Куда важнее сама идея и опыт того, кто собирает команду – поэтому так важно иметь портфолио, показывающее, что ты умеешь реализовать идею в конечный продукт.
> Сначала делаем большое, потом маленькое.
Достаточно простой совет, но ему чаще всего не следуют. Игровой проект в большинстве случаев сложен и имеет множество зависимостей. Все это сложно просчитать на уровне составления концепции, частенько приходиться что-то менять в планах. Поэтому, чтобы не выполнять двойную работу, сначала необходимо сделать общую работающую конструкцию (прототип), а затем углубляться в детали.
По тексту все верно, а заголовок, по-моему, не совсем хорош. Скорее «от общего к частному», к деталям.
> Что сначала контент или код?
Прочитав раздел про контент, Вы уже, наверное, поняли, что современные игры основаны на контенте, а не на программировании. Отсюда дилемма – код подгонять под контент или контент подгонять под код. Оба подхода имеют место в современном процессе разработки. Если подгонять код под контент, то нагрузка падает на программиста, время разработки увеличивается. Это дешёвый способ. Если контент подгонять под код, то нагрузка с программиста спадает, и при учёте, что контент подготавливают наёмные работники, время разработки сокращается. Это дорогой способ, так как нагрузка падает на наёмных создателей контента. Заранее оцените ситуацию и придерживайтесь одного из подходов.
На самом деле не очень понял зачем что-то под что-то подгонять. По-моему, каждый случай индивидуален, а если речь о ключевом функционале – то он должен быть сделан так, как задумано, а не так, как проще и дешевле. А вообще частенько вижу, что многие коммерческие движки имеют серьезные недостатки, и художники выдумывают порой очень изощренные способы, чтобы их замаскировать.
> Нерешаемые ошибки.
Это даже не проблема, а предубеждение. Разработка игры весьма сложный процесс. Бывает, что разработчик сталкивается с нерешаемыми проблемами (либо решаемыми крайне тяжело) и ему приходиться пересматривать чуть ли не весь проект. Психологически это очень трудно. Многие, даже самые упёртые разработчики, попав в такой «тупик», теряют энтузиазм и закрывают проект. Предубеждение в том, что все считают, что с ними такого не случиться. Совет один: будьте психологически готовы пересмотреть весь проект и выполнить работу заново.
Чтобы этого не происходило, нужно идти от общего к частному, имея на руках не кусочки продукта, а цельное решение, но той или иной степенью детализации. Спиральная модель разработки с ее итерациями, Agile-методики и т.п. вам в помощь. Нужно быть скульптором, высекающим из камня, который сначала придает общие формы, а потом детализирует своё творение.
> Журналы.
Совет лично от меня. Ведите три журнала:
1. 1. Журнал выполненной работы по проекту для отслеживания динамики разработки;
2. 2. Журнал идей по проекту, чтобы не забыть их и, если возможно, включить в кон
> Программирование
> Команда.
В отличие от создателей контента программистов для своей команды найти легко. Это объясняется тем, что при определённом уровне подготовки написание программного кода игры не такая уж сложная задача. Можно найти «бесплатных» программистов, готовых работать ради интереса. А за плату и «имя» (упоминание, как разработчика игры) можно найти программиста, который будет писать хороший годный код. Но… сейчас не начало 2000-х и программисты поумнели. Первым делом адекватный программист попросит разработчика продемонстрировать концепцию и ТЗ. Затем спросит про создание контента или финансирование, которое пойдёт на его создание. Специалисты прекрасно понимают, что незачем вкладывать силы в изначально провальный проект. Если у Вас нет концепции и не решен вопрос с контентом, то нормального программиста Вы не найдёте.
Уже обсуждалось. Из моего опыта – нам всегда было сложнее найти хорошего разработчика-программиста под движок. Но если проект достойный и удастся заинтересовать – то найти и программистов, и художников – нифига не непосильная задача. И просят «концепцию и ТЗ» скорее на автомате, чем на здравом смысле. Куда важнее сама идея и опыт того, кто собирает команду – поэтому так важно иметь портфолио, показывающее, что ты умеешь реализовать идею в конечный продукт.
> Сначала делаем большое, потом маленькое.
Достаточно простой совет, но ему чаще всего не следуют. Игровой проект в большинстве случаев сложен и имеет множество зависимостей. Все это сложно просчитать на уровне составления концепции, частенько приходиться что-то менять в планах. Поэтому, чтобы не выполнять двойную работу, сначала необходимо сделать общую работающую конструкцию (прототип), а затем углубляться в детали.
По тексту все верно, а заголовок, по-моему, не совсем хорош. Скорее «от общего к частному», к деталям.
> Что сначала контент или код?
Прочитав раздел про контент, Вы уже, наверное, поняли, что современные игры основаны на контенте, а не на программировании. Отсюда дилемма – код подгонять под контент или контент подгонять под код. Оба подхода имеют место в современном процессе разработки. Если подгонять код под контент, то нагрузка падает на программиста, время разработки увеличивается. Это дешёвый способ. Если контент подгонять под код, то нагрузка с программиста спадает, и при учёте, что контент подготавливают наёмные работники, время разработки сокращается. Это дорогой способ, так как нагрузка падает на наёмных создателей контента. Заранее оцените ситуацию и придерживайтесь одного из подходов.
На самом деле не очень понял зачем что-то под что-то подгонять. По-моему, каждый случай индивидуален, а если речь о ключевом функционале – то он должен быть сделан так, как задумано, а не так, как проще и дешевле. А вообще частенько вижу, что многие коммерческие движки имеют серьезные недостатки, и художники выдумывают порой очень изощренные способы, чтобы их замаскировать.
> Нерешаемые ошибки.
Это даже не проблема, а предубеждение. Разработка игры весьма сложный процесс. Бывает, что разработчик сталкивается с нерешаемыми проблемами (либо решаемыми крайне тяжело) и ему приходиться пересматривать чуть ли не весь проект. Психологически это очень трудно. Многие, даже самые упёртые разработчики, попав в такой «тупик», теряют энтузиазм и закрывают проект. Предубеждение в том, что все считают, что с ними такого не случиться. Совет один: будьте психологически готовы пересмотреть весь проект и выполнить работу заново.
Чтобы этого не происходило, нужно идти от общего к частному, имея на руках не кусочки продукта, а цельное решение, но той или иной степенью детализации. Спиральная модель разработки с ее итерациями, Agile-методики и т.п. вам в помощь. Нужно быть скульптором, высекающим из камня, который сначала придает общие формы, а потом детализирует своё творение.
> Журналы.
Совет лично от меня. Ведите три журнала:
1. 1. Журнал выполненной работы по проекту для отслеживания динамики разработки;
2. 2. Журнал идей по проекту, чтобы не забыть их и, если возможно, включить в кон
Discussion of the article (habrahabr.ru/post/153933/), part 2.
> Programming
> Team.
Unlike content creators, programmers are easy to find for your team. This is because with a certain level of preparation, writing the game program code is not such a difficult task. You can find "free" programmers willing to work for fun. And for a fee and a “name” (mentioning as a game developer) you can find a programmer who will write good, suitable code. But ... now is not the beginning of the 2000s and programmers wiser. First of all, an adequate programmer will ask the developer to demonstrate the concept and TK. Then he will ask about the creation of content or the financing that will go to its creation. Experts are well aware that there is no need to invest in an initially failed project. If you do not have a concept and the content issue is not resolved, then you will not find a normal programmer.
Already discussed. From my experience - it has always been harder for us to find a good developer-programmer for the engine. But if the project is worthy and it will be possible to interest, then finding both programmers and artists is not an impossible task. And they ask for a "concept and TK" rather on the machine than on common sense. What is more important is the idea and experience of the person who is assembling the team - therefore it is so important to have a portfolio that shows that you are able to implement the idea into the final product.
> First we do big, then small.
Fairly simple advice, but it is most often not followed. The game project in most cases is complex and has many dependencies. All this is difficult to calculate at the level of drafting the concept, often you have to change something in your plans. Therefore, in order not to perform double work, you must first make a common working structure (prototype), and then go deep into the details.
Everything is correct in the text, but the title, in my opinion, is not entirely good. Rather, “from the general to the particular,” to the details.
> What is the content or code first?
After reading the section on content, you probably already realized that modern games are based on content, not programming. Hence the dilemma - customize the code for content or customize the content for the code. Both approaches take place in the modern development process. If you customize the code for the content, then the load falls on the programmer, the development time increases. This is a cheap way. If the content is customized to fit the code, then the load from the programmer decreases, and when hired workers prepare the content, the development time is reduced. This is an expensive way, as the load falls on hired content creators. Assess the situation in advance and stick to one of the approaches.
In fact, I did not quite understand why something should be customized for something. In my opinion, each case is individual, and if we are talking about key functionality, then it should be done as planned, and not as simpler and cheaper. In general, I often see that many commercial engines have serious shortcomings, and artists sometimes devise very sophisticated ways to disguise them.
> Unsolvable errors.
This is not even a problem, but a prejudice. Game development is a very complicated process. It happens that a developer is faced with unsolvable problems (or extremely difficult to solve) and he has to review almost the entire project. Psychologically, this is very difficult. Many, even the most stubborn developers, having fallen into such a "dead end", lose their enthusiasm and close the project. The prejudice is that everyone believes that this will not happen to them. One advice: be psychologically prepared to review the entire project and do the job again.
To prevent this from happening, you need to go from the general to the particular, having in your hands not pieces of the product, but an integral solution, but with one or another degree of detail. Spiral development model with iterations, Agile methods, etc. to help you. You need to be a sculptor carving out of stone, which first gives the general form, and then details its creation.
> Magazines.
Advice personally from me. Keep three magazines:
1. 1. Journal of the work performed on the project to track development dynamics;
2. 2. A magazine of ideas on the project, so as not to forget them and, if possible, include in
> Programming
> Team.
Unlike content creators, programmers are easy to find for your team. This is because with a certain level of preparation, writing the game program code is not such a difficult task. You can find "free" programmers willing to work for fun. And for a fee and a “name” (mentioning as a game developer) you can find a programmer who will write good, suitable code. But ... now is not the beginning of the 2000s and programmers wiser. First of all, an adequate programmer will ask the developer to demonstrate the concept and TK. Then he will ask about the creation of content or the financing that will go to its creation. Experts are well aware that there is no need to invest in an initially failed project. If you do not have a concept and the content issue is not resolved, then you will not find a normal programmer.
Already discussed. From my experience - it has always been harder for us to find a good developer-programmer for the engine. But if the project is worthy and it will be possible to interest, then finding both programmers and artists is not an impossible task. And they ask for a "concept and TK" rather on the machine than on common sense. What is more important is the idea and experience of the person who is assembling the team - therefore it is so important to have a portfolio that shows that you are able to implement the idea into the final product.
> First we do big, then small.
Fairly simple advice, but it is most often not followed. The game project in most cases is complex and has many dependencies. All this is difficult to calculate at the level of drafting the concept, often you have to change something in your plans. Therefore, in order not to perform double work, you must first make a common working structure (prototype), and then go deep into the details.
Everything is correct in the text, but the title, in my opinion, is not entirely good. Rather, “from the general to the particular,” to the details.
> What is the content or code first?
After reading the section on content, you probably already realized that modern games are based on content, not programming. Hence the dilemma - customize the code for content or customize the content for the code. Both approaches take place in the modern development process. If you customize the code for the content, then the load falls on the programmer, the development time increases. This is a cheap way. If the content is customized to fit the code, then the load from the programmer decreases, and when hired workers prepare the content, the development time is reduced. This is an expensive way, as the load falls on hired content creators. Assess the situation in advance and stick to one of the approaches.
In fact, I did not quite understand why something should be customized for something. In my opinion, each case is individual, and if we are talking about key functionality, then it should be done as planned, and not as simpler and cheaper. In general, I often see that many commercial engines have serious shortcomings, and artists sometimes devise very sophisticated ways to disguise them.
> Unsolvable errors.
This is not even a problem, but a prejudice. Game development is a very complicated process. It happens that a developer is faced with unsolvable problems (or extremely difficult to solve) and he has to review almost the entire project. Psychologically, this is very difficult. Many, even the most stubborn developers, having fallen into such a "dead end", lose their enthusiasm and close the project. The prejudice is that everyone believes that this will not happen to them. One advice: be psychologically prepared to review the entire project and do the job again.
To prevent this from happening, you need to go from the general to the particular, having in your hands not pieces of the product, but an integral solution, but with one or another degree of detail. Spiral development model with iterations, Agile methods, etc. to help you. You need to be a sculptor carving out of stone, which first gives the general form, and then details its creation.
> Magazines.
Advice personally from me. Keep three magazines:
1. 1. Journal of the work performed on the project to track development dynamics;
2. 2. A magazine of ideas on the project, so as not to forget them and, if possible, include in
У записи 1 лайков,
0 репостов.
0 репостов.
Эту запись оставил(а) на своей стене Александр Денисов
