Флейм
GameDev.ru / Флейм / Форум / Движок к стратежке [смена сезонов]

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

Поделиться

Страницы: 1 2 3 4 Следующая

Джек АллигаторПостоялецwww31 янв. 20172:54#0
Изображение
Актуальное обсуждение начинается с #25 сообщения
+ старый нульпост: движок к тетрису

Правка: 17 сен. 2017 12:35

kvakvsПостоялецwww31 янв. 201712:21#1
Игра-то получилась?
Значит движок норм, достаточно хорош.
ПорядокПостоялецwww31 янв. 201713:10#2
пора писать на нём ммо
kiparПостоялецwww31 янв. 201713:15#3
Код не смотрел, но зачем core.delta не совсем ясно. Для отображения нужен (сглаженный) ФПС, а для игровой логики лучше таймер или что-то с фиксированной дельтой времени. Конечно фиксированную дельту легко свелосипедить на дельте, но зачем?
122Постоялецwww31 янв. 201715:25#4
Джек Аллигатор
> Модули:
Архитектура может быть самой разной, нет одной правильной и для всех.

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

122Постоялецwww31 янв. 201715:33#5
Джек Аллигатор
> Так вот - правильно ли сделано ядро? Менеджер клавиатуры и тд? gui? Правильно
> ли я вообще распланировал архитектуру модулей, их связей, методов и тд?
У архитектуры есть вполне объективные факторы "годности".
- Легкость модификации и развития.
- Легкость использования.
- Безглючность.
Вот и смотри. Ну к примеру легкость модификации и развития можно проверить сделав перемещение фигур тетриса плавным, а не по блокам как наверное сейчас. Или заменив квадратные ячейки тетриса шестиугольными.
Если такие штуки делаются легко, без переписывания основ, то архитектура норм.
Джек АллигаторПостоялецwww31 янв. 201723:49#6
kvakvs
kipar
122
Понятно.
Спасибо.
Буду продолжать в том же духе.
MadwareПостоялецwww6 фев. 201714:05#7
Для тайловых игр типа тетриса я бы сделал отдельную систему для тайловых карт. 
Профит очевиден —  после тетриса с минимумом геморроя сможешь сделать импорт из  Tiled, 
или свой редактор карт приделать. А там уже и более интересные темы пойдут заодно вроде
системы коллизий / физики,  потайлового освещения и т.д.

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

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

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

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

Правка: 6 фев. 2017 14:45

MadwareПостоялецwww6 фев. 201714:48#8
Самым логичным действием считаю поход в мир какого-нибудь MonoGame, и анализ того как выстроена работа.
Понять что там удобно для тебя а что нет, и почему.
Джек АллигаторПостоялецwww6 фев. 201714:52#9
Madware, спасибо за советы, но я стараюсь не заниматься преждевременной оптимизацией.
Первоочередная цель - получить играбельный билд с максимально простым кодом.

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

Правка: 6 фев. 2017 14:53

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

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

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

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

Правка: 6 фев. 2017 15:12

Джек АллигаторПостоялецwww6 фев. 201715:17#11
Понятно. Спасибо.
MadwareПостоялецwww6 фев. 201715:31#12
У движка Godot открытые исходники. Считаю этот движок неплохим. Посмотри для интереса как там делают (я тоже хочу когда-нибудь это сделать но пока не смог), заодно по модулям и структуре фреймворка возможно вопросы прояснишь

Правка: 6 фев. 2017 15:31

kiparПостоялецwww6 фев. 201716:15#13
Для 2д-движка на rust, возможно, технологии из 3д движков будут чрезмерным усложнением. Те же скрипты - по-моему в большинстве в 2д игр всего один программист, поэтому смысла в них при условии что движок и так написан на нормальном языке нет.
С другой стороны ты вроде трехмерный и собираешься делать, тогда всё ок, но имхо лучше и пример игры сразу трехмерный сделать, много ньюансов сразу выявится.

Правка: 6 фев. 2017 16:15

MadwareПостоялецwww6 фев. 201716:41#14
Ого, я как-то сразу не посмотрел на каком языке игра

Правка: 6 фев. 2017 16:42

Страницы: 1 2 3 4 Следующая

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

2001—2017 © GameDev.ru — Разработка игр