Войти
ФлеймФорумПроЭкты

Движок к стратежке [смена сезонов]

Страницы: 1 2 3 4 Следующая »
#0
2:54, 31 янв. 2017
Изображение

Актуальное обсуждение начинается с #25 сообщения
+ старый нульпост: движок к тетрису

#1
12:21, 31 янв. 2017

Игра-то получилась?
Значит движок норм, достаточно хорош.

#2
13:10, 31 янв. 2017

пора писать на нём ммо

#3
13:15, 31 янв. 2017

Код не смотрел, но зачем core.delta не совсем ясно. Для отображения нужен (сглаженный) ФПС, а для игровой логики лучше таймер или что-то с фиксированной дельтой времени. Конечно фиксированную дельту легко свелосипедить на дельте, но зачем?

#4
15:25, 31 янв. 2017

Джек Аллигатор
> Модули:
Архитектура может быть самой разной, нет одной правильной и для всех.

> получить критику от сообщества
Главная критика будет от того, кто движок использует. То есть от тебя самого. Тебе удобно, быстро сделал много игр? Хороший двиг. Мало сделал, медленно делаются? Плохой двиг.

#5
15:33, 31 янв. 2017

Джек Аллигатор
> Так вот - правильно ли сделано ядро? Менеджер клавиатуры и тд? gui? Правильно
> ли я вообще распланировал архитектуру модулей, их связей, методов и тд?
У архитектуры есть вполне объективные факторы "годности".
- Легкость модификации и развития.
- Легкость использования.
- Безглючность.
Вот и смотри. Ну к примеру легкость модификации и развития можно проверить сделав перемещение фигур тетриса плавным, а не по блокам как наверное сейчас. Или заменив квадратные ячейки тетриса шестиугольными.
Если такие штуки делаются легко, без переписывания основ, то архитектура норм.

#6
23:49, 31 янв. 2017

kvakvs
kipar
122
Понятно.
Спасибо.
Буду продолжать в том же духе.

#7
14:05, 6 фев. 2017

Для тайловых игр типа тетриса я бы сделал отдельную систему для тайловых карт. 
Профит очевиден —  после тетриса с минимумом геморроя сможешь сделать импорт из  Tiled, 
или свой редактор карт приделать. А там уже и более интересные темы пойдут заодно вроде
системы коллизий / физики,  потайлового освещения и т.д.

Квады которые не привязаны к сетке,  но статичные,  тоже нужно объединять в один меш — получишь статический батчинг.

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

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

После того как разберешься с адвансед частью выведения графония, надо будет задуматься об удобстве написания игровой логики.
Нужен будет достаточно гибкий фреймворк для управления  игровыми объектами,  скорее всего у него надо будет продумать API и
отправить на съедение какому нибудь скриптовому языку, например Lua или что-то более экзотическое.

#8
14:48, 6 фев. 2017

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

#9
14:52, 6 фев. 2017

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

> Нужен будет достаточно гибкий фреймворк для управления  игровыми объектами, 
> скорее всего у него надо будет продумать API и
> отправить на съедение какому нибудь скриптовому языку, например Lua или что-то
> более экзотическое.
А вот тут я полный ноль.
Зачем вообще выносить игровую логику в скрипты? Ради ускорения разработки, чтобы не перекомпилировать двиг на каждое изменение?
Можешь посоветовать какие-нибудь простые обзорные статьи по этой теме?

#10
15:11, 6 фев. 2017

Джек Аллигатор
> Зачем вообще выносить игровую логику в скрипты?
В идеале для того чтобы сценарии писал не программист а какой-нибудь левел-дизайнер,
либо писал программист с набором скиллов именно в реализации игровой логики, а не в дебрях си++.

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

Ну и допустим у нас не просто игровой движок, а движок с редактором. Нам нужно быстро вводить функционал в игру,
сделать это можно:
    1. через скрипты(пример — юнити);   
    2. через некий графический программинг(пример — анрил и юнити).
    3. через пинание программиста движка(а не игрового программиста, потому что получается что у нас у всех программистов специализация — движок) на реализацию очередного компонента для возникшей нетипичной задачи.

Естественно, в 1 и 2 случае тоже возможно пинание движкового программиста, но этот вопрос будет возникать намного реже, потому что чаще всего можно будет справиться своими силами.

#11
15:17, 6 фев. 2017

Понятно. Спасибо.

#12
15:31, 6 фев. 2017

У движка Godot открытые исходники. Считаю этот движок неплохим. Посмотри для интереса как там делают (я тоже хочу когда-нибудь это сделать но пока не смог), заодно по модулям и структуре фреймворка возможно вопросы прояснишь

#13
16:15, 6 фев. 2017

Для 2д-движка на rust, возможно, технологии из 3д движков будут чрезмерным усложнением. Те же скрипты - по-моему в большинстве в 2д игр всего один программист, поэтому смысла в них при условии что движок и так написан на нормальном языке нет.
С другой стороны ты вроде трехмерный и собираешься делать, тогда всё ок, но имхо лучше и пример игры сразу трехмерный сделать, много ньюансов сразу выявится.

#14
16:41, 6 фев. 2017

Ого, я как-то сразу не посмотрел на каком языке игра

Страницы: 1 2 3 4 Следующая »
ФлеймФорумПроЭкты

Тема в архиве.