Войти
ПрограммированиеФорумОбщее

Lua + C++. Правильное разделение обязанностей (2 стр)

Страницы: 1 2 3 4 Следующая »
#15
20:44, 22 дек. 2017

mr.DIMAS
Нет бреда c++. ООП, шаблонов (на самом деле я только против злоупотребления ими) и тд.


#16
20:50, 22 дек. 2017

cl /O2 /Zi /nologo /w /D WIN32 /D _HAS_EXCEPTIONS=0 /MD /MP /sdl- %include_dirs% %compile_src% /link %add_lib_dirs% %add_lib% /OUT:..\..\bin\Game.exe

Вот так собираю.

#17
20:55, 22 дек. 2017

RostislavP
Хех, а у меня шаблоны на шаблонах и шаблонами погоняют.

За что я люблю чистый Си, так это за очень быструю компиляцию. Иногда жалею что не начал писать игру на Си.

#18
21:18, 22 дек. 2017

mr.DIMAS
У MS компиляция в любом случае медленная, даже если это 2-4 секундны. И у меня если что не чистый си, некоторые возможности с++ все равно используются. Тут больше дело в том что, код сосредоточен на том что он должен делать, нежели чем на идеях и теориях о том как "нужно" писать код.

#19
21:20, 22 дек. 2017

Зачем тебе C++, он в большинстве игр не нужен. Пиши целиком на LUA. Я часто так делаю. :)

#20
23:30, 22 дек. 2017

Мне кажется lua лучше дать обязанность управление движковыми объекты и всю логику игры писать именно на луа. Интеллект, катсцены, триггеры и т.д.

#21
1:26, 23 дек. 2017

GermanAizek
И что это даст?

#22
4:11, 23 дек. 2017

mr.DIMAS
Много встречных вопросов сразу.
Например - зачем отдельный json с данными. Ведь Lua создавался как язык описания данных.
Можно завести отдельный Lua файл с похожей Lua таблицей. Но может есть GUI-редактор который умеет эти json файлы не только читать но и писать?
И т.д.
Твоя схема - здравая, но не очень ООП. Это то что я называю "C++ толкает Lua" (push со стороны C++, Lua - сервер, C++ - клиент)

Если ее придерживаться то tutorial.onSerialize - не надо.
Ты знаешь identity твоего объекта (строковое "tutorial") и можешь перебрать все ключ-значения в этой таблице,
посмотреть типы и значения, сохранить/восстановить.
https://www.lua.org/manual/5.3/manual.html#lua_next
Конечно же, это особенный сериализатор будет, отдельный от C++-ного.

#23
4:46, 23 дек. 2017

mr.DIMAS
Вообще можно делать еще так (прокинуть недостающие референсы):

function main() — точка входа
  local game = Game:new()
  game:main()
end

Game = Class()

function Game:main()
  local tutorial = Tutorial:new()
  tutorial:main()
end

Tutorial = Class()

function Tutorial:main()
  ui:printRequest(data.tutorials.controls) — мгновенно
  teach(Keys.MoveLeft) — длится
  teach(Keys.MoveRight) — длится
  ui:printRequest(data.tutorials.combat) — мгновенно
  teach(Keys.Punch) — длится
end

function teach(key)
  local stage = TutorialStage:new()
  stage.key = key
  return stage:Init()
end

TutorialStage = CspOperation:new()

function TutorialStage:Work(deltaTime)
  local hit = self.game:isKeyHit(self.key)
  if hit then
    return self.Finish
  else
    return self.Yield
  end
end

но тут нетривиально с сериализацией корутин. либы сторонние умели такое.

Промежуточное решение между твоим и CSP - замутить все на Sequential FSM.
Вместо main - централизованный onUpdate каждый кадр.
Т.е. main возвращает рутовый объект (таблицу game), C++ зовет ему onUpdate, а рутовый game раздает его дальше по иерархии ownership.

#24
5:22, 23 дек. 2017

mr.DIMAS
> Проблема во времени сборки, да. Сам я скрипты не особо люблю, как и все языки с
> динамической типизацией.
Тогда быть может лучше внедрить к себе CERN'овский Cling?
https://github.com/vgvassilev/cling
LHC и C++ - веселее вместе! Достойны друг друга.

#25
6:17, 23 дек. 2017

На C++ время сборки можно радикально сократить, если выделить интерфейсные части модулей, которые меняются крайне редко, связывать модули только через интерфейсы, не вызывать напрямую. Само собой, в "глубине самого глубокого цикла" так лучше не делать, чтобы не просадить производительность, но на макроуровне - почему бы и нет...

Ради "сокращения времени сборки" переходить на интерпретируемые языки - это уж слишком.

P.S. Помнится, преподаватель, когда жаловались на время компиляции, спрашивал - "Сколько раз вы компилируете?".
Зачем много раз компилировать? Может лучше программу сначала написать попытаться, а только потом запускать?

#26
16:15, 23 дек. 2017

Virtex
> Зачем тебе C++
Моя игра это одна большая числодробилка, ну по крайней мере физика. Поэтому на луа писать такое не вариант. Да и к тому же я не люблю языки с динамической типизацией.

loyso
> Конечно же, это особенный сериализатор будет, отдельный от C++-ного.
Поэтому я и отказался от сериализации скриптов. Подход как в Starbound не требует сохранения состояния скрипта. Однако даже там есть возможность регистрировать свои переменные (через C++-биндинги) которые все же будут сериализоваться, но на стороне C++. А при десериализации их можно получить по имени.

> Тогда быть может лучше внедрить к себе CERN'овский Cling?
Боюсь что мододелы будут страдать при создании модов на C++. Вообще я уже отказался от идеи переноса части кода на луа, оставлю только возможность моддинга. А медленную компиляцию я как-нибудь переживу (немного оптимизировал уже скорость компиляции).

Zab
> Ради "сокращения времени сборки" переходить на интерпретируемые языки - это уж
> слишком.
Ага, я уже понял что это шальная идея.

> Зачем много раз компилировать?
Меняешь пару констант и вот ты опять сидишь и ждешь пока скомпилится. На самом деле тут я сам виноват, по хорошему все геймплейные константы должны быть где-нибудь в json-файлике собраны.

#27
18:21, 23 дек. 2017

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

#28
18:22, 23 дек. 2017

RostislavP
Ты представь если у тебя крупный проект и тебе надо всю механику описать, в этом и помогает луа, да и еще с луа джит в реальном времени можешь делать.

#29
19:40, 23 дек. 2017

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

Страницы: 1 2 3 4 Следующая »
ПрограммированиеФорумОбщее

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