Pull to refresh

Не твоя проблема

Reading time6 min
Views30K
Original author: Daniel Schuller
image

Ты — целеустремлённый разработчик игр. Ты хочешь создать и выпустить потрясающую игру, чтобы о ней узнал мир. Это сложно, намного сложнее чем, скажем, написать книгу. Игра — это алхимическая смесь искусства, личного вкуса, строгой математики, логистики и проектирования. Очень немногие могут создать игру в одиночку, при этом легко отвлечься, слишком легко. Или ещё хуже — заняться тем, что тебе не нужно. Ты доволен, многому учишься, что-то делаешь, но игра не становится ближе к завершению, которое и является целью. Не забывай о цели…

Специалисты


Проблемы специалистов — это не твои проблемы.

Ты подписан в твиттере на таких крутых экспертов, как @ID_AA_Carmack, @notch и @grumpygamer? Все они отличные разработчики успешно выпущенных игр.

А ты уже выпустил игру? Нет ведь, правда? Тогда проблемы этих ребят — не твои проблемы. У тебя совершенно другая проблема, требующая твоего полного внимания: выпуск завершённой игры. Вот и всё.

Твоя проблема и проблемы специалистов частично пересекаются, но совсем чуть-чуть. Так что от большинства из них можно с лёгкостью отмахнуться.

Проблемы специалистов


image
Джон Кармак: «Я рад, что мы наконец обеспечили поддержку C++11 в базе кода Oculus для мобильных устройств. Там есть куча мест, где unique_ptr очень поможет.»

Ой-ой-ой, а я-то использую GameMaker! Я не настоящий программист, выкину-ка весь проект в мусорку! Надо срочно заказать на Amazon шесть книг по C++11.

Остановись! Использование умных указателей — не твоя проблема. Чтобы выпустить игру, тебе нужно для начала выбросить из головы указатели. Как ты будешь выполнять сборку игры? Как обеспечишь её работу на чужом компьютере? Целые игровые студии еле с этим справляются, а ведь у них команды часто состоят из сотен людей. Это не твоя проблема.

У специалистов много проблем: хейтеры в Интернете, фанаты просят инноваций, фанаты просят оставить всё как есть, большие коллективы, бюрократия, возникающая в больших коллективах, особая бюрократия, возникающая в больших коллективах кодеров (методология Scrum, отношение к сотрудникам как к ресурсам, планёрки, споры о невымытой посуде в раковине — в общем, проблемы специалистов).

Самая суть


Вот твои проблемы по степени важности.

  1. Придумать игру, которую ты можешь сделать, и
    • Которую оценит (а может и купит!) кто-то ещё.
    • Которую ты сможешь сделать меньше, чем за месяц. Да, именно.
  2. Найти готовый движок
    • В котором уже создавали коммерческие игры.
    • В котором можно разрабатывать игры быстро.
    • Который сам занимается сборкой.
    • А если ты уже знаком с ним, то вообще отлично.
  3. Закончить игру
  4. Продать её (или выложить)
  5. Прорекламировать её
  6. Получить отзывы
  7. GOTO 1

Если в выбранном движке ты не можешь за полдня создать клон Pong, в который другие люди смогут сыграть впервые, значит, выбор был неверным и тебя съест Гру.

А вот проблемы, которые не твои.

  1. Создание движка на C++
    • Нет
    • Неееееет
    • Неа
  2. Переписывание библиотеки STL C++, чтобы она не занимала так много памяти
    • *Сдерживаемые рыдания*
  3. Изучение способов создания многоплатформенных сборок
    • Научиться make
    • Потом cmake (make — для лохов!)
    • Затем premake (cmake — фигня)
    • Потом Jam (пфф, premake!)
    • И так он опускался всё глубже в темноту бездны. Мы знаем, что больше не увидим его лица. Он потерян для нас. Ещё одно дитя Адама заблудилось во тьме.
  4. Начать писать класс Vector
    • Хм, лучше посмотреть в операциях SIMD
    • Потом матрицы, кватернионы, ад интеграции OpenGL на любой вкус для шести платформ. Ой, постойте-ка, лучше ведь создать ещё и общий слой абстракции для поддержки DirectX. И материал для металла. А, нужен качественный промежуточный язык написания шейдеров!
      • Ни слёз.
      • Ни жалости.
      • Ни надежды.
  5. Споры обо всякой фигне в интернетах
    • Язык X лучше языка Y
    • Библиотека X лучше Y
    • Платформа
    • Методология программирования
    • Надо ли стремиться к 60 FPS (правильный ответ: нет.)
  6. Изучение программирования шейдеров
    • Это было твоей целью? Нет? Тогда ХВАТИТ. Делай игру.
    • Тебе нужна какая-то техника? Ну ладно, продолжай...
      • … но с осторожностью.
  7. Автоматизированные системы документирования
    • Doxygen
    • cldoc
    • Закапывайте его
  8. Локализация
    • Nooooo
    • Nein
    • Non
    • ヤダー
    • Займёшься ею, как и всем остальным, после релиза.
  9. Оптимизация
    • «Игры — это исследовательское программирование»
      • Ты выбросишь этот код
      • Будет не важно, насколько быстро он шевелится на дне корзины для мусора.
    • Ты будешь заниматься ею, пока код не станет быстрым, или таким медленным, что не захочется продолжать
  10. Написание многотомных диздоков
    • Или рисование UML-диаграмм (Открою секрет: никто этим не занимается.)
    • Разработка через тестирование.
      • Нет.
  11. Создание редактора уровней
    • Не поддавайся искушению
    • Если очевидно, что это сэкономит время, создай МИНИМАЛЬНЫЙ редактор. Не тешь себя мыслью, что он пригодится в будущем.
    • MFC (Здесь тебе лучше просто выйти из-за компьютера, взять молоток и ударить себе по пальцам. Это будет менее болезненно.)
    • Qt — нееееет
    • .NET — неа
    • Простые текстовые файлы с динамической перезагрузкой в редакторе
      • Удивительно, но да
  12. XML
    • Нет
    • Написание собственного парсера XML
      • Который работает с пространствами имён!
        • Нет
    • SOAP
      • Ты так далеко сошёл с пути разработки игр, что уже не видишь его.
    • JSON, YAML, MessagePack
      • Нет, нет, нет
  13. Boost!
    • Усыпите нас обоих. Дороги назад уже нет. Это точка невозврата.

Во всём этом нет ничего плохого, но занимаясь такими вещами, ты никогда не выпустишь игру. Через несколько лет ковыряния у тебя будет отличный самописный движок, но ты останешься на первой клетке поля. Создай и выпусти игру.

Советы


Как сосредоточиться на своих проблемах и развивать то, что важно? Вот что можно попробовать.

改善 — кайдзен

Всё японское — это круто, не так ли? Ну, если подумать, можно найти несколько исключений. А вообще в Японии есть то, что без сомнения замечательно — это Toyota. Да, люди, делающие автомобили! Они, как Генри Форд двухтысячных, создают множество интересных бизнес-инноваций. И ведь все мы всегда готовы поговорить о бизнес-инновациях? Правда?

Ну ладно, пора проснуться!

Компания Toyota популяризировала отличный метод кайдзен: постоянное усовершенствование. Вкратце описать эту технику можно как мировоззрение, направленное на постоянный поиск областей для улучшения процесса разработки. Небольших улучшений, пусть на 1%. Никаких революций.

Выбери минимальный шаг, который может улучшить процесс и приблизит тебя к цели.

Когда я думаю о кайдзен в свете разработки игр, я игнорирую то, что касается процесса и рассматриваю этот метод как вопрос: «Какое минимально возможное действие я могу сделать, чтобы игра приблизилась к релизу?» Это может быть создание одного уровня или быстрое накидывание всех уровней при первом этапе доводки. Это может быть составление списка нужных звуков и отправка его аутсорсеру. Важно всегда двигать процесс разработки вперёд.

Новая страница диздока не приблизит завершение игры, как и безрезультатная встреча. Приближают финал строки кода и мегабайты ассетов. Только они двигают процесс. Тебе может понадобиться выполнение других задач, но всегда надо делать небольшие шаги в направлении релиза.

Начни с малого


Это будет твоя первая игра? О, тогда тебя ждут проблемы.

Начни с малого! Действительно малого. Маленького как Pong. Выбери самую маленькую игру, которую сможешь сделать, и пройди с ней весь процесс разработки. Благодаря этим мукам ты получишь из первых рук мудрость, которая недоступна людям, годами пыхтящим над своей первой игрой.

Конечно, это только мнение, но и объективная правда: ты во всех отношениях будешь сверхчеловеком по сравнению с этими жалкими грязнокровками, которым не удалось ничего закончить. Каждый день они будут уныло мотыжить поля, а ты — проноситься мимо них на своей лихой тройке. (Сам я в одиночку выпустил ровно ноль игр, так что я тоже тот смерд с мотыгой, варящий самогон и мечтающий о мировой революции, которая принесёт ему свободу.)

Выбери то, что вдохновляет тебя


Цель, которая вдохновляет тебя, но не слишком масштабна или сложна! Фактор X для любой игры — это ты, с твоими уникальными взглядами на дизайн игр, своим мироощущением, которое ты можешь выразить через игру. Не бойся вносить собственные штрихи.

Чем больше тебя вдохновляет проект, тем проще будет закончить.

Завершение — это навык


Это главный секрет, что-то вроде чит-кода. Чем больше ты завершаешь, тем больше сможешь завершить. Это не тавтология, а правда: делая что-то, ты улучшаешь в этом свои навыки.

Завершение повышает уверенность в себе и позволяет быть рационально амбициозным.

Потребляй меньше


Прочтение 20 статей о разработке игр в день похоже на работу. Да это и есть работа! Но бесполезная, непродуктивная работа: ты топчешься на месте.

Проводи меньше времени на Gamasutra, TIGSource, r/gamedev/ (или где там ещё тусуются крутые ребята в наши дни), и трать чуть больше времени на работу над проектом.

Дай своему внутреннему голосу и интуиции немного развернуться!

Делись


Рассказывай о том, что делаешь, что чувствуешь, какие проблемы у тебя возникают и т.д. Многие разработчики, ведущие бой со своими проектами, найдут для тебя слова поддержки. Кроме того, ты получишь обратную связь, а она сделает тебя лучше.

Заключение


Хватит читать, приступай к делу!
Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
Total votes 77: ↑69 and ↓8+61
Comments78

Articles