DrNemo22 дек 2012 в 09:11

just2d — создаем «идеальный» игровой движок. Шаг 1

4 мин

11K

Canvas * Разработка игр *

-4

Комментарии 38

nick0x01 22 дек 2012 в 09:22

У вас не определено, что есть «идеальный» игровой движок в вашем понимании. Мотивация разработки? А так же область его применения? Насколько понял — web?

> Сначала мы придумаем и напишем 2-3 типовых игры на «идеальном» движке, т.е. сначала будет создано само приложение, а уже потом под его код будет писаться движок.

То есть пытаетесь создать конструктор шаблонных игр?

DrNemo 22 дек 2012 в 09:27

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

krovatti 22 дек 2012 в 10:05

Присмотритесь к реализации пакета javax.microedition.lcdui.game в Java, например. Выпилив некоторые части и допилив другие — мы получим идеальный движок.

krovatti 22 дек 2012 в 10:06

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

OlegTar 24 мар 2013 в 19:07

Идея хорошая, удивлён низкому рейтингу статьи. Готов даже помочь в реализации.

TheShock 25 мар 2013 в 13:30

Потому что:
1. Реализация из топика отвратительная
2. Уже есть намного более качественные решения

NCrashed 22 дек 2012 в 09:44

Такой подход имеет право на жизнь, чем то похоже на Test-driven development. В университете заставляли делать курсовую по Архитекутре ЭВМ таким же образом, сначала пишем идеальные программы с блок-схемами, потом для этого идеального кода проектируем архитектуру. Из опыта написания этого же курсача вынес, что идеальный код потом может привести к очень неэффективной реализации самого движка или сделать эту реализацию вообще нереальной. Как думаете избегать этих проблем? Будем в конце концов подгонять «идеальный» код игр под реалити движка?

DrNemo 22 дек 2012 в 09:47

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

ну и не зря же я обратился к сообществу) 1 голова хорошо, а много лучше)

AmdY 22 дек 2012 в 10:02

Есть важное отличие — при TDD пишешь кучу неготивных тестов и ассертов из-за которых отвлекаешься от задачи и замыливается архитектура.
А остальная часть вашего вопроса решается опытом, грамотно расставленными точками входа и управляемыми зависимостями. Да и никто не мешает по ходу модифицировать подобные вишлисты.

lair 22 дек 2012 в 10:23

при TDD пишешь кучу неготивных тестов

А зачем?

из-за которых отвлекаешься от задачи

В смысле — отвлекаешься? Тесты и есть представление задачи.

замыливается архитектура.

В чем это выражается?

AmdY 22 дек 2012 в 10:37

>>А зачем?
Чтобы не получить приложение работающее только по четвергам выпадающим на новолуние. Да и вообще написание теста начинается с красного, потом пишутся зелёные, чтобы быть уверенным что мы что-то протестировали.

>>В смысле — отвлекаешься? Тесты и есть представление задачи.
Задачей является построение архитектуры и апи приложения, а не одновременная проверка его работоспособности, которая должна быть но позже.

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

lair 22 дек 2012 в 10:42

Да и вообще написание теста начинается с красного, потом пишутся зелёные, чтобы быть уверенным что мы что-то протестировали.

Вы путаете «негативный» (т.е., проверяющий не-happy-path) тест с «красным» (т.е., тупо не проходящим).

Задачей является построение архитектуры и апи приложения

Нет. Задачей является построение приложения, удовлетворяющего требованиям.

(А построение архитектуры и API — это то, что вам хотелось бы делать. Как и мне.)

а когда создаёшь архитектуру — это ад.

Архитектуру проще всего создавать на бумажке.

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

AmdY 22 дек 2012 в 10:59

Вы занимаетесь софистикой. Я отвечал на чёткие вопросы, а вы пригаете из стороны в сторону. Объяснил объективные причины из за чего появляется посторонний код, который мне мешает. А вы занялись инсинуацими о моих личных знаниях (красные тесты), жонглирования словами (конкретный этап построение архитектуры, заменили эпичным — результатом) и прекрасно завершили ответив на обзац о лишнем коде, так словно речь шла о инструменте.

Кстати, вот именно, на бумаге или белой доске тесты не погоняешь, это ещё один их минус.

Ну и абзац о изменениях, которые действительно без тестов проблематичны. Но собственно построение архитектуры без tdd, вовсе не обозначает что тесты вовсе писать не надо. Просто МНЕ это делать проще отдельно от этапа проектирования.

lair 22 дек 2012 в 11:04

Вы просто почему-то игнорируете тот факт, что TDD — это подход к построению приложения целиком, а не к конкретному этапу.

Кстати, вот именно, на бумаге или белой доске тесты не погоняешь, это ещё один их минус.

По-моему, это минус не тестов, а доски, вы не находите?

Просто МНЕ это делать проще отдельно от этапа проектирования.

Я не спорю с тем, что вам что-то проще. Но не надо распространять свой опыт на всех. У TDD есть объективные плюсы, равно как и объективные минусы.

AmdY 22 дек 2012 в 11:14

Так в начальном посте я раз и говорил о объективном минусе TDD и про то, что решающим является личный опыт.

lair 22 дек 2012 в 17:36

Это вы об этом?

кучу неготивных тестов и ассертов из-за которых отвлекаешься от задачи и замыливается архитектура.

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

MrGobus 22 дек 2012 в 09:54

Вам туда GamDev,ru
Ну или хотябы в вопросы ответы

Почему это стало постом непонятно

О идеальности — идеального кода не бывает, бывает или удобный или быстрый код.

Разжую: быстрый код требует понимания или даст ошибку, удобный требует использования но медленный так как оберегает вас от ошибок =)

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

DrNemo 22 дек 2012 в 10:00

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

MrGobus 22 дек 2012 в 10:22

Зависит от игры например у вас лодерунер на 1 экран, тайлы одного размера, анимация из 3х кадров, для этого движок вообще ненужен.

Если это скроллер, тут потребуется камера и отсечение невидимых объектов, задача также усложница если размеры тайлов разные

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

Игра без физики это не игра, если все это добавить к нашему паучку полчится довольно тяжолый код на котором естественно можно написать лодерунер на 1 экран, но возникает вопрос а стоит ли…

Если хотите совет взгляните на то как работает с граф объектами ActionScript в Flash, это позволит вам создать не идеальный но всеже интересный код.

DrNemo 22 дек 2012 в 10:36

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

заявленный минимум:
Работа со сценами — не попадающие в окно отрезается, можно установить как свои размеры так и сдвиги

Объекты сцены — дочерние элементы сцены, это сами игровые объекты, могут быть произвольными на основе parrentа
поддерживается переназначение обработчиков событий

события:
функции обработчики событий
eventClick, eventDblClick, eventHover, eventKeyX — понятно
eventCollision — столкновение с объектом той же маски

collisionFlagBottom, collisionFlagLeft — и т.д. флаги коллизий по сторонам

простейшая физика
gravitati = new Vec2(1, 0) или false если отключена

если не переназначать события, то срабатывают события по умолчанию

MrGobus 22 дек 2012 в 12:41

Я планирую идти от простого к сложному

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

DrNemo 22 дек 2012 в 12:45

если сразу взяться за новый Source, то в одиночку не вытянуть)
хотя гибкость и масштабируемость не отменяется)

GreatRash 22 дек 2012 в 10:20

А начните лучше с идеального кода игрового цикла. Я вот так и не смог нагуглить хороший туториал по игровому циклу для JS. Либо народ делает тупо через setInterval, либо просто дают код, без объяснений почему сделано так или иначе.

DrNemo 22 дек 2012 в 10:22

можно немного поподробнее об вопросе, какой именно цикл вы имеете в веду, отвечающий за рендер?

GreatRash 22 дек 2012 в 10:24

Вот что-то типа такого:

while (true) {
  checkInput();
  updateLogic();
  renderGame();
}

DrNemo 22 дек 2012 в 10:41

на текущий момент идея такая:
1. воздействие на мир (все внутри игры строится на основе векторов)
2. применение изменений
3. обработка исключений (например коллизии) — возможно вынос в отдельный слой с созданием премитивов, для облегчения определений коллизии
4. рисуем
такт

OpenMinded 22 дек 2012 в 12:10

Или что-то типа такого.

virtualtoy 22 дек 2012 в 11:38

«любой тип распространенных в веб 2d игр» — это, скажем, там будут пакеты towerdefence, match3, hiddenobject и т.д.?

DrNemo 22 дек 2012 в 11:44

нет, хочется реализовать 1 единый пакет, возможно с механизмом плагинов

GreatRash 22 дек 2012 в 11:52

Уже есть похожий опенсорсный 2d-движок — Crafty.js. Поддерживает тайлы, физику, спрайты, канвас и/или DOM, события и плагины.

virtualtoy 22 дек 2012 в 11:52

Просто интересно, какой уровень абстракции собираетесь реализовывать. Уровень конкретного жанра — это, наверное, перебор. А в качестве рендера что используете?

GreatRash 22 дек 2012 в 11:48

Мне кажется автор имел в виду игры, основанные на тайлах (mario, pacman и т.д), и игры основанные на физике (cut the rope, angry birds), игры с изометрией может (хотя это тоже тайлы по идее). Tower defence, match3 и hidden object — это тайлы по сути.

DrNemo 22 дек 2012 в 11:57

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

ping 22 дек 2012 в 12:53

На по след ок.

DrNemo 22 дек 2012 в 13:05

спасибо, но лучше в личку

TheShock 22 дек 2012 в 14:40

Engine.setResurs

О боги, нет! Resources!

Что за привычка дублировать согласные в названиях свойств? parrent, summ

Почему иногда название метода начинается с маленькой буквы, а иногда — с большой?

this.parrent.vec2 = this.parrent.vec2.summ(new Vec2(-2, 0))

Зачем переопределять переменную, если объекты в JS можно изменять напрямую. Что за название vec2?

 // переназначение events с parrent
    this.eventKeyUp = function(){ // стрелка вверх
        this.parrent.vec2 = this.parrent.vec2.summ(new Vec2(-2, 0))
    }
    this.eventKeyLeft = function(){ // в лево
        this.parrent.vec2 = this.parrent.vec2.summ(new Vec2(0, -1))
    }
    this.eventKeyRight = function(){ // в право
        this.parrent.vec2 = this.parrent.vec2.summ(new Vec2(0, 1))
    }

var velocity = this.velocity;

keyboard.events.add({
  'aup': function () {
    velocity.move(new Point(-2, 0));
  },
  'aleft': function () {
    velocity.move(new Point( 0,-0));
  },
  'aright': function () {
    velocity.move(new Point( 0, 1));
  },
});

separator — id html элемента canvas

Почему separator? Это ведь «разделитель». При чём тут он?

Ну и вообще — всё, что вы хотите создать, все ваши цели уже есть в LibCanvas. Там вам и тайловый движок и правильная перерисовка динамических объектов и спрайтовые анимации, гексагональный и изометрический движки, мощное смещение слоёв. И нету тех детский болезней, которые есть в вашем будущем продукте)

pascualle 16 мая 2013 в 17:33

Паша, ты как всегда жесток.
Насчет LibCanvas — абсолютно справедливо, подтверждаю. Люди, очень рекомендую использовать.

TheShock 16 мая 2013 в 19:45

Правда жестковато получилось? Я не хотел(

Зарегистрируйтесь на Хабре, чтобы оставить комментарий