Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > ActionScript 3.0

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 22.10.2018, 02:51
Tails вне форума Посмотреть профиль Отправить личное сообщение для Tails Найти все сообщения от Tails
  № 31  
Ответить с цитированием
Tails
 
Аватар для Tails

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Цитата:
А если например, метод расчёта урона, который наносит гоблин (т.е. не значения дамага из справочника, а что-то типа вероятности попадания или какие-то ещё модификаторы), отличается от аналогичного для мага? Как тогда обойтись без наследования классов юнитов в Модели?
Я уже сказал, в моём примере всё взаимодействие с миром происходит через апи объекта World. У этого класса будет, в том числе метод:
Код AS3:
function unitAttack(unit1:uint, unit2:uint):void;
Который примет id атакующего и атакуемого юнитов. Выполнит все проверки, посчитает модификаторы урона и т.д. Объект World содержит данные обо всех сущностях в игре. (В нём есть списки юнитов, бафов/дебафов, вся необходимая информация)
__________________
Дети не должны знать о своих родителях

Старый 23.10.2018, 09:52
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 32  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Tails, я ещё полюбопытствую. В твоём примере есть класс GameData, который, как я понял, затягивает из json все справочные данные игры: и юниты, и атаки, и типы атак. На больших проектах ты так же делаешь - один пухлый справочник всех статических данных, который хранит и выдаёт все списки, или уже как-то разделяешь?
__________________
Не сломано - не чини!

Старый 23.10.2018, 12:35
Tails вне форума Посмотреть профиль Отправить личное сообщение для Tails Найти все сообщения от Tails
  № 33  
Ответить с цитированием
Tails
 
Аватар для Tails

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Я выносил в GameData все статичные данные игры, не изменяемые во время выполнения. А если и делить, то как? И зачем? Динамические данные (изменяемые в ходе игры) у меня были в объекте World. Вообще, я думаю, что лучше хранить абсолютно все данные в одном месте и изменяемые и не изменяемые (В идеале).
__________________
Дети не должны знать о своих родителях

Старый 23.10.2018, 12:59
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 34  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Не знаю, поэтому и спрашиваю. Можно пофантазировать, что а) данный класс будет слишком раздутым, так что в нём будет тяжело ориентироваться, б) объём загружаемой и хранимой инфо будет слишком большим с т.з. ресурсов системы и, возможно, в) над различными аспектами игры трудятся разные люди в команде, поэтому им удобнее иметь свои справочники, а не делить один общий.

И если у тебя все справочники живут вместе, зачем тебе наследовать классы парсеров? Ты в одном из предыдущих сообщений писал, что по этой причине предпочитаешь не реализовывать парсер как "статический" класс. Я правильно понимаю, что парсер - это у тебя такая огромная простыня с кол-вом методов по кол-ву классов-листов?
__________________
Не сломано - не чини!

Старый 23.10.2018, 13:52
Tails вне форума Посмотреть профиль Отправить личное сообщение для Tails Найти все сообщения от Tails
  № 35  
Ответить с цитированием
Tails
 
Аватар для Tails

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Цитата:
Данный класс будет слишком раздутым, так что в нём будет тяжело ориентироваться
Количество строк кода не так страшно, как его запутанность. Даже если в классе будет более 2к строк, это не проблема, в любой нормальной иде есть "сворачивалки кода", закладки, различные способы навигаций и т.д. Главное, что-бы один класс выполнял строго одну задачу, тогда всё будет по красоте. Когда класс решает более одной задачи, тогда можно и в 200 строчках намутить такого, что чёрт ноги сломит. В данном случае, это просто справочник и в нём не будет много строчек, он будет иметь только список переменных.

Цитата:
Объём загружаемой и хранимой инфо будет слишком большим с т.з. ресурсов системы
Я думаю, напротив, это - самый минималистичный способ представления данных. Только чистые данные, без чего либо лишнего. Как уже писал выше, для сравнения:
Мой гоблин в рантайме:
id, unitID, life - Не более 16 байт. (4 + 4 + 8)

Гоблин по принципу - "объект сам себе режисёр":
Содержит текущие данные, копию его статичных данных (Имя юнита, например) и данные всей цепочки наследования + EventDispatcher. Потребление памяти будет явно в несколько раз больше.

Цитата:
Над различными аспектами игры трудятся разные люди в команде, поэтому им удобнее иметь свои справочники, а не делить один общий.
Наврядли приветствуется такой подход. Скорее, в командах есть главный архитектор, который раздаёт всем остальным реализацию составленного им дизайна апи того или иного модуля программы. То-есть, формат у всех единый. В моём опыте я пересекался с другими программистами только в способах коммуникаций и передачи данных. (Я писал клиент, другой человек - сервер и т.п.)

Цитата:
И если у тебя все справочники живут вместе, зачем тебе наследовать классы парсеров?
Конкретно тут, наверное, незачем. Я это сказал к тому, что обычный объект класса предпочтительнее статического, по некоторым важным причинам. Давно ещё где-то читал, из аргументов помню: Невозможность наследования, переопределения, имплементации интерфейса и ещё вроде что-то было. Поэтому, если в этом особой нужды нету, то не нужно так делать.

Цитата:
Я правильно понимаю, что парсер - это у тебя такая огромная простыня с кол-вом методов по кол-ву классов-листов?
У меня да. Вы можете как угодно сделать Никто не запрещает вам разбить парсер на составные, которые будут читать конкретные списки данных. Но нужно ли это? Парсер и так выполняет очень примитивную задачу. Его суть - в отделений модели данных от чтения конкретного формата. Этим со мной когда-то поделился Dimarik на этом форуме. Респект ему.
__________________
Дети не должны знать о своих родителях

Старый 23.10.2018, 14:16
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 36  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Исчерпывающе, спасибо.

Цитата:
Сообщение от Tails Посмотреть сообщение
Вы можете как угодно сделать
Будешь смеяться, но поскольку по мере развития своего проекта мои собственные познания очень активно развиваются и расширяются, я уже на сегодня имею массу разнообразных вариантов хранения справочных данных. В частности, у меня есть языковые XML файлы, несколько классов, в которых я создал и вручную заполнил такие же хэши, как у тебя из json считываются, плюс есть в порядке эксперимента вариант подгрузки и считывания из json в рантайме. В принципе все работают, то ясен пень, нужно с этим плюрализмом заканчивать.

Кстати, намотал на ус твою мысль о рисках ошибиться, возникающих при обращении к данным json в рантайме.

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

Код AS3:
public static function generate (id: String) : Superclass 
{
if (!CLASSES[id]) throw ("Нет записи для id " + id);
 
var GeneratedClass: Class = CLASSES[id];
var result: Superclass = new GeneratedClass(id);
return result;
}
А дальше прямо в конструкторе класса создаваемого экземпляра записан запуск переопределяемого в наследниках метода setInitialProps(), который ломится в тот же справочник и сам заполняет нужные данному наследнику поля.
__________________
Не сломано - не чини!

Создать новую тему Ответ Часовой пояс GMT +4, время: 18:07.
Быстрый переход
  « Предыдущая тема | Следующая тема »  
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 18:07.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.