Comments 38
У вас не определено, что есть «идеальный» игровой движок в вашем понимании. Мотивация разработки? А так же область его применения? Насколько понял — web?
> Сначала мы придумаем и напишем 2-3 типовых игры на «идеальном» движке, т.е. сначала будет создано само приложение, а уже потом под его код будет писаться движок.
То есть пытаетесь создать конструктор шаблонных игр?
> Сначала мы придумаем и напишем 2-3 типовых игры на «идеальном» движке, т.е. сначала будет создано само приложение, а уже потом под его код будет писаться движок.
То есть пытаетесь создать конструктор шаблонных игр?
идея немного утопична, создать движок под любой тип распространенных в веб 2d игр. (я понимаю что такую мультикомбайность очень сложно создать, но к идеалу стремится буду)
т.е. при разработке учесть и заложить все основные необходимые программистам возможности и методы.
только упаковать все это в удобный и логичный для использования и понимания механизм.
т.е. при разработке учесть и заложить все основные необходимые программистам возможности и методы.
только упаковать все это в удобный и логичный для использования и понимания механизм.
Присмотритесь к реализации пакета javax.microedition.lcdui.game в Java, например. Выпилив некоторые части и допилив другие — мы получим идеальный движок.
Я как раз этим занимаюсь. Правда, пишу на TypeScript, ввиду отсутствия углубленных знаний по JavaScript.
Идея хорошая, удивлён низкому рейтингу статьи. Готов даже помочь в реализации.
Такой подход имеет право на жизнь, чем то похоже на Test-driven development. В университете заставляли делать курсовую по Архитекутре ЭВМ таким же образом, сначала пишем идеальные программы с блок-схемами, потом для этого идеального кода проектируем архитектуру. Из опыта написания этого же курсача вынес, что идеальный код потом может привести к очень неэффективной реализации самого движка или сделать эту реализацию вообще нереальной. Как думаете избегать этих проблем? Будем в конце концов подгонять «идеальный» код игр под реалити движка?
по опыту могу сказать, будут подгонки и туда и туда, не забываем что есть такие вещи как производительность и особенности языка.
однако хочется свести к минимуму изменение «идеального» кода.
ну и не зря же я обратился к сообществу) 1 голова хорошо, а много лучше)
однако хочется свести к минимуму изменение «идеального» кода.
ну и не зря же я обратился к сообществу) 1 голова хорошо, а много лучше)
Есть важное отличие — при TDD пишешь кучу неготивных тестов и ассертов из-за которых отвлекаешься от задачи и замыливается архитектура.
А остальная часть вашего вопроса решается опытом, грамотно расставленными точками входа и управляемыми зависимостями. Да и никто не мешает по ходу модифицировать подобные вишлисты.
А остальная часть вашего вопроса решается опытом, грамотно расставленными точками входа и управляемыми зависимостями. Да и никто не мешает по ходу модифицировать подобные вишлисты.
при TDD пишешь кучу неготивных тестов
А зачем?
из-за которых отвлекаешься от задачи
В смысле — отвлекаешься? Тесты и есть представление задачи.
замыливается архитектура.
В чем это выражается?
>>А зачем?
Чтобы не получить приложение работающее только по четвергам выпадающим на новолуние. Да и вообще написание теста начинается с красного, потом пишутся зелёные, чтобы быть уверенным что мы что-то протестировали.
>>В смысле — отвлекаешься? Тесты и есть представление задачи.
Задачей является построение архитектуры и апи приложения, а не одновременная проверка его работоспособности, которая должна быть но позже.
>>В чем это выражается?
В том, что помимо проверяемого кода у нас получается в разы больше кода для тестирования — куча полезных ассертов тестирующих сам код, неготивные ассерты и любимые моки. Это не мешает и можно использовать как документацию, но лишь к готовому коду, а когда создаёшь архитектуру — это ад.
Чтобы не получить приложение работающее только по четвергам выпадающим на новолуние. Да и вообще написание теста начинается с красного, потом пишутся зелёные, чтобы быть уверенным что мы что-то протестировали.
>>В смысле — отвлекаешься? Тесты и есть представление задачи.
Задачей является построение архитектуры и апи приложения, а не одновременная проверка его работоспособности, которая должна быть но позже.
>>В чем это выражается?
В том, что помимо проверяемого кода у нас получается в разы больше кода для тестирования — куча полезных ассертов тестирующих сам код, неготивные ассерты и любимые моки. Это не мешает и можно использовать как документацию, но лишь к готовому коду, а когда создаёшь архитектуру — это ад.
Да и вообще написание теста начинается с красного, потом пишутся зелёные, чтобы быть уверенным что мы что-то протестировали.
Вы путаете «негативный» (т.е., проверяющий не-happy-path) тест с «красным» (т.е., тупо не проходящим).
Задачей является построение архитектуры и апи приложения
Нет. Задачей является построение приложения, удовлетворяющего требованиям.
(А построение архитектуры и API — это то, что вам хотелось бы делать. Как и мне.)
а когда создаёшь архитектуру — это ад.
Архитектуру проще всего создавать на бумажке.
Более того, опыт показывает, что практически любая архитектура приложения в процессе разработки меняется. Менять ее без тестового покрытия, конечно, можно, но очень смело.
Вы занимаетесь софистикой. Я отвечал на чёткие вопросы, а вы пригаете из стороны в сторону. Объяснил объективные причины из за чего появляется посторонний код, который мне мешает. А вы занялись инсинуацими о моих личных знаниях (красные тесты), жонглирования словами (конкретный этап построение архитектуры, заменили эпичным — результатом) и прекрасно завершили ответив на обзац о лишнем коде, так словно речь шла о инструменте.
Кстати, вот именно, на бумаге или белой доске тесты не погоняешь, это ещё один их минус.
Ну и абзац о изменениях, которые действительно без тестов проблематичны. Но собственно построение архитектуры без tdd, вовсе не обозначает что тесты вовсе писать не надо. Просто МНЕ это делать проще отдельно от этапа проектирования.
Кстати, вот именно, на бумаге или белой доске тесты не погоняешь, это ещё один их минус.
Ну и абзац о изменениях, которые действительно без тестов проблематичны. Но собственно построение архитектуры без tdd, вовсе не обозначает что тесты вовсе писать не надо. Просто МНЕ это делать проще отдельно от этапа проектирования.
Вы просто почему-то игнорируете тот факт, что TDD — это подход к построению приложения целиком, а не к конкретному этапу.
По-моему, это минус не тестов, а доски, вы не находите?
Я не спорю с тем, что вам что-то проще. Но не надо распространять свой опыт на всех. У TDD есть объективные плюсы, равно как и объективные минусы.
Кстати, вот именно, на бумаге или белой доске тесты не погоняешь, это ещё один их минус.
По-моему, это минус не тестов, а доски, вы не находите?
Просто МНЕ это делать проще отдельно от этапа проектирования.
Я не спорю с тем, что вам что-то проще. Но не надо распространять свой опыт на всех. У TDD есть объективные плюсы, равно как и объективные минусы.
Вам туда GamDev,ru
Ну или хотябы в вопросы ответы
Почему это стало постом непонятно
О идеальности — идеального кода не бывает, бывает или удобный или быстрый код.
Разжую: быстрый код требует понимания или даст ошибку, удобный требует использования но медленный так как оберегает вас от ошибок =)
P.S. код вам никто не даст, это было бы совсем просто и движков как ваш, идеальных, в мире былобы как грязи, один идеальнее другого. Концепт движка нельзя спросить у интернетов, вы должны предложить его сами и вы также должны будете доказать его эффективность.
Ну или хотябы в вопросы ответы
Почему это стало постом непонятно
О идеальности — идеального кода не бывает, бывает или удобный или быстрый код.
Разжую: быстрый код требует понимания или даст ошибку, удобный требует использования но медленный так как оберегает вас от ошибок =)
P.S. код вам никто не даст, это было бы совсем просто и движков как ваш, идеальных, в мире былобы как грязи, один идеальнее другого. Концепт движка нельзя спросить у интернетов, вы должны предложить его сами и вы также должны будете доказать его эффективность.
этим я и собираюсь заняться)
от сообщества, если заинтересует, я жду идеи как по реализации конкретно движка (когда будет рабочий прототип), так и улучшения удобства его эксплуатации.
так же интересно посмотреть как бы вы написали игру на своем «идеально» движке.
от сообщества, если заинтересует, я жду идеи как по реализации конкретно движка (когда будет рабочий прототип), так и улучшения удобства его эксплуатации.
так же интересно посмотреть как бы вы написали игру на своем «идеально» движке.
Зависит от игры например у вас лодерунер на 1 экран, тайлы одного размера, анимация из 3х кадров, для этого движок вообще ненужен.
Если это скроллер, тут потребуется камера и отсечение невидимых объектов, задача также усложница если размеры тайлов разные
Далее если в игре есть сложная анимация, например огромный робот паук с хвостом сороконожкой, тут потребуется разворот тайла, древовидная структура модели, расчет колизии (поподание в этого зверя)
Игра без физики это не игра, если все это добавить к нашему паучку полчится довольно тяжолый код на котором естественно можно написать лодерунер на 1 экран, но возникает вопрос а стоит ли…
Если хотите совет взгляните на то как работает с граф объектами ActionScript в Flash, это позволит вам создать не идеальный но всеже интересный код.
Если это скроллер, тут потребуется камера и отсечение невидимых объектов, задача также усложница если размеры тайлов разные
Далее если в игре есть сложная анимация, например огромный робот паук с хвостом сороконожкой, тут потребуется разворот тайла, древовидная структура модели, расчет колизии (поподание в этого зверя)
Игра без физики это не игра, если все это добавить к нашему паучку полчится довольно тяжолый код на котором естественно можно написать лодерунер на 1 экран, но возникает вопрос а стоит ли…
Если хотите совет взгляните на то как работает с граф объектами ActionScript в Flash, это позволит вам создать не идеальный но всеже интересный код.
спасибо за советы, учту.
по делу:
я планирую идти от простого к сложному, наращивать функционал и возможности от версии к версии
заявленный минимум:
Работа со сценами — не попадающие в окно отрезается, можно установить как свои размеры так и сдвиги
Объекты сцены — дочерние элементы сцены, это сами игровые объекты, могут быть произвольными на основе parrentа
поддерживается переназначение обработчиков событий
события:
функции обработчики событий
eventClick, eventDblClick, eventHover, eventKeyX — понятно
eventCollision — столкновение с объектом той же маски
collisionFlagBottom, collisionFlagLeft — и т.д. флаги коллизий по сторонам
простейшая физика
gravitati = new Vec2(1, 0) или false если отключена
если не переназначать события, то срабатывают события по умолчанию
по делу:
я планирую идти от простого к сложному, наращивать функционал и возможности от версии к версии
заявленный минимум:
Работа со сценами — не попадающие в окно отрезается, можно установить как свои размеры так и сдвиги
Объекты сцены — дочерние элементы сцены, это сами игровые объекты, могут быть произвольными на основе parrentа
поддерживается переназначение обработчиков событий
события:
функции обработчики событий
eventClick, eventDblClick, eventHover, eventKeyX — понятно
eventCollision — столкновение с объектом той же маски
collisionFlagBottom, collisionFlagLeft — и т.д. флаги коллизий по сторонам
простейшая физика
gravitati = new Vec2(1, 0) или false если отключена
если не переназначать события, то срабатывают события по умолчанию
А начните лучше с идеального кода игрового цикла. Я вот так и не смог нагуглить хороший туториал по игровому циклу для JS. Либо народ делает тупо через setInterval, либо просто дают код, без объяснений почему сделано так или иначе.
можно немного поподробнее об вопросе, какой именно цикл вы имеете в веду, отвечающий за рендер?
Вот что-то типа такого:
while (true) {
checkInput();
updateLogic();
renderGame();
}на текущий момент идея такая:
1. воздействие на мир (все внутри игры строится на основе векторов)
2. применение изменений
3. обработка исключений (например коллизии) — возможно вынос в отдельный слой с созданием премитивов, для облегчения определений коллизии
4. рисуем
такт
1. воздействие на мир (все внутри игры строится на основе векторов)
2. применение изменений
3. обработка исключений (например коллизии) — возможно вынос в отдельный слой с созданием премитивов, для облегчения определений коллизии
4. рисуем
такт
Или что-то типа такого.
«любой тип распространенных в веб 2d игр» — это, скажем, там будут пакеты towerdefence, match3, hiddenobject и т.д.?
нет, хочется реализовать 1 единый пакет, возможно с механизмом плагинов
Мне кажется автор имел в виду игры, основанные на тайлах (mario, pacman и т.д), и игры основанные на физике (cut the rope, angry birds), игры с изометрией может (хотя это тоже тайлы по идее). Tower defence, match3 и hidden object — это тайлы по сути.
На по след ок.
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. Там вам и тайловый движок и правильная перерисовка динамических объектов и спрайтовые анимации, гексагональный и изометрический движки, мощное смещение слоёв. И нету тех детский болезней, которые есть в вашем будущем продукте)
Sign up to leave a comment.
just2d — создаем «идеальный» игровой движок. Шаг 1