Game Dev: Правильный подход к разработке игр. Часть №2

Содержание:
Приветствую! Сегодня мы рассмотрим самое сладкое в разработке игр. Сам процесс разработки.
Я думаю, что можно уже начинать.
Let's do it.

Часть №2 Эпизод №0 Первые шаги

И вот, ты мы с тобой уже начинаем практическую часть. Давай запускай свои инструменты и мы начнём.
Мы начнём с подготовки контента. В первой части я оставил дизайн-документ, где описал какие ресурсы нам понадобятся.
Так как мы делаем полноценную качественную игру, то мы нуждаемся в качественном полноценном контенте. Я имею в виду, что нам понадобятся спрайты, звуки, фоновая музыка, анимация, скрипты и т.д. Следовательно нам необходимо всё это для начала собрать. Желательно создать на рабочем столе отдельную папку и там создать ещё папки, в каждой из которых мы будем хранить по категориям наши ресурсы.
Специально для этой статьи я тоже всё это сделаю, а также скину сюда.
Чтобы не было проблем с авторским правом на музыкальные произведения, берём музыку с сайтов, где музыкальные произведения разрешены для коммерции и где проблем с авторством не будет.
Я предпочту сайт www.freesfx.co.uk. Окей, с музыкой разобрались. Теперь переходим к нашим спрайтам.
Так как я взял пиксельную стилистику игры, для меня не возникнет проблем с отрисовкой разных спрайтов.
Всё буду рисовать в фотошопе. А вы, как пожелаете. Главных героев, кстати, я решил немного отредактировать.
Вот что из этого вышло:
Рекомендую узнать какие форматы поддерживаются тем инструментом, которым вы разрабатываете свой проект. Перед тем как начать подготавливать контент, ты должен чётко для себя понимать, что именно ты должен сделать. какие именно элементы интерфейса отрисовать, какие именно анимации персонажей подготовить и так далее.
Кстати, если ты тоже выбрал пиксельный стиль, погугли, если не знаешь что такое тайлы.
Они помогут создавать целые уровни из менее чем десяти спрайтов.

Часть №2 Эпизод №1 Сила в UML диаграммах заключена.

Этот эпизод в принципе можно пропустить, так как здесь я лишь в деталях рассказываю о том,
как лучше всего проектировать небольшие приложения.
Что ж, я уже затрагивал тему проектирования и надеюсь этим хоть кто нибудь да занимался.
Я буду демонстрировать UML диаграммы нашей игры. Вот такая диаграмма вышла у меня:
Вам не обязательно вникать в каждую мелочь, которая здесь изображена. Зелёным цветом я пометил классы, которые будут созданы. Красным - интерфейсы. Жёлтым - структуры. В самих классах я описал переменные, которые будут в классе, и методы. Всё, что соединено стрелочкой, означает, что класс либо наследуется от такого-то класса или как-то с ним связан. Например у нас в игре есть тёмное жиле. Этот класс не наследует класс LevelManager и SpawnManager. Он лишь связан с ними какими-то действиями. Он будет создаваться на каждом уровне и отображаться в интерфейсе игрока.
Кстати здесь я бы отметил такие основные классы как: LevelManager, SpawnManager, Options. Первый класс хранит в себе всё, что будет отображаться в интерфейсе пользователя. SpawnManager отвечает полностью за создание уровня и ключевых объектов. Options записывает данные в файл и загружает их, а также отвечает за настройки игры и также их записывает.
Да и эта диаграмма вышла не очень точной (некоторые элементы я опустил, чтобы не тратить время), также она получилась очень простой (да, запутаться можно, но проектирование более крупных проектов будет в разы сложнее, диаграммы сверх огромными, а времени займет много).

Часть №2 Эпизод №2 Из UML в код.

Пора нам заняться за программную часть кода. Тут-то самое сладенькое и начинается.
Так, я вижу ты уже настроен, ты уже предполагаешь, как ты будешь всё спроектированное, переносить в код?
А? Ладно, давай-ка вместе сделаем это.
Я запущу Unity3d и Visual Studio, чтобы демонстрировать "наглядно". Для начала я создам три основных класса, о которых я говорил в предыдущем эпизоде. Сначала LevelManager. В нём, кстати, я собираюсь хранить ещё и наш интерфейс и структуру.
Вот так я изобразил этот класс в программе:
Далее не буду демонстрировать написание уже самих функций класса т.к. каждый работает с разным инструментарием. Здесь я демонстрирую лишь сам класс. Как он выглядел в диаграммах, и как он выглядит в коде игры.

Часть №2 Эпизод №3 Применение ООП.

Так как я говорил что буду использовать объектно-ориентированный язык программирования,
следовательно мне необходимо построить логику игры так, чтобы это была красивая книжная полочка,
где всё расставлено по своим местам.
Итак, у нас есть два персонажа, следовательно у нас должно быть реализовано два класса,
оба которые имеют одни и те же свойства, следовательно эти свойства мы отделяем так,
чтобы каждый класс мог использовать их, например метод Move(); или метод Dead();. Конечно,
у нас есть ещё и враг, который имеет такие же методы. Собственно это всё показано на диаграмме.
Каждый этот класс имеет свой спрайт, свою анимацию, свои отличительные свойства. Всё это указывается уже непосредственно в самом классе.
Такие классы как SpawnManager и LevelManager в целом можно было бы и совместить, НО они никак не связаны, да и функции у них разные, поэтому чтобы в наших файлах не имелось тысячи строк,
в которых в будущем можно будет запутаться, мы отделяем все подобные классы. Я даже отделил в отдельный класс монетку и ключ, хотя если мыслить объективно, то оба эти объекта являются "ключевыми" то есть можно было бы создать класс, в котором объединить это всё. Но зачем? Например зачем наша монетка будет содержать ещё такие методы как Open(); и Close();? Именно поэтому мы всё и отделяем.
Хочу заметить также что я взял такие редко используемые (я так думаю) типы данных как byte и short. А всё потому, что нет смысла брать другой тип данных, который будет только занимать больше места. Я не думаю что кто-то из программистов хоть раз брал для переменной здоровья игрока тип long. Это как минимум странно.
Также я использовал применение структуры. Если программист, знающий объектно-ориентированный язык программирования не знает что такое структура, стоит задуматься.. Вкратце, это тот же класс,
только в нём хранятся только различные переменные. Это также влияет на употребление оперативной памяти. Казалось бы, нам то что, мы создаём не крупный проект ММО, где это действительно может сказаться. Всё же, хорошая применение ООП необходима даже для создания калькулятора.

Часть №2 Эпизод №4 Первый результат.

Как ты уже мог увидеть, я сделал простенькие анимации для наших монстров, позже я отрисовал тайлы для создания уровней, и сейчас можно увидеть уже первые шаги к готовому уровню:
Значения Timer и Health я взял из нашей структуры, которую демонстрировал в коде скрипта LevelManager.
Можно ещё много обсуждать мой код и реализацию этой игры, но мы перейдем к другим вещам.

Часть №2 Эпизод №5 Упрощать работу стоит.

В будущем когда в игре мы захотим сделать скажем ещё десять уровней, то нам стоит как-то облегчить себе построение новых уровней. Для таких целей я пишу простой конструктор уровней (возьму пример с игры про монстров), задача которого:
  • Создать землю так, чтобы при этом были ещё и провалы в пропасть.
  • Создать обязательно монстров в определённом месте.
  • Создать обязательно финиш.
  • Создать n-ое кол-во монет в разных свободных местах. Т.е. не в спавне игрока или в финише.
Далее некоторые вещи всё же вручную. Например редкое тёмное желе в особо труднодоступных местах.
Также вручную выставить противников и разные объекты, при помощи которых можно пройти уровень.
В итоге у меня он выглядит вот так:
При следующей же загрузке уже в игре:

Часть №2 Эпизод №6 Подводя итоги.

Сегодня я рассказал очень мало о разработке нашей игры, но дальше рассказывать больше и нечего,
т.к. дальше можно рассказывать о том, как я буду доделывать нашу игру. Пускай, кто разрабатывал игру по статьям, доделает сам, это будет куда правильнее.
Хочу отметить ещё пару вещей. Эта статью я писал относительно немного, три дня, но если я углублялся в процесс разработки, ушла бы неделя, к тому же незачем нам тратить столько время. Кстати не стоит сидеть целыми днями перед компьютером, особенно в праздники. Я не говорю что стоит обязательно прогуливаться. По крайней мере не обязательно, но желательно. Стоит хотя бы немного делать перерывы.
За кружечкой чая и печеньками. В такие моменты ты можешь сконцентрироваться и абстрагироваться от того, что, например, не получается, а также это хоть немного отвлечёт тебя от стула. Двусмысленно конечно сказано.
А теперь пару советов программистам. Читайте и изучайте API своего инструментария.
Многие задают в группах вконтакте такие простые вопросы, что ты понимаешь что такого не было во времена, когда выходили самые первые игры. Не важно на что. Просто представь как разработчики делали игры в то время и как разработчики делают игры сейчас. И как.
» Какая-то история
У меня есть друг, тоже разработчик. Вот однажды у нас зашёл разговор о разработке (о чём же ещё?),
тогда он поделился со мной своими планами на будущее. В его словах я отметил для себя что он относится к созданию игр потребительски. Говорит что выпустит пару игр, которые разработает за пару дней,
раскрутит их и будет получать небольшой заработок.
С каких вообще пор кто-то начал делать игры без вложения частички души, не искренне?
Игры ведь тоже своего рода искусство... Это всё равно что Да Винчи нарисовал бы Моно Лизу,
чтобы прославиться и "втюхать" картину за "кэш".
А как ты думаешь, чем ещё отличается геймдев нынешний и зарождавшийся? Как сейчас относятся к этому?
Да и, скорее всего какие-то моменты я мог пропустить. Может потому, что было лень, но не факт.
P.S. Если необходимо "разжевать" сам процесс разработки подобной игры, то пишите, но тогда это будет уже не в этой статье.
P.S.S. Прикреплю спрайты сюда, если кому-то нужны.


Views: 4 899

» Лучшие комментарии


Ethernet #1 - 6 years ago 0
Голосов: +0 / -0
Есть же приложения для создания UML диаграмм. Почему бы не кинуть ссылки на них?
alexprey #2 - 6 years ago 0
Голосов: +0 / -0
UML не правильная. Насследование - сплошная стрелочка, Связь - пунктирная
ScorpioT1000 #4 - 6 years ago (изм. ) 6
Голосов: +6 / -0
alexprey, согласен, причем там указана ассоциация, а не наследование (стрелка маленькая и не замкнутая), но по факту происходит композиция =(
Бесплатное приложение для создания полноценных грамотных диаграмм и графиков, включая полный UML пакет:
Всем рекомендую. Для более крутого Microsoft Office Visio.
alexprey #5 - 6 years ago 0
Голосов: +0 / -0
ScorpioT1000, мне draw.io хватало всегда)
darkowlom #6 - 6 years ago (изм. ) 2
Голосов: +2 / -0
С каких вообще пор кто-то начал делать игры без вложения частички души, не искренне?
Игры ведь тоже своего рода искусство... Это всё равно что Да Винчи нарисовал бы Моно Лизу,
чтобы прославиться и "втюхать" картину за "кэш".
Сейчас все ради кэша практически, особенно в гемдеве. Как сказал мой знакомый художник, осваивающий компьютерные редакторы - искусство, нынче, никому не нужно - холст не продашь, а кушать хочется. Нужно рисовать, то за что платят, а это явно не картины
Praytic #7 - 6 years ago 0
Голосов: +2 / -2
alexprey:
ScorpioT1000, мне draw.io хватало всегда)
Согласен, хороший инструмент, мне еще нравится gliffy, там функционала побольше и аккуратнее все делается.
alexprey #8 - 6 years ago -2
Голосов: +0 / -2
мне еще нравится gliffy
он слишком ушел в платность, выглядит да покрасивее, но в draw.io лучше группировка реализована + интеграция с дропбоксом
Praytic #9 - 6 years ago -2
Голосов: +0 / -2
он слишком ушел в платность, выглядит да покрасивее, но в draw.io лучше группировка реализована + интеграция с дропбоксом
Да, и с google docs. И в приложениях chrome есть. Но мне так не хватает в нем комментариев к блокам, что аж прям ужас.
ScorpioT1000 #10 - 6 years ago (изм. ) 0
Голосов: +0 / -0
Ребят, у Dia есть dia2code, который может генерить код для языков Ada, C, C++, C#, CORBA IDL, Java, PHP, PHP5, Python, Ruby, shapefile, and SQL
awesomesk1ll #11 - 6 years ago 0
Голосов: +0 / -0
darkowlom:
С каких вообще пор кто-то начал делать игры без вложения частички души, не искренне?
Игры ведь тоже своего рода искусство... Это всё равно что Да Винчи нарисовал бы Моно Лизу,
чтобы прославиться и "втюхать" картину за "кэш".
Сейчас все ради кэша практически, особенно в гемдеве. Как сказал мой знакомый художник, осваивающий компьютерные редакторы - искусство, нынче, никому не нужно - холст не продашь, а кушать хочется. Нужно рисовать, то за что платят, а это явно не картины
Неистово плюсую). Так и есть.
Mark Mocherad #12 - 6 years ago 0
Голосов: +0 / -0
жду 3ю часть
Clamp #13 - 6 years ago 2
Голосов: +2 / -0
Ну блин, есть разница между "правильной разработкой" и "разработкой в соло, если ты программист".
DasBro #14 - 6 years ago (изм. ) 0
Голосов: +0 / -0
Clamp, Согласен, но всё равно для всех есть какие-то особые правила к подходу разработки..
Mark Mocherad, А о чём вы хотите там прочесть?)
Praytic #15 - 5 years ago 0
Голосов: +0 / -0
Можно кстати выкладывать на гит папки со стадиями проекта, которые соответствуют вашим статьям. Т.е.:
part1: всякий код
part2: всякий код + больше кода
part3: всякий код + больше кода + спрайты
или можно просто отдельные ветки делать, но некоторые так могут потеряться.
Kozinaka #16 - 5 years ago 6
Голосов: +6 / -0
А где гарантии, что ваш подход правильный?
DasBro #18 - 5 years ago 0
Голосов: +0 / -0
Kozinaka, Лично мой, конечно же нет гарантий, но если рассуждать объективно, то всё же это лучше чем всё делать в импровизации
ehnaton #19 - 5 years ago 0
Голосов: +0 / -0
Правильный подход - наиболее эффективный в данной ситуации)
А в данной ситуации у нас тут соло кодер. Так что все норм.
И, мне кажется, на хгм многие геймдеверы именно солокодеры)
Oneiros #20 - 5 years ago 0
Голосов: +0 / -0
Любопытненько. Только вопрос а почему только UML? А вообще структурно-системный анализ реально сильно экономит время и нервы при любой разработке, и позволяет некоторые косяки увидеть ещё до создания кода.
GeneralElConsul #21 - 2 years ago (изм. ) 0
Голосов: +0 / -0
В данной записи к автору то же самое замечание, что и в более поздней его статье. Опять же стремление сохранить байты на типах переменных в структуре LevelManager.
  1. Во-первых выравнивание данных в памяти вероятно сделает автору бяку и если уж так важно сохранить память, то можно было бы воспользоваться атрибутами StructLayout, если, конечно, они работают в Unity.
  2. Во-вторых, попытка сэкономить память в скорее всего единичной сущности попросту нецелесообразна. Это все имело бы смысл, если бы использовалось большое множество значений этой структуры, тогда в совокупности можно было бы надеяться на какую-то экономию. В данном же случае имеем наоборот одинокий менеджер, поля которого будут интенсивно использоваться вследствие чего опять возникнет уже один раз описанная мной в комментарии дополнительная работа. В таких условиях не зазорно было бы не поскупиться на память такой важной структуре.