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

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

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Закрытая тема
Старый 07.09.2017, 14:36
Nooob вне форума Посмотреть профиль Отправить личное сообщение для Nooob Найти все сообщения от Nooob
  № 11  
Nooob
 
Аватар для Nooob

Регистрация: Mar 2007
Сообщений: 319
Цитата:
Сообщение от Appleman Посмотреть сообщение
Вопрос, в чём преимущество создания отдельных пакетов и постоянного импорта двух других в каждый, по сравнению с созданием единого пакета для всей игры, и настройки взаимодействия на уровне отношений исключительно между классами?
разделив все по пакетам ты тем самым выделяешь отдельные блоки взаимоотношений и классы с полями/методами internal в общем пакете могут работать с ними как с публичными, классы в разных пакетах эти поля видеть не будут, например в model методы findEnemy/hit можно смело пометить как internal

Цитата:
Сообщение от Appleman Посмотреть сообщение
Код AS3:
public class BattleData
	{
		private static const map:Dictionary = new Dictionary();
		public static function find(key:String):BattleData
		{
			return map[key] ||= new BattleData(key);
		}
И выражение return map[key] ||= new BattleData(key);
это короткая запись
Код AS3:
var data:BattleData = map[key];
if(data == null)
{
   data = new BattleData(key);
   map[key] = data;
}
return data;
//или
return map[key] || map[key] = new BattleData(key);
оператор ||= обозначает что если выражение слева ложное false/null/0, то приравнять к нему выражение справа, ну и любая операция приравнивания так же возвращает это значение, поэтому его можно передать в return

Цитата:
Сообщение от Appleman Посмотреть сообщение
Последний мини-вопрос. Обратил внимание, что у тебя и у Wolsh многие переменные в коде записаны с символа "_", но не все. Какая тут логика? Я такое в некоторых книгах встречал (не у Мука).
переменными "_" принято обозначать приватные поля класса которые затем могут быть открыты для чтения/записи через get/set, просто удобство в случае пересечения имен публичных и приватных полей класса
__________________
RocketJump

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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Wolsh Посмотреть сообщение
Я даже использовал синтаксис в своем примере: _character[Hash.CHARACTER_INTELLIGENCE]
то есть это равнозначно обращению _character.intelligence, если константа CHARACTER_INTELLIGENCE в классе Hash имеет значение "intelligence". И да, это может быть геттер или сеттер.
Круто! Вот тут нужно из скайпа ставить трёх бабушек с маракасами. Я и забыл про такую форму записи И что касается геттера, то он получается должен быть записан именно в виде жёсткого get, а варианты типа метода с произвольным названием типа GetStrength(), не канает.

Цитата:
То есть, ты предлагаешь ВООБЩЕ ВСЁ хранить в одном бесконечном массиве, а константы класса, вместо того чтобы просто содержать строку "strength", будут содержать индекс массива, по которому из него можно вытащить этот "strength"? Это уместно, когда "strength" может оказаться не "strength", например при смене языка мы заменяем весь массив текстов, а идентификаторы фраз остаются в коде как были. Но если ты начнешь на каждую фразу создавать константу, хранящую ее uint-идентификатор, то это будет адский перебор.
Не совсем так. Я предполагал группу классов-хранителей, внутри которых будут храниться однотипные данные. Если, например, имеем 10 характеристик персонажа, для каждой из которых предусмотрен набор расшифровок, то будет система из 10 индетификаторов-констант, по которым будем вылавливать. Если у персонажа умения имеют похожую структуру (числовое значение и текстовая расшифровка), то и их тужа же, чтобы не дублировать код. Ещё допустим штук 15, итого 25 идентификаторов - вроде вполне терпимо.

Другой класс - для имён, где хранятся имена, фамилии и прозвища. Там идентификаторов служит ID персонажа. Фактически тоже пачка массивов, забитых именами (на нужном языке).

И да, я почитав твои предыдущие советы задумался о том, что "strength" может быть и "силой", а значит и само наименование свойства нужно не задавать жёстко, а брать откуда-то по некоему идентификатору. Хотя, насколько я понимаю, использование строковых идентификаторов такому подходу тоже не противоречит.

Цитата:
Как находит массив по строковому идентификатору? Да может быть просто объект _hints (или статическая константа HINTS:Object) содержащая массивы вариантов по строковым ключам. То есть HINTS["intelligence"] это массив ["дурак", "ни так ни сяк", "умный"].
Можно поподробнее? Получается, что для каждого свойства в классе с хинтами создаётся свой отдельный массив, присвоенный переменной, имя которой совпадает со строковым идентификатором? Учитывая, что у меня планируется игрушка не RTS и совсем не военная, а скорее социальное RPG, выбор всякой инфо по строковым ключам скорее всего будет центральной технологией

Старый 07.09.2017, 18:04
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 13  
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Я вот вообще не хотел опускаться в разговоре до конкретного кода, просто потому что всегда есть 100500 способов решить задачу, и какой из них оптимальный, зависит от множества факторов. А когда начинаешь приводить код, выглядит так что ты настаиваешь на конкретно таком вот решении. А я вообще никак не настаиваю, просто показываю возможный вариант, ОК?
Код AS3:
package 
{
	public class Character 
	{
		private var _strength:int = 50;
		private var _intelligence:int = 50;
		private var _agility:int = 50;
 
		public function Character() 
		{
 
		}
 
		public function get strength():int
		{
			return _strength;
		}
 
		public function get intelligence():int
		{
			return _intelligence;
		}
 
		public function get agility():int
		{
			return _agility;
		}
	}
 
}
 
////--------------------------
 
package 
{
	public class Hash 
	{
		static public const AGILITY:String = "agility";
		static public const STRENGTH:String = "strength";
		static public const INTELLIGENCE:String = "intelligence";
 
		static private const HINTS:Object = 
		{
			strength:		["слабак", "атлет", "силач"],
			intelligence:	["дурак", "умник", "ботан"],
			agility:		["тюфяк", "ловкач", "гимнаст"]
		}
 
		static public function getHint(propName:String, propValue:int) : String
		{
			if (propValue < 30) return HINTS[propName][0];
			if (propValue > 70) return HINTS[propName][2];
			return HINTS[propName][1];
		}
	}
}
 
////----------------------
 
package
{
	import flash.display.Sprite;
 
	public class Main extends Sprite 
	{
		private var _character:Character;
 
		public function Main() 
		{
			_character = new Character();
			trace(Hash.getHint(Hash.STRENGTH, _character[Hash.STRENGTH]));
			trace(Hash.getHint(Hash.INTELLIGENCE, _character[Hash.INTELLIGENCE]));
			trace(Hash.getHint(Hash.AGILITY, _character[Hash.AGILITY]));
		}
	}
 
}
__________________
Reality.getBounds(this);

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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Уважаемые Nooob и Wolsh!

Спасибо за ваши подробные объяснения. Всё прочитал, осознал и пошёл переваривать и экспериментировать. Думается мне, что для первого опыта программирования я в слишком сложную телегу впрягся По крайней мере я уже третий день туплю и даже не могу начать вообще что-либо программировать. Хотя понимание того, что я в любом случае всего сразу не предусмотрю, уже появилось. Поэтому думаю выбрать какой-то отдельный и законченный участок, который можно создать, и сконцентрируюсь на нём.

Цитата:
Я вот вообще не хотел опускаться в разговоре до конкретного кода, просто потому что всегда есть 100500 способов решить задачу, и какой из них оптимальный, зависит от множества факторов. А когда начинаешь приводить код, выглядит так что ты настаиваешь на конкретно таком вот решении. А я вообще никак не настаиваю, просто показываю возможный вариант, ОК?
Да, конечно. Мне пока вообще любой рабочий код, связанный с моей задачей, крайне полезен на посмотреть.

Вот кстати ещё один методологический вопрос, над которым я размышляю. У всех персонажей есть одинаковые свойства, что логично. При этом у главного героя их больше всего (ибо ему условно не только руками махать, но и девок охмурять), у второстепенных NPC их поменьше, а у "проходных" - буквально 3-4 типа имени с фамилией. Вопрос, как в данной ситуации правильнее организовать: наследовать классы и потом воспользоваться преимуществами полиморфизма (ибо расчёты для центральных персонажей производятся иначе, чем для второстепенных) или создавать единый класс и просто не заполнять неиспользуемые поля значениями для второстепенных персонажей? От чего может зависеть решение?

И вопрос камраду Nooob. Я правильно понял логику, что условно все шаблоны и правила расчёта игровой механики "живут" в data, а в model производятся только непосредственные "живые" расчёты для конкретных игровых ситуаций? То есть если действие "пендель" условно наносится с расстояния полметра, а его урон зависит от массы тапка персонажа и его умения бить ногами, то всё это хозяйство прописывается в качестве методов класса game.data.pendel, чтобы потом быть импортированным в model для расчёта по актуальным значениям. Или нет?


Последний раз редактировалось Appleman; 07.09.2017 в 20:36.
Старый 08.09.2017, 00:12
Godwarlock вне форума Посмотреть профиль Отправить личное сообщение для Godwarlock Найти все сообщения от Godwarlock
  № 15  
Godwarlock

Регистрация: Jan 2012
Сообщений: 836
Цитата:
При этом у главного героя их больше всего (ибо ему условно не только руками махать, но и девок охмурять), у второстепенных NPC их поменьше, а у "проходных" - буквально 3-4 типа имени с фамилией. Вопрос, как в данной ситуации правильнее организовать: наследовать классы
Все твои данные - это библиотека. Поэтому кроме метода get у определенной Data, для того, чтобы получить статы, указанные в параметрах функции тебе ничего не надо.

Старый 09.09.2017, 16:26
Nooob вне форума Посмотреть профиль Отправить личное сообщение для Nooob Найти все сообщения от Nooob
  № 16  
Nooob
 
Аватар для Nooob

Регистрация: Mar 2007
Сообщений: 319
Цитата:
Сообщение от Appleman Посмотреть сообщение
Я правильно понял логику, что условно все шаблоны и правила расчёта игровой механики "живут" в data, а в model производятся только непосредственные "живые" расчёты для конкретных игровых ситуаций? То есть если действие "пендель" условно наносится с расстояния полметра, а его урон зависит от массы тапка персонажа и его умения бить ногами, то всё это хозяйство прописывается в качестве методов класса game.data.pendel, чтобы потом быть импортированным в model для расчёта по актуальным значениям. Или нет?
Если расчеты основываются на константных данных, то они живут в data. к примеру есть статические препятствия и нужен метод который определяет пересекает ли луч эти препятствия, этот метод пишется в ObstaclesData, для того что-бы можно было применить эту математику в любом независимо от модели месте, во view, на кнопке атаки или в прицеле, или рисовать ли препятствие на сцене. или другой пример есть некий персонаж у него есть дерево умений, каждое умение можно изучить выполнив некий список условий (предыдущее умение изучено, достаточно энергии, есть нужный предмет в инвентаре), этот метод я бы тоже располагал в data, так как на этот момент еще нету модели этого конкретного умения (оно еще не изучено), а его состояние нужно рисовать в интерфейсе. альтернативный пример есть кнопка атаки другого персонажа, которая становится активной когда в радиусе есть враги, этот метод проверки доступности атаки я бы расположил в model.
твой пример с пенделем можно располагать в data, но если в игре появляются бафы которые влияют на массу тапка и его умения и его урон, то это перестает быть константными данными, и по большей части все данные уже берутся из модели, и логичнее всего такой метод переложить в model
__________________
RocketJump

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

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Nooob,
Можно узнать ваш способ организаций ответа на действия пользователя? (Controller) Как именно вы реализуете этот процесс. На любом простом примере, например, кнопка изучить скилл.
__________________
Дети не должны знать о своих родителях

Старый 11.09.2017, 19:24
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 18  
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Wolsh Посмотреть сообщение
Я вот вообще не хотел опускаться в разговоре до конкретного кода, просто потому что всегда есть 100500 способов решить задачу, и какой из них оптимальный, зависит от множества факторов. А когда начинаешь приводить код, выглядит так что ты настаиваешь на конкретно таком вот решении. А я вообще никак не настаиваю, просто показываю возможный вариант, ОК?
Код AS3:
	package 
{
	public class Hash 
	{
		static public const AGILITY:String = "agility";
		static public const STRENGTH:String = "strength";
		static public const INTELLIGENCE:String = "intelligence";
 
		static private const HINTS:Object = 
		{
			strength:		["слабак", "атлет", "силач"],
			intelligence:	["дурак", "умник", "ботан"],
			agility:		["тюфяк", "ловкач", "гимнаст"]
		}
}
Уважаемый Wolsh!

Потихоньку разбирался и пробовал, в итоге из всех 100500 разнообразных решений для хранения нужных мне строковых данных выбрал всё-таки предложенный тобой код, что не удивительно Сделал в целом похожую конструкцию, она работает.

Возникло 2 вопроса. Во-первых, каково преимущество статических переменных и методов перед обычными для подобных классов-"справочников"? В своём примере коллега Nooob, например, сразу после объявления класса создавал в нём константу с экземпляром класса-"справочника" и потом обращался непосредственно к ней.

Во-вторых, я попробовал в классе Object с массивами расшифровок заменить прямое указание строковых идентификаторов ("agility", "strength") на константы, содержащие те же значения (попытка записи типа [GlobalValues.FEATURES_STRENGTH], имеющей значение "strength"). Ничего не вышло, выдаёт ошибку. Есть способ непрямого указания идентификаторов в теле Object?

Старый 11.09.2017, 19:30
ZackMercury вне форума Посмотреть профиль Отправить личное сообщение для ZackMercury Найти все сообщения от ZackMercury
  № 19  
ZackMercury
 
Аватар для ZackMercury

блогер
Регистрация: Jul 2013
Адрес: Север
Сообщений: 1,918
Записей в блоге: 23
Отправить сообщение для ZackMercury с помощью ICQ Отправить сообщение для ZackMercury с помощью Skype™
Цитата:
Во-первых, каково преимущество статических переменных и методов перед обычными для подобных классов-"справочников"?
Удобство. На самом деле, обращение к статическим данным занимает больше времени, чем к членам, так как сначала при нахождении идентификатора, оно проверяет локальную область видимости, затем область видимости класса, а затем уже ищет среди названий других классов и при совпадении пытается тащить у них статическое свойство/метод.
__________________
There is no thing in this world that is not simple.

Старый 11.09.2017, 21:04
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 20  
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Спасибо, понял. А по второму вопросу есть какие-нибудь идеи?

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

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

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


 


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


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