LexTailor
поставил
1132 плюса и 233 минуса
Награды:
432 рейтинг
11 подписчиков
53 подписки
4 поста
0 в горячем
Начинающим от начинающего. Разработка игр взглядом неопытного разработчика.
Здравствуй, читатель. Не против, если на «ты»?
Если ты читаешь этот текст, то позволю себе предположить (не зря же теги выставлял?), что тебя интересуют, привлекают игры и, собственно, разработка оных. Возможно, у тебя даже есть своя задумка, которую ты хотел бы воплотить в жизнь для самореализации во вполне коммерческом смысле. Думаю, что в некотором роде я смогу тебе помочь.
Нет, я не смогу научить тебя делать игры. По-крайней мере, во всех смыслах этой фразы. Я не гуру в этой области, не имею на руках готовый проект, я почти такой же, как и ты, дорогой читатель. Однако же…
Я знаю, что и как тебе рассказать, чтобы дать хотя бы минимальное представление о том, что встретится на пути в процессе работы над твоим детищем, и что стоит сделать, дабы вероятность успеха твоего непростого мероприятия выросла. Благо, опыт позволяет.
Да, я капитанствую, говорю очевидные вещи, однако, как показала практика общения с некоторыми личностями, очень многие понятия не имеют о том, с чего вообще стоит начать и о чём даже думать. Ну, как я в своё время.
Вряд ли это можно назвать уроком, скорее набором рекомендаций желающим попытаться воплотить свою электронную мечту. Рассказ будет подаваться постепенно просто исходя из того, что я занят своим проектом и всё нижесказанное будет основываться на опыте работы с ним (а быстро это не делается) и при небольшой модерации знакомых из сферы геймдева.
Что ж, теперь, когда несколько затянувшееся представление завершено, можно перейти к сабжу.
Каждого, кто когда-либо хотел заниматься созданием своих игр, вдохновило на это что-либо. Я, будучи пятилетним мальчиком, играл в свои первые игры на игровой консоли Dendy и уже тогда понял, что хочу однажды начать делать свои игры, чтобы приносить людям такое же удовольствие, которое получил сам тогда.
Однако первое, что стоит понять и принять, приходя к разработке – каким бы единоличником ты ни был, не старайся всё делать в одиночку. Это долго, тяжело и не обещает успеха в твоей кампании. Прошло то время, когда один-двое энтузиастов могли создать нечто и произвести фурор. Мне неприятно это говорить, но смирись – тебе с большим процентом вероятности не стать первооткрывателем, как товарищ Кармак (Doom), товарищи Брэбен и Бэлл (Elite), товарищ Пажитнов (Tetris), например. Есть очень редкие исключения, вроде Дина Додрилла с его милым Dust’ом (Dust: The Elisyan Tail), но он, если уж на то пошло, сделал всё за три года и всё равно не смог обойтись без сторонней помощи – сценарий дописать помог друг, а почти всю музыку написала отдельная студия.
Вывод: не работай один. Это может плохо сказаться на качественном уровне твоей идеи во всех смыслах. Да и когда закончишь, может быть уже поздно.
Следующее, что стоит запомнить – не стремись охватить всё и сразу. Помни, точное и конкретное планирование – твой верный товарищ, ведь не всё можно сделать сразу и сгоряча. Стоп, погоди-ка. У тебя всё продумано? Я тоже так считал.
Однако попытка написать сходу дизайн-документ кончилась… Ну, не то, чтобы кончилась. Даже половина не готова, каждая деталь продумывается по нескольку раз и только после этого записывается в соответствующий раздел. Уже третий месяц пишу, что вовсе не порядок.
Дизайн-документ – твой самый лучший друг во время разработки и путеводная звезда тех, кто работает над проектом. Концепция твоей игры, сюжетная часть, игровая механика, формулы, предполагаемые расходы – всё это должно быть написано в дизайн-документе. Если хочешь, чтобы шанс что-то сделать в нынешних тяжелейших условиях рынка нашей нетленной игровой индустрии хотя бы появился – напиши диздок. Сразу поймёшь, где у тебя недочёты, что будет интересным и наоборот. Даже в голове всё уложится в аккуратные стопочки с информацией. Чувство приятное, поверь мне на слово.
Вывод: сначала создай свой проект «на бумаге» - сразу почувствуешь себя увереннее и сильно продвинешься вперёд. Более того, именно этот план действий бдет помогать твоей команде работать так, как это необходимо твоей идее.
О диздоке стоит поговорить отдельно в грядущем, поскольку я сам его ещё не дописал, уж простите ^^*
А пока, раз всё понятно, ответь самому себе на вопрос – чем ты готов пожертвовать в угоду своему будущему творению? Да-да, именно так, пожертвовать.
Любая работа должна оплачиваться. Любой труд стоит затраченных усилий и должен быть вознаграждён. Если ты примешь это как нерушимую истину, то шанс обрести сильную команду, которая будет заниматься твоим проектом, вырастет в разы. А тем более, если ты сможешь обеспечить её нормальным серьёзным рабочим инструментом, честно приобретённым по лицензии, а не скачанным с рутрекера. Это покажет серьёзность твоих намерений и поднимет планку доверия команды к тебе.
Однако это вовсе не означает, что тебе нужно всех «купить». По-крайней мере, нанимать рабочую силу вовсе не обязательно, особенно с малым бюджетом. Есть действительно серьёзные группы энтузиастов, которые работают за идею, но создать такое очень сложно. Идея должна действительно стоить того, чтобы другие люди могли за неё тратить свои силы и время. Если ищешь тех, с кем хочешь сделать Нечто, не стесняйся рассказать немного о своей идее. Посмотри на другие проекты – на всяких кикстартерах и иже с ними трейлеры, информация о проекте, некоторые даже небольшие части диздока выкладывают, которые не раскрывают основные секреты и сюжет, просто описывают концепцию игры. Не стесняйся заинтересовать людей, в конце концов – не для себя же делаешь, не так ли?
Вывод: не скупись ни в чём, если хочешь что-то сделать хорошо. Однако подлетать близко к солнцу тоже не стоит.
Какая валюта самая ценная в этом мире? Информация, а не то, о чём ты подумал. Да, тебе придётся научиться очень многому, и чем больше ты узнаешь – тем лучше. В конце концов, чтобы разграничить роли людей в твоей команде, чтобы грамотно оформить техзадание в диздоке, нужно иметь понятие о том, что нужно сделать твоим людям. Если ты хочешь курировать свой проект по-серьёзному, ты должен знать массу всего: основные принципы того, как программист составляет программы, а лучше – знать как минимум основы хотя бы одного языка программирования; как моделлер делает модельки, что такое полигоны и почему так важно следить за их количеством; как работает сетевая составляющая, как работают базы данных, какие основные консольные команды нужны для управления серверной машиной. Что, думаешь всё? Прости, но нет. Это лишь малая часть, которая просто пришла в голову сейчас. В конце концов, с помощью всех этих знаний ты сможешь максимально полно составить для твоих людей картины игры, которую вы делаете.
По-большому счёту, тебе нужно знать всё, что должны делать люди в твоей команде. Хотя бы основы, чтобы понимать, что может понадобиться им для решения поставленных тобою задач. А если команда маленькая и не дай кернел что-то произошло – чтобы мог заменить кого-либо хотя бы временно.
Нет ничего постыдного в том, чтобы спросить что-то у более опытных людей, но намного лучше в практическом смысле, да и для понимания сабжа, найти ответ на свой вопрос самому.
Вообще, самостоятельное обучение намного более эффективное, чем обычная учёба, поскольку заставляет твой мозг работать на полную катушку, выискивая именно то, что тебе нужно и выстраивая в голове модель того, как это можно применить.
Вывод: читай, учи, запоминай, практикуй – любая новая информация важна, причём не только для твоего проекта, но и для твоего собственного развития.
Что определяет порядок и правила работы, помимо плана? Правильно, рабочий инструмент. В зависимости от того, что за игру ты делаешь, нужно оценивать то, чем вашей команде придётся пользоваться, начиная от движка для проекта и заканчивая элементарными библиотеками.
Не постесняйся почитать о возможностях выбранного инструмента, обязательно найди отзывы тех, кто на любительском уровне что-то пробовал сделать – они всегда наиболее информативны, потому как не предвзяты в большинстве случаев. Максимум – личное отношение, развившееся ввиду индивидуального понятия об удобстве (найди программера на Delphi и программера на C и спроси у них, что лучше – наглядность во все поля). Кстати, в топиках со спорами о том, что лучше, можно также почерпнуть массу полезных сведений, которые помогут определиться с выбором.
Вывод: хороший, удобный рабочий инструмент с правильным подходом к работе с ним – огромный шаг навстречу релизу.
Всё выше перечисленное – далеко не всё, через что нужно морально и физически пройти на пути от идеи к релизу. Однако же… Если после всего прочитанного у тебя не пропало желание заниматься чем-либо – я очень горд за твоё стремление. Несмотря ни на что, постарайся сохранить этот рабочий запал, потому как более ничего не сможет заставить тебя продолжать идти дальше.
По мере работы над собственным проектом будут составляться новые посты с разъяснениями (я очень не хочу заниматься склеиваниями длиннопоста с картинками, всё зависит от настроения и наличия свободного времени), а так же будет выложен полностью оформленный дизайн-документ для дополнения картины.
LT, к вашим услугам.
Если ты читаешь этот текст, то позволю себе предположить (не зря же теги выставлял?), что тебя интересуют, привлекают игры и, собственно, разработка оных. Возможно, у тебя даже есть своя задумка, которую ты хотел бы воплотить в жизнь для самореализации во вполне коммерческом смысле. Думаю, что в некотором роде я смогу тебе помочь.
Нет, я не смогу научить тебя делать игры. По-крайней мере, во всех смыслах этой фразы. Я не гуру в этой области, не имею на руках готовый проект, я почти такой же, как и ты, дорогой читатель. Однако же…
Я знаю, что и как тебе рассказать, чтобы дать хотя бы минимальное представление о том, что встретится на пути в процессе работы над твоим детищем, и что стоит сделать, дабы вероятность успеха твоего непростого мероприятия выросла. Благо, опыт позволяет.
Да, я капитанствую, говорю очевидные вещи, однако, как показала практика общения с некоторыми личностями, очень многие понятия не имеют о том, с чего вообще стоит начать и о чём даже думать. Ну, как я в своё время.
Вряд ли это можно назвать уроком, скорее набором рекомендаций желающим попытаться воплотить свою электронную мечту. Рассказ будет подаваться постепенно просто исходя из того, что я занят своим проектом и всё нижесказанное будет основываться на опыте работы с ним (а быстро это не делается) и при небольшой модерации знакомых из сферы геймдева.
Что ж, теперь, когда несколько затянувшееся представление завершено, можно перейти к сабжу.
Каждого, кто когда-либо хотел заниматься созданием своих игр, вдохновило на это что-либо. Я, будучи пятилетним мальчиком, играл в свои первые игры на игровой консоли Dendy и уже тогда понял, что хочу однажды начать делать свои игры, чтобы приносить людям такое же удовольствие, которое получил сам тогда.
Однако первое, что стоит понять и принять, приходя к разработке – каким бы единоличником ты ни был, не старайся всё делать в одиночку. Это долго, тяжело и не обещает успеха в твоей кампании. Прошло то время, когда один-двое энтузиастов могли создать нечто и произвести фурор. Мне неприятно это говорить, но смирись – тебе с большим процентом вероятности не стать первооткрывателем, как товарищ Кармак (Doom), товарищи Брэбен и Бэлл (Elite), товарищ Пажитнов (Tetris), например. Есть очень редкие исключения, вроде Дина Додрилла с его милым Dust’ом (Dust: The Elisyan Tail), но он, если уж на то пошло, сделал всё за три года и всё равно не смог обойтись без сторонней помощи – сценарий дописать помог друг, а почти всю музыку написала отдельная студия.
Вывод: не работай один. Это может плохо сказаться на качественном уровне твоей идеи во всех смыслах. Да и когда закончишь, может быть уже поздно.
Следующее, что стоит запомнить – не стремись охватить всё и сразу. Помни, точное и конкретное планирование – твой верный товарищ, ведь не всё можно сделать сразу и сгоряча. Стоп, погоди-ка. У тебя всё продумано? Я тоже так считал.
Однако попытка написать сходу дизайн-документ кончилась… Ну, не то, чтобы кончилась. Даже половина не готова, каждая деталь продумывается по нескольку раз и только после этого записывается в соответствующий раздел. Уже третий месяц пишу, что вовсе не порядок.
Дизайн-документ – твой самый лучший друг во время разработки и путеводная звезда тех, кто работает над проектом. Концепция твоей игры, сюжетная часть, игровая механика, формулы, предполагаемые расходы – всё это должно быть написано в дизайн-документе. Если хочешь, чтобы шанс что-то сделать в нынешних тяжелейших условиях рынка нашей нетленной игровой индустрии хотя бы появился – напиши диздок. Сразу поймёшь, где у тебя недочёты, что будет интересным и наоборот. Даже в голове всё уложится в аккуратные стопочки с информацией. Чувство приятное, поверь мне на слово.
Вывод: сначала создай свой проект «на бумаге» - сразу почувствуешь себя увереннее и сильно продвинешься вперёд. Более того, именно этот план действий бдет помогать твоей команде работать так, как это необходимо твоей идее.
О диздоке стоит поговорить отдельно в грядущем, поскольку я сам его ещё не дописал, уж простите ^^*
А пока, раз всё понятно, ответь самому себе на вопрос – чем ты готов пожертвовать в угоду своему будущему творению? Да-да, именно так, пожертвовать.
Любая работа должна оплачиваться. Любой труд стоит затраченных усилий и должен быть вознаграждён. Если ты примешь это как нерушимую истину, то шанс обрести сильную команду, которая будет заниматься твоим проектом, вырастет в разы. А тем более, если ты сможешь обеспечить её нормальным серьёзным рабочим инструментом, честно приобретённым по лицензии, а не скачанным с рутрекера. Это покажет серьёзность твоих намерений и поднимет планку доверия команды к тебе.
Однако это вовсе не означает, что тебе нужно всех «купить». По-крайней мере, нанимать рабочую силу вовсе не обязательно, особенно с малым бюджетом. Есть действительно серьёзные группы энтузиастов, которые работают за идею, но создать такое очень сложно. Идея должна действительно стоить того, чтобы другие люди могли за неё тратить свои силы и время. Если ищешь тех, с кем хочешь сделать Нечто, не стесняйся рассказать немного о своей идее. Посмотри на другие проекты – на всяких кикстартерах и иже с ними трейлеры, информация о проекте, некоторые даже небольшие части диздока выкладывают, которые не раскрывают основные секреты и сюжет, просто описывают концепцию игры. Не стесняйся заинтересовать людей, в конце концов – не для себя же делаешь, не так ли?
Вывод: не скупись ни в чём, если хочешь что-то сделать хорошо. Однако подлетать близко к солнцу тоже не стоит.
Какая валюта самая ценная в этом мире? Информация, а не то, о чём ты подумал. Да, тебе придётся научиться очень многому, и чем больше ты узнаешь – тем лучше. В конце концов, чтобы разграничить роли людей в твоей команде, чтобы грамотно оформить техзадание в диздоке, нужно иметь понятие о том, что нужно сделать твоим людям. Если ты хочешь курировать свой проект по-серьёзному, ты должен знать массу всего: основные принципы того, как программист составляет программы, а лучше – знать как минимум основы хотя бы одного языка программирования; как моделлер делает модельки, что такое полигоны и почему так важно следить за их количеством; как работает сетевая составляющая, как работают базы данных, какие основные консольные команды нужны для управления серверной машиной. Что, думаешь всё? Прости, но нет. Это лишь малая часть, которая просто пришла в голову сейчас. В конце концов, с помощью всех этих знаний ты сможешь максимально полно составить для твоих людей картины игры, которую вы делаете.
По-большому счёту, тебе нужно знать всё, что должны делать люди в твоей команде. Хотя бы основы, чтобы понимать, что может понадобиться им для решения поставленных тобою задач. А если команда маленькая и не дай кернел что-то произошло – чтобы мог заменить кого-либо хотя бы временно.
Нет ничего постыдного в том, чтобы спросить что-то у более опытных людей, но намного лучше в практическом смысле, да и для понимания сабжа, найти ответ на свой вопрос самому.
Вообще, самостоятельное обучение намного более эффективное, чем обычная учёба, поскольку заставляет твой мозг работать на полную катушку, выискивая именно то, что тебе нужно и выстраивая в голове модель того, как это можно применить.
Вывод: читай, учи, запоминай, практикуй – любая новая информация важна, причём не только для твоего проекта, но и для твоего собственного развития.
Что определяет порядок и правила работы, помимо плана? Правильно, рабочий инструмент. В зависимости от того, что за игру ты делаешь, нужно оценивать то, чем вашей команде придётся пользоваться, начиная от движка для проекта и заканчивая элементарными библиотеками.
Не постесняйся почитать о возможностях выбранного инструмента, обязательно найди отзывы тех, кто на любительском уровне что-то пробовал сделать – они всегда наиболее информативны, потому как не предвзяты в большинстве случаев. Максимум – личное отношение, развившееся ввиду индивидуального понятия об удобстве (найди программера на Delphi и программера на C и спроси у них, что лучше – наглядность во все поля). Кстати, в топиках со спорами о том, что лучше, можно также почерпнуть массу полезных сведений, которые помогут определиться с выбором.
Вывод: хороший, удобный рабочий инструмент с правильным подходом к работе с ним – огромный шаг навстречу релизу.
Всё выше перечисленное – далеко не всё, через что нужно морально и физически пройти на пути от идеи к релизу. Однако же… Если после всего прочитанного у тебя не пропало желание заниматься чем-либо – я очень горд за твоё стремление. Несмотря ни на что, постарайся сохранить этот рабочий запал, потому как более ничего не сможет заставить тебя продолжать идти дальше.
По мере работы над собственным проектом будут составляться новые посты с разъяснениями (я очень не хочу заниматься склеиваниями длиннопоста с картинками, всё зависит от настроения и наличия свободного времени), а так же будет выложен полностью оформленный дизайн-документ для дополнения картины.
LT, к вашим услугам.