Рубрика «Gamedev» - 27

Как расправиться с читерами и не переписать весь код - 1

Несколько лет назад появился прототип игры War Robots (тогда она еще называлась Walking War Robots). Это был первый опыт Pixonic в жанре тактического PvP, поэтому многие будущие проблемы были заложены в коде изначально. Но несмотря на ряд трудностей (популярность проекта стремительно росла, небольшая команда не могла полностью изменить архитектуру игры в краткие сроки), нам в итоге удалось свести к минимуму количество читеров, а также исправить другие недостатки оригинального кода. Расскажу немного подробнее.Читать полностью »

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

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

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

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

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

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

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

larian_dublin_logo Привет! Это снова Larian Studios. Уф, у нас прошёл релиз, и теперь наконец-то появилось время продолжить делиться с вами нашим опытом и наработками.

Сегодня я расскажу о самом главном инструменте, с помощью которого родилось уже 4 проекта — о кофемашине внутреннем редакторе игры. Редактор доступен в ограниченном (для моддеров и игроков) виде в Steam/GoG, поэтому каждый, кто приобрел игру, может скачать его и попробовать бесплатно.

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

Ну и еще расскажу, чем занимаются Tools Programmer в нашей студии.
Читать полностью »

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

Реактивное программирование — это всё то же самое, только на стероидах, то есть мы можем создавать потоки данных всего. И также наблюдать за ними и реагировать. Update, OnCollisionEnter, Coroutine, Event, Mouse input, Keyboard input, Joystick input — все это потоки.
Все что нас окружает это потоки.

image

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

Russian AI Cup 2017 — отчет о бета-тесте, старт чемпионата. Хотели StarCraft, получили странный Total War - 1

Седьмого ноября официально стартовала неделя бета-теста Russian Ai Cup 2017. Чемпионат ежегодный, и в этом году мы решили предложить участникам проект под названием CodeWars — конкурс по программированию ботов для игры, которую сами участники сходу окрестили «симулятором игрока в RTS». Бета-тест подошел к концу, чемпионат официально стартовал, и под катом мы хотели бы отчитаться, поделиться новостями о том, что же мы теперь можем предложить. Ну и еще раз зазвать всех поучаствовать, не без этого конечно.

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

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

В данной статье я опишу разработку простого плагина для локализации UI Text-компонентов с возможностью динамической смены языка и редактирования текста в редакторе.
Читать полностью »

image

У всех нас есть свои слабости, которым мы можем изредка предаваться — так называемые “guilty pleasures”. Я вот, к примеру, люблю время от времени перелистывать старые игровые журналы; среди прочего, в них попадаются интересные интервью и дневники разработчиков, неторопливо закрывающие белые пятна моего незнания (которое, как и положено, границ не имеет). С пост-мортемами разговор отдельный — они повествуют о вечном, и потому абсолютно не теряют своего очарования.

imageВзять хотя бы пост-мортем Portal, опубликованный в январском выпуске журнала Game Developer за 2008 год. Благодаря ему, многие читатели впервые узнали про излюбленную методику создания игр в стенах компании Valve (да, было время, когда Valve еще делала игры): постоянными итерациями прототипов игровых механик и регулярными плей-тестами с участием новых игроков. Сегодня эта идея всем нам кажется очевидной — справедливости ради, она была известна и тогда, но не столь широко распространена — несмотря на то, что она уже успела поспособствовать появлению игр высочайшего геймплейного качества — одна Half-Life 2 чего стоит.

Еще несколько фактов из пост-мортема Portal

Оказывается, сам Portal в итоге был урезан примерно в два раза: в силу того, что неподготовленным игрокам тяжело давались те или иные уровни, разработчики регулярно убирали головоломки и заменяли их на новые. Как подсказывают завсегдатаи редактора Hammer, при прототипировании уровней Valve использует примитивы оранжевого цвета, а не серые, как все остальные — отсюда и сам этот процесс они называют не «grayboxing», а «orange boxing» (отсюда и «orange box»?..)

Другой пост-мортем, и всего одна маленькая (и невероятная) деталь: концепты дизайна основных боссов в Diablo III за время разработки переделывались по 50-60 раз. Теперь я каждый раз напоминаю себе об этом факте, когда начинают опускаться руки!

Конечно же, на многие известные игры пост-мортемов не существует. Сегодня вашему вниманию предлагается история о том, про что в пост-мортеме никто в здравом уме не расскажет.
Читать полностью »

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

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

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

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

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

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

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

Как-то для своих некоторых планов мне потребовалось сделать небольшую песочницу в 2D пространстве с базовыми возможностями:
1. Передвижение по игровому миру
2. Физика при движении, столкновения
3. Создание блоков
4. Удаление блоков
Графическое исполнение меня не беспокоило, поэтому я решил оформить все в серых тонах, выглядит это так:
image
Читать полностью »

Разработка браузерной онлайн игры без фреймворков и движков - 1

Привет!
В этом посте будет описан процесс разработки онлайн игры на чистом javascript и WebGL (без фреймворков и движков). Будут рассмотрены некоторые алгоритмы, техники рендеринга, искусственный интеллект ботов и сетевая игра. Проект является полностью опенсорсным, в конце поста будет ссылка на репозиторий.
Читать полностью »


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