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

от автора

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
      • Нет, нет, нет
    • Boost!
      • Усыпите нас обоих. Дороги назад уже нет. Это точка невозврата.

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

    Советы

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

    改善 — кайдзен

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Делись

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

    Заключение

    Хватит читать, приступай к делу!

ссылка на оригинал статьи https://habrahabr.ru/post/314908/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *