Jusper Jusper

По требованию Яндекса, разбили на 2 отдельные странички.
Вторая часть переехала сюда: https://devtribe.ru/p/indie-kitchen/podcast_devgamm_volume_2

Jusper Jusper

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

Jusper Jusper

Мелочь, но - новая поза персонажа в главном меню. Да, он даже чешет себе задницу.

...
Dreaman Dreaman

IDALGAME,

Действительно оригинально и интересно игра выглядит ;)

Rummy_Games Rummy_Games

Saturated Outer Space #saturdayscreenshot

...
Razz Razz

Мясной шторм в исполнении Юрия Маркова

Stabilitron Stabilitron

Метроидвания в мире славянских сказок. Разбойникам тоже нужно отдыхать.
https://twitter.com/SlavaniaGame/status/1292048996115120128

TheDarkestRed TheDarkestRed

Заброшенный город - концепт арт The Darkest Red 🎮 🕸 🏚
https://vk.com/the_darkestred

IDALGAME IDALGAME

Геймплей беты и создания кофейных пятен.

Следите за разработкой игры: https://vk.com/pt_game

...
Jusper Jusper

У издателей инди-проектов как раз берут либо готовую команду, либо соло-разработчика. Потому что там чем больше хард-скиллов у тебя есть, тем лучше. Я не умею в арт, я не умею в толковый оптимальный код...

Jusper Jusper

GenElCon,

HypeTrain издают в основном инди-разрабочиков, а мне там особо делать нечего, потому что я на данном этапе не инди (точнее инди-мобильник).

GenElCon GenElCon

Ну вот, например, если бы ты в какую-нибудь игру вписаться типо тех, что выходят из под издательского крыла TinyBuild или HypeTrain Digital (такие типичные небольшие крепкие и не очень ПК проекты), как думаешь...

GenElCon GenElCon

Jusper,

А ты пробовал в такие подобные места идти: это были прям гиганты или не только? Просто если это что-то акромя этих гигантов, например, какая-нибудь студия делающая крпепкие не ААА, например Endless Space...

alexprey alexprey

GenElCon, ну это почти тоже самое, что сказать, что я сверх спец по юнити, т.к. C# знаю уже 9 лет, но опыт веб разработки на нем не тоже самое, что скрипты под юньку писать. Тоже самое и с мобилками, там немного другие задачи решаются...

...
Jusper Jusper

GenElCon, в большинстве мест крупных типа Blizzard прямо написано: опыт разработки игры AAA PC проекта, поэтому мобилка там нерелевантна, меня несколько раз развернули.

По личным ощущениям приходится делать конкретное усилие...

GenElCon GenElCon

Jusper,

Хм, а были конкретные кейсы? Ты просто не первый знакомый, кто про это говорит. Любопытно..

Jusper Jusper

Xakkar, lol

Логотип проекта Game Design

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

Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество

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

Let's do it.

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

Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество

И вот, ты мы с тобой уже начинаем практическую часть. Давай запускай свои инструменты и мы начнём.
Мы начнём с подготовки контента. В первой части я оставил дизайн-документ, где описал какие ресурсы нам понадобятся.

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

Чтобы не было проблем с авторским правом на музыкальные произведения, берём музыку с сайтов, где музыкальные произведения разрешены для коммерции и где проблем с авторством не будет.
Я предпочту сайт http://www.freesfx.co.uk/. Окей, с музыкой разобрались. Теперь переходим к нашим спрайтам.
Так как я взял пиксельную стилистику игры, для меня не возникнет проблем с отрисовкой разных спрайтов.
Всё буду рисовать в фотошопе. А вы, как пожелаете. Главных героев, кстати, я решил немного отредактировать.
Вот что из этого вышло:

Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество

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

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

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

Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество

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

Что ж, я уже затрагивал тему проектирования и надеюсь этим хоть кто нибудь да занимался.
Я буду демонстрировать UML диаграммы нашей игры. Вот такая диаграмма вышла у меня:

Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество

Вам не обязательно вникать в каждую мелочь, которая здесь изображена. Зелёным цветом я пометил классы, которые будут созданы. Красным - интерфейсы. Жёлтым - структуры. В самих классах я описал переменные, которые будут в классе, и методы. Всё, что соединено стрелочкой, означает, что класс либо наследуется от такого-то класса или как-то с ним связан. Например у нас в игре есть тёмное жиле. Этот класс не наследует класс LevelManager и SpawnManager. Он лишь связан с ними какими-то действиями. Он будет создаваться на каждом уровне и отображаться в интерфейсе игрока.

Кстати здесь я бы отметил такие основные классы как: LevelManager, SpawnManager, Options. Первый класс хранит в себе всё, что будет отображаться в интерфейсе пользователя. SpawnManager отвечает полностью за создание уровня и ключевых объектов. Options записывает данные в файл и загружает их, а также отвечает за настройки игры и также их записывает.

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

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

Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество

Пора нам заняться за программную часть кода. Тут-то самое сладенькое и начинается.

Так, я вижу ты уже настроен, ты уже предполагаешь, как ты будешь всё спроектированное, переносить в код?
А? Ладно, давай-ка вместе сделаем это.

Я запущу Unity3d и Visual Studio, чтобы демонстрировать "наглядно". Для начала я создам три основных класса, о которых я говорил в предыдущем эпизоде. Сначала LevelManager. В нём, кстати, я собираюсь хранить ещё и наш интерфейс и структуру.

Вот так я изобразил этот класс в программе:

Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество

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

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

Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество

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

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

Такие классы как SpawnManager и LevelManager в целом можно было бы и совместить, НО они никак не связаны, да и функции у них разные, поэтому чтобы в наших файлах не имелось тысячи строк,
в которых в будущем можно будет запутаться, мы отделяем все подобные классы. Я даже отделил в отдельный класс монетку и ключ, хотя если мыслить объективно, то оба эти объекта являются "ключевыми" то есть можно было бы создать класс, в котором объединить это всё. Но зачем? Например зачем наша монетка будет содержать ещё такие методы как Open(); и Close();? Именно поэтому мы всё и отделяем.

Хочу заметить также что я взял такие редко используемые (я так думаю) типы данных как byte и short. А всё потому, что нет смысла брать другой тип данных, который будет только занимать больше места. Я не думаю что кто-то из программистов хоть раз брал для переменной здоровья игрока тип long. Это как минимум странно.

Также я использовал применение структуры. Если программист, знающий объектно-ориентированный язык программирования не знает что такое структура, стоит задуматься.. Вкратце, это тот же класс,
только в нём хранятся только различные переменные. Это также влияет на употребление оперативной памяти. Казалось бы, нам то что, мы создаём не крупный проект ММО, где это действительно может сказаться. Всё же, хорошая применение ООП необходима даже для создания калькулятора.

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

Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество
Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество
Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество

Как ты уже мог увидеть, я сделал простенькие анимации для наших монстров, позже я отрисовал тайлы для создания уровней, и сейчас можно увидеть уже первые шаги к готовому уровню:

Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество

Значения Timer и Health я взял из нашей структуры, которую демонстрировал в коде скрипта LevelManager.

Можно ещё много обсуждать мой код и реализацию этой игры, но мы перейдем к другим вещам.

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

Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество

В будущем когда в игре мы захотим сделать скажем ещё десять уровней, то нам стоит как-то облегчить себе построение новых уровней. Для таких целей я пишу простой конструктор уровней (возьму пример с игры про монстров), задача которого:

  • Создать землю так, чтобы при этом были ещё и провалы в пропасть.
  • Создать обязательно монстров в определённом месте.
  • Создать обязательно финиш.
  • Создать n-ое кол-во монет в разных свободных местах. Т.е. не в спавне игрока или в финише.

Далее некоторые вещи всё же вручную. Например редкое тёмное желе в особо труднодоступных местах.
Также вручную выставить противников и разные объекты, при помощи которых можно пройти уровень.

В итоге у меня он выглядит вот так:

Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество

При следующей же загрузке уже в игре:

Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество

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

Правильный подход к разработке игр. Часть №2 — Game Design — DevTribe: инди-игры, разработка, сообщество

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

Хочу отметить ещё пару вещей. Эта статью я писал относительно немного, три дня, но если я углублялся в процесс разработки, ушла бы неделя, к тому же незачем нам тратить столько время. Кстати не стоит сидеть целыми днями перед компьютером, особенно в праздники. Я не говорю что стоит обязательно прогуливаться. По крайней мере не обязательно, но желательно. Стоит хотя бы немного делать перерывы.
За кружечкой чая и печеньками. В такие моменты ты можешь сконцентрироваться и абстрагироваться от того, что, например, не получается, а также это хоть немного отвлечёт тебя от стула. Двусмысленно конечно сказано.

А теперь пару советов программистам. Читайте и изучайте API своего инструментария.
Многие задают в группах вконтакте такие простые вопросы, что ты понимаешь что такого не было во времена, когда выходили самые первые игры. Не важно на что. Просто представь как разработчики делали игры в то время и как разработчики делают игры сейчас. И как.

У меня есть друг, тоже разработчик. Вот однажды у нас зашёл разговор о разработке (о чём же ещё?),
тогда он поделился со мной своими планами на будущее. В его словах я отметил для себя что он относится к созданию игр потребительски. Говорит что выпустит пару игр, которые разработает за пару дней,
раскрутит их и будет получать небольшой заработок.

С каких вообще пор кто-то начал делать игры без вложения частички души, не искренне?
Игры ведь тоже своего рода искусство... Это всё равно что Да Винчи нарисовал бы Моно Лизу,
чтобы прославиться и "втюхать" картину за "кэш".

А как ты думаешь, чем ещё отличается геймдев нынешний и зарождавшийся? Как сейчас относятся к этому?

Да и, скорее всего какие-то моменты я мог пропустить. Может потому, что было лень, но не факт.

P.S. Если необходимо "разжевать" сам процесс разработки подобной игры, то пишите, но тогда это будет уже не в этой статье.

P.S.S. Прикреплю спрайты сюда, если кому-то нужны.

Вот тута: https://www.dropbox.com/s/g02matxxm72h5li/Sprites.zip?dl=0

Смотрите также:


Комментарии



  • 1
  • 2 (Текущая страница)

жду 3ю часть

Ну блин, есть разница между "правильной разработкой" и "разработкой в соло, если ты программист".

Clamp, Согласен, но всё равно для всех есть какие-то особые правила к подходу разработки..
Mark Mocherad, А о чём вы хотите там прочесть?)

Можно кстати выкладывать на гит папки со стадиями проекта, которые соответствуют вашим статьям. Т.е.:
part1: всякий код
part2: всякий код + больше кода
part3: всякий код + больше кода + спрайты
или можно просто отдельные ветки делать, но некоторые так могут потеряться.

А где гарантии, что ваш подход правильный?

Kozinaka, Лично мой, конечно же нет гарантий, но если рассуждать объективно, то всё же это лучше чем всё делать в импровизации

Правильный подход - наиболее эффективный в данной ситуации)
А в данной ситуации у нас тут соло кодер. Так что все норм.
И, мне кажется, на хгм многие геймдеверы именно солокодеры)

Любопытненько. Только вопрос а почему только UML? А вообще структурно-системный анализ реально сильно экономит время и нервы при любой разработке, и позволяет некоторые косяки увидеть ещё до создания кода.

  • 1
  • 2 (Текущая страница)
Справка