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

Добавлен , опубликован

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

Содержание:
Приветствую! Сегодня мы рассмотрим самое сладкое в разработке игр. Сам процесс разработки.
Я думаю, что можно уже начинать.
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. Прикреплю спрайты сюда, если кому-то нужны.

Содержание
`
ОЖИДАНИЕ РЕКЛАМЫ...

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
0
15
8 лет назад
0
Есть же приложения для создания UML диаграмм. Почему бы не кинуть ссылки на них?
0
29
8 лет назад
0
UML не правильная. Насследование - сплошная стрелочка, Связь - пунктирная
6
37
8 лет назад
Отредактирован ScorpioT1000
6
alexprey, согласен, причем там указана ассоциация, а не наследование (стрелка маленькая и не замкнутая), но по факту происходит композиция =(
Бесплатное приложение для создания полноценных грамотных диаграмм и графиков, включая полный UML пакет:
Всем рекомендую. Для более крутого Microsoft Office Visio.
0
29
8 лет назад
0
ScorpioT1000, мне draw.io хватало всегда)
2
24
8 лет назад
Отредактирован darkowlom
2
С каких вообще пор кто-то начал делать игры без вложения частички души, не искренне?
Игры ведь тоже своего рода искусство... Это всё равно что Да Винчи нарисовал бы Моно Лизу,
чтобы прославиться и "втюхать" картину за "кэш".
Сейчас все ради кэша практически, особенно в гемдеве. Как сказал мой знакомый художник, осваивающий компьютерные редакторы - искусство, нынче, никому не нужно - холст не продашь, а кушать хочется. Нужно рисовать, то за что платят, а это явно не картины
2
20
8 лет назад
2
alexprey:
ScorpioT1000, мне draw.io хватало всегда)
Согласен, хороший инструмент, мне еще нравится gliffy, там функционала побольше и аккуратнее все делается.
0
29
8 лет назад
0
мне еще нравится gliffy
он слишком ушел в платность, выглядит да покрасивее, но в draw.io лучше группировка реализована + интеграция с дропбоксом
0
20
8 лет назад
0
он слишком ушел в платность, выглядит да покрасивее, но в draw.io лучше группировка реализована + интеграция с дропбоксом
Да, и с google docs. И в приложениях chrome есть. Но мне так не хватает в нем комментариев к блокам, что аж прям ужас.
0
37
8 лет назад
Отредактирован ScorpioT1000
0
Ребят, у Dia есть dia2code, который может генерить код для языков Ada, C, C++, C#, CORBA IDL, Java, PHP, PHP5, Python, Ruby, shapefile, and SQL
0
21
8 лет назад
0
darkowlom:
С каких вообще пор кто-то начал делать игры без вложения частички души, не искренне?
Игры ведь тоже своего рода искусство... Это всё равно что Да Винчи нарисовал бы Моно Лизу,
чтобы прославиться и "втюхать" картину за "кэш".
Сейчас все ради кэша практически, особенно в гемдеве. Как сказал мой знакомый художник, осваивающий компьютерные редакторы - искусство, нынче, никому не нужно - холст не продашь, а кушать хочется. Нужно рисовать, то за что платят, а это явно не картины
Неистово плюсую). Так и есть.
0
15
8 лет назад
0
жду 3ю часть
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.