mushroom_queen mushroom_queen

Jusper, спасибо за комментарий! старалась писать нескучно))

Jusper Jusper

Моя любимая фаза разработки любой игры!
Отлично написано, посмеялся местами от души. Спасибо!

Jusper Jusper

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

Не вижу пока, как в такое управление впихнуть боевку.

Jusper Jusper

PallSwarrow
Что ж я поиграл. Пока это не игра про пиратов, а игра про навигацию парусами. Это скорее пока в плюс, потому что управление мне понравилось, но боюсь, что весь игровой фокус сейчас только в этом...

...
id44474404 id44474404

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

...
TheDarkestRed TheDarkestRed

Экспериментируем с рэгдолами 🎮🧟🤺🐺

lehha95 lehha95

Открыли страницу в Steam! Добавляйте в список желаемого!

https://store.steampowered.com/app/1355780/

romandviski romandviski

Спасибо, добрый человек.

Rummy_Games Rummy_Games

Доброго субботнего вечера! Сегодня мы поделимся с вами видео процесса разработки одного из противников (“Роя”) в нашей игре, в рамках #saturdayscreenshot, а также кратко делимся ЛОРом игры.

...
id44474404 id44474404

Всем привет!
Функционал авторитарного сервера продолжает восстанавливаться до уровня, который был на фотон клауде. На этой неделе стало возможным убийство мобов, и получение с них опыта, и прокачка персонажа...

...
Jusper Jusper

В GMS сильно поменялась структура функционала, но не все корректно мигрируется из старых проектов. Если тебе не критичны новинки, то переходить на него стоит только с новым проектом.

Kazirath Kazirath

Насколько я понял проще установть последнюю версию перед 2.3 и продолжить работать под ней. Новинка не стоит свеч после переделки скриптов

Kazirath Kazirath

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

...
alexprey alexprey

Учитывая то, что написано в данной статье обратно включить это не получится и придется действительно обернуть код скриптов в функции.

Кратко из документации:

  • Раньше скрипты были индивидуальными и изолированными
  • ...
  • ...
  • ...
  • ...
...
PallSwarrow PallSwarrow

Спасибо за комменты, оч приятно)
Про ссылку тупанул - пока разбираюсь с сайтом)

alexprey alexprey

Жду линк на потестить и следующий девлог о разработке)

Jusper Jusper

Если есть прототип, было бы здорово выложить на него ссылку.
Не хватает игровых скриншотов.

Jusper Jusper

Raised, оригинал на Eurogamer.
Скорее всего, ирония.

Raised Raised

Это была такая ирония или Фортнайт тогда действительно был небольшим проектом?

id44474404 id44474404

alexprey, спасибо !)

Логотип проекта 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 (Текущая страница)
Справка