- foxes
- Постоялец
codingmonkey
Так или иначе, если планируется готовое решение физики, то оно будет в надстройках над движком, а не в его основе. Звук и сеть должны быть в каком-то виде в движке. Но какое-то законченное готовое решение не планируется, потому как его сложно сделать универсальным. Скорее что-то вроде получение контента по Post/Get запросам + голые сокеты без надстроек (но кросс-платформенные). По звукам надо что-то более-менее готовое и законченное.
>то оно будет в надстройках над движком
Что это еще за надстройка? По-моему двиг и есть сумма всех его составляющих. Это не графический двиг сам по себе, этих фрейворков туевы кучи уже, чем твой будет лучше? Нужно именно комплексное решение, а не ...ня на палочке.
>потому как его сложно сделать универсальным.
Все как-то делают. На винде виндовозный звук, во всех остальных open al или еще что-то.
Над всем этим общий интерфейс.
>голые сокеты без надстроек (но кросс-платформенные).
Скажем дружно нафиг нужно. Я игру пишу или с сокетами разгребаюсь?
Работа с сетью должна быть построена таким образом чтобы от программиста требовалось чуть меньше чем ничего.
Включить какой-нибудь флажок синхронизации этого объекта между сервером и клиентами и все.
>>Все как-то делают. На винде виндовозный звук, во всех остальных open al или еще что-то.
>>Над всем этим общий интерфейс.
Я имел ввиду именно сетевую часть, со звуками особых проблем не вижу. Хотя тут тоже за готовое решение (звуки/музыка).
>>Включить какой-нибудь флажок синхронизации этого объекта между сервером и клиентами и все.
Когда и при каких условиях синхронизировать этот объект с сервером? Какие данные надо передавать серверу (я не хочу передавать все данные объекта)? Как быть с сообщениями, реализовывать свой RPC? Даже если этого монстра реализовать, то наверняка он будет работать не так эффективно, как может работать заточенная под конкретную игру сетевая система (ну или хотя бы жанр игр). Задачи очень разные: есть риалтайм шутеры или стратегии, есть игры, в которых надо просто синхронизировать только своё состояние с сервером, обращение к стейту других игроков минимальное (или наоборот), есть игры, от которых требуется только работа с текущим прогрессом (номер уровня) и максимальное количество очков. Так вот это абсолютно разные серверы и абсолютно разные требования к клиенту, как это всё увязывать одну систему - я не знаю.
>Когда и при каких условиях синхронизировать этот объект с сервером?
Когда они будут помечены что необходима синхронизация. Метятся в основном автоматом, но должна быть возможность и в ручную.
>Какие данные надо передавать серверу (я не хочу передавать все данные объекта)?
Общие базовые, и зарегистрированные пользовательские данные.
>Даже если этого монстра реализовать, то наверняка он будет работать не так эффективно
Это не монстр, а удобное средство.
codingmonkey
Так и вперёд! Буду рад за тебя, если реализуешь и будет хорошо работать.
the_siv
> Скрипты писать приходилось, ботов не было необходимости.
Ну это половина бота. Остальное дело техники.
codingmonkey
> Ты опять не спишь ?)
Да именно так, пытался целый день голову включить, под утро заснул - давление.
the_siv
> Идея хорошая, единственное не понятна роль Qt во всём этом... Если взять за
> основу Qt, то это уже будет не движок, а надстройка над Qt.
Я в какой то момент разработки некоего высокоуровнего фреймворка решил взять SDL в место QT - и стоял он у меня в качестве платформы. То есть все низкоуровневое API от OS завернул как еще одну платформу через SDL. Получил два билда - чисто API движка и вариант с надстройкой над SDL для любителей SDL.
Ну и благодаря прозрачной архитектуре разницы между CSAD:FULL и CSAD:SDL сильно не заметил. А CSAD:QT получился неудачным в плане стыковки GUI, слишком много особенностей проще писать только на QT (для 5.0-5.2).
>>Я в какой то момент разработки некоего высокоуровнего фреймворка решил взять SDL в место QT - и стоял он у меня в качестве платформы.
Я планировал как раз писать низкоуровневые вещи уровня API операционных систем, там свои обёртки над файлами, окнами и т.д.
the_siv
> там свои обёртки над файлами, окнами и т.д.
вот в паре своих собственных оберток я взял еще и SDL - и получил CSAD:FULL и CSAD:SDL два самостоятельных отдельных билда.
И в этом плане, можно обсудить модульность/дополняемость или оригинальность архитектуры. Жертвовать ли производительность или универсальностью?
Можно сделать и то и другое но тогда нужно приготовиться к разрастанию кода и тому что архитектура будет напичкана двойными стандартами. То есть внутренний высокопроизводительный объект будет обрабатываться специальным низкоуровневым кодом-конвейером, а внешне будет обслуживаться громоздким высокоуровневым классом не производительным но позволяющим визуально проектировать алгоритм и взаимодействовать со скриптами.
foxes
Ну тут я так понимаю под модульностью понимается отсутствие одной части движка от других. Если так, то не понятно зачем жертвовать производительностью, по сути если не нравится модуль - его можно удалить и написать другой с таким же интерфейсом (и вот тут обязательно надо, чтобы интерфейс не навязывал детали реализации). Но это плохой вариант, пользователь движка не должен кастомизировать поведение переписывая куски движка. Тут я скорее склоняюсь к колбекам для кастомизации некоторых стратегий поведения, какому-то виду плагинов и на крайняк к тупому наследованию классов основных систем для переопределения поведения.
the_siv
> Тут я скорее склоняюсь к колбекам для кастомизации некоторых стратегий
> поведения, какому-то виду плагинов и на крайняк к тупому наследованию классов
> основных систем для переопределения поведения.
Вот этот момент как раз относится к модульности, а не к производительности. Такого рода модули по определению будут менее производительны и скорее хороши для основного описания задачи на движке.
the_siv
> Но это плохой вариант, пользователь движка не должен кастомизировать поведение
> переписывая куски движка.
А вот как раз этот момент хорош для написания грамотного плагина или действительно взаимозаменяемой части движка, для расширения функций для пользователя. Это полезно для разгрузки и конкретизации цели, в место того чтобы делать перочинный ножик и пытаться уместить все в один цикл конвейера движка. Хотя принципы можно организовать на тех же калбеках, но их будет гораздо меньше чем в пользовательском решении. Может быть всего один на внутренний цикл приложения где последовательность обработки будет выбирать пользователь, и заменять деталь на свою. Конечно же это ни чем не будет отличатся от наследования, просто моделирование будет более организованно из основных частей или функций движка.
Интересно было бы разграничить эти уровни по доступности, и тогда вариативность и эффективность выполнения задачи увеличиться.
В общем получается некая тафтология.
Но если сделать архитектуру некоторых базовых пользовательских классов открытую, то появляется возможность определять нагрузку на пользовательский интерфейс самому пользователю. И распределять некоторого рода "Евенты" между различными функциональными объектами по воле пользователя.
В общем это долгий разговор по архитектуре движка, и тут все цело выбор стоит перед разработчиком движка и зависит полностью от его целей.
В итоге мы пришли к тому, что в посте до сих пор нету того-самого Эберли-Баткина-Капулькина, который будет лидить разработку?
lookid
Желающих разработчиков что-то программировать тоже не наблюдается: только желающие как максимум обсудить, а как правило исключительно по критиковать.
the_siv
Желающие тут не при чем. Желающие не знают как, а просто хотят. Тут либо приходит какой-нибудь Антон Капланян и по ночам сидит и разжевывает всё. Либо дальше сидеть, кувырять в пустую Огры и Булет-физиксы. Так что можно попробовать призвать сюда всяких Сусликов, innuendo и Рудибиров. Если откажутся, то можно закрывать лавочку.
О чём это сообщество? О разработке какого-то конкретного движка или место тусовки всех движкописателей на крестах?
Что происходит вообще? Кто здесь?
>>Кто здесь?
Здесь все: Никита, Стас, Гена, Турбо и Дюша Метёлкин.
Тема в архиве.