Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, Crystalizer, Вы писали:
C>>В каком случае какой подход лучше применять?
D>Я думаю, тебе никто не отвечает, потому что уже устали сраться на эту тему. Вот, почитай одно из обсуждений: http://rsdn.ru/forum/design/3406168.aspx
Хех, ничего не знал про эти модели, но в своей игрушке интуитивно стал переходить на стройную модель, когда получил ад с изменениями и синхронизациями объектов в множестве потоков, вообще перестав понимать что и где происходит. Поэтому решил отказаться от возвращения ссылок и передачи ссылок на объекты, и вместо этого переделать всё на сервисы, которые будет что-то делать по всяким там id и результаты тоже возвращать в подобном виде.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
S>Хех, ничего не знал про эти модели, но в своей игрушке интуитивно стал переходить на стройную модель, когда получил ад с изменениями и синхронизациями объектов в множестве потоков, вообще перестав понимать что и где происходит. Поэтому решил отказаться от возвращения ссылок и передачи ссылок на объекты, и вместо этого переделать всё на сервисы, которые будет что-то делать по всяким там id и результаты тоже возвращать в подобном виде.
во. вот и мне кажется что когда логика обработки сущностей очень ветвистая — то она должна стоять отдельно. иначе это всё становится безумно сложно...
Здравствуйте, Crystalizer, Вы писали:
C>Здравствуйте, Sorc17, Вы писали:
S>>Здравствуйте, dimgel, Вы писали:
D>>>Вот, почитай одно из обсуждений: http://rsdn.ru/forum/design/3406168.aspx
S>>Хех, ничего не знал про эти модели, но в своей игрушке интуитивно стал переходить на стройную модель, когда получил ад с изменениями и синхронизациями объектов в множестве потоков, вообще перестав понимать что и где происходит. Поэтому решил отказаться от возвращения ссылок и передачи ссылок на объекты, и вместо этого переделать всё на сервисы, которые будет что-то делать по всяким там id и результаты тоже возвращать в подобном виде.
C>во. вот и мне кажется что когда логика обработки сущностей очень ветвистая — то она должна стоять отдельно. иначе это всё становится безумно сложно...
У меня одни и те же игроки были во множестве разных списков (список всех игроков, список игроков видимых игроку 1, игроку 2, ...) Было много тредов, которые выполняли всякие задачи и которым постоянно нужен был доступ ко всяким данным (тред захвата цели башней и инициирования атаки, тред синхронизации внутреигрового времени с клиентами, тред, обрабатывающий попадание снарядов после того как они долетят до цели). И я всюду передавал ссылки на игрока, ссылки на текущую позицию, ссылку на объект снаряда, чтобы можно было вызвать у них соответствующие методы. В итоге я получил хаос, такой что перестал понимать где и что меняется, где и кто вызывает методы и решил всё полностью переделать. Теперь игра будет состоять из отдельных сервисов, которые будут общаться между собой с помощью внутреннего протокола, не вызывая методы объектов непосредственно, а лишь оставляя запрос на их выполнение и параметры для вызова метода. И эти запросы будут складываться в очередь внутри каждого сервиса и выполняться внутренним тредом сервиса. Не знаю пока всё ли у меня получится таким образом сделать, поживём увидим.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
