Рубрика «game engine»

Пролог

Не так давно я увидел showreel движка, который выглядит более чем конкурентно

showreel

В этой статье я максимально кратко расскажу об этом движке и косвенно сравню с прямыми конкурентами.

зарегестрироваться и скачать тут

Немного про историю :

Все началось в 2004(!) году с Александра Запрягаева и его opensource проекта
В 2010 году вышел Heaven Benchmark на основе Unigine
В 2012 вышла спорная с точки зрения геймплея, но симпатичная OilRush

OilRush

В 2017 вышла забавная индюшка

Sumoan

Текущее состояние

10 апреля 2020 вышла Community версия, которую можно, использовать если у вашей компании доход меньше 100к$ или для некомерческого проекта
Читать полностью »

Привет! Представляю вашему вниманию перевод статьи "ECS back and forth — Part 1 — Introduction" автора Michele skypjack Caini.

ECS back and forth

Часть 1 — Введение.

Когда я в первые узнал про архитектурный шаблон entity component system, я пошёл искать больше информации о нём в интернете. Но, к сожалению, тогда на эту тему не было пролито достаточно света, а ресурсов, где описывались бы разные подходы с их плюсами и минусами, не существовало. Почти каждые статья, пост, комментарии (существенная их доля) были об одной специфичной реализации и только слегка ссылались на другие примеры.

В этом посте я попытаюсь вас ввести в курс дела и открыть для вас несколько вводных моделей, давая некоторые советы для того, чтобы вы могли сделать свою собственную ECS.

Почему я должен использовать ECS?

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

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

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

Читать полностью »

image

Введение

Цель этого проекта — создание клона движка DOOM, использующего ресурсы, выпущенные вместе с Ultimate DOOM (версия со Steam).

Он будет представлен в виде туториала — я не хочу добиваться в коде максимальной производительности, а просто создам работающую версию, и позже начну её улучшать и оптимизировать.

У меня нет опыта создания игр или игровых движков, и мало опыта в написании статей, поэтому можете предлагать свои изменения или даже полностью переписать код.

Вот список ресурсов и ссылок.

Книга Game Engine Black Book: DOOM Фабьена Санглара. Одна из лучших книг по внутреннему устройству DOOM.

Doom Wiki

Исходный код DOOM

Исходный код Chocolate Doom
Читать полностью »

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

image
Читать полностью »

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

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

//обновления данных, полученных с устройств ввода
cotrols->Update()
...
void Player::Move()
{
  if (controls->MouseButonPressed(0))
  {
     ...
  }

  if (controls->KeyPressed(KEY_SPACE))
  {
     ... 
  }

  if (controls->JoystickButtonPressed(0))
  {
     ...
  }
}

Что меня не устраивает в таком подходе? Во-первых, если мы хотим считать данные с конкретного устройства, например джойстика, то мы используем методы, которые получают данные от определенного устройства. Во-вторых, в коде получаем хардкод, т.е. прямо в игровом коде идет опрос конкретной клавиши и у конкретного устройства. Это не хорошо, потому что позднее, чтобы сделать переопределение клавиш через игровое меню, надо будет все подобное вычищать и делать некую подсистему ремапинга, с возможностью переопределять биндинг клавиш на лету. Таким образом, с самой простой реализацией не все так хорошо.

Что можно предложить для решения проблемы?
Читать полностью »

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

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

//обновления данных, полученных с устройств ввода
cotrols->Update()
...
void Player::Move()
{
  if (controls->MouseButonPressed(0))
  {
     ...
  }

  if (controls->KeyPressed(KEY_SPACE))
  {
     ... 
  }

  if (controls->JoystickButtonPressed(0))
  {
     ...
  }
}

Что меня не устраивает в таком подходе? Во-первых, если мы хотим считать данные с конкретного устройства, например джойстика, то мы используем методы, которые получают данные от определенного устройства. Во-вторых, в коде получаем хардкод, т.е. прямо в игровом коде идет опрос конкретной клавиши и у конкретного устройства. Это не хорошо, потому что позднее, чтобы сделать переопределение клавиш через игровое меню, надо будет все подобное вычищать и делать некую подсистему ремапинга, с возможностью переопределять биндинг клавиш на лету. Таким образом, с самой простой реализацией не все так хорошо.

Что можно предложить для решения проблемы?
Читать полностью »

Ищем ошибки в игровом движке Xenko - 1

Движков с открытым исходным кодом, написанных на C++, куда больше, чем аналогичных движков, написанных на C#. Но есть исключения. Xenko – один из движков, написанных на C# и имеющих открытый исходный код. О том, что же интересного удалось найти в коде этого движка, будет рассказано в этой статье.
Читать полностью »

Посмотрел хабр, и увидел что очень мало статей по замечательному конструктору/движку игр Game Maker Studio.

Решил составить обзор новой версии Game Maker Studio (1.3), да и самого движка в целом, попытаюсь как можно более подробно осветить возможности движка.

Извиняюсь заранее за возможный не полный обзор, это мой первый обзор.

Описание

Game Maker Studio — кроссплатформенный конструктор/движок игр с легким освоением и подробной документацией.

Game Maker Studio предлагает интуитивно понятный и простой в использовании Drag-и-Drop (называется «DnD» теперь) Интерфейс «значки действий», которые позволят вам начать создавать свои собственные игры очень быстро. Вы можете импортировать и создавать образы и звуки для использования их в игре, а затем мгновенно увидеть результаты ваших действий при нажатии на кнопку. Следует отметить, что GameMaker: Studio заточен на двумерные игры, (но имеется так же базовая поддержка работы с 3d).

C помощью D&D любой человек без знаний программирования может создать простенькую игру, на подобии Марио или Тетриса.

Для более сложных игр, типо Heroes 3 или Diablo имеется встроенный язык программирования GML. Который легок в освоении, достаточно гибкий, и имеет около 1000 функций.
Читать полностью »

Moai SDK 1.5 — кроссплатформенный 2д игровой движок
Сегодня я хочу рассказать об одном малоизвестном игровом движке, который мы используем уже год для кроссплатформенной разработки мобильных игр. Для 2д он нас полностью устраивает, а единственным конкурентом может быть только Unity3d из-за своего редактора. Отсутствие должного внимания к MOAI SDK, очевидно, связано с высоким порогом входа — сами разработчики (Zipline Games) позиционируют свой продукт как «The mobile platform for pro game developers», хотя разобравшись с установкой и настройкой окружения можно очень быстро и просто клепать игры на Lua.
Читать полностью »

Epic выпустили Unreal Engine 4 с исходниками по подписке за $19

Совсем недавно я получил письмо от Epic где собственно сообщается, что они делают доступной всем
Unreal Engine 4 по подписке за $19 в месяц для разработки под PC, Mac, iOS, и Android, с условием оплаты 5% от суммы продаж.
И главное, доступны исходники на C++ которые будут
распространятся через github (хотя также можно использовать и бинарную версию).
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js