Тёмная тема
- Salamandr
- Участник
Arclight
Ваша проблема в том, что про ООП что-то где-то слышали, но не понимаете его и не знаете терминологию. Я же уже ответил - агрегация, а вы мне про наследование. Вы понимаете, что это два разных вида взаимосвязи между классами? Одно исключает другое.
Arclight
> С чего вы взяли что компонентный подход должен быть обязательно привязан к
> Юнити?
Ну как с чего, с того, что так сделали разработчики Юнити. Не самое плохое решение кстати.
хоть делай уроки по ООП на ютубе :) но нет, утрудите себя немного сами ...
tac
Entity Component System не исключает наследования для основного класса.
Но зачем ты это объясняешь u960 и Arclight, если они всё равно не внимательно читают твои сообщения..
> Так как по вашему должен выглядеть склад и генератор в одном флаконе?
В заводе присутствует большое количество цехов и каждый цех занимается своим делом, но от этого завод не перестаёт быть заводом, даже если на Мясокомбинате добавиться Авто-цех для ремонта автомобилей принадлежащих заводу.
Вы слишком узко смотрите, очевидно в силу ограниченного стремления или каких либо заведомо узких рамок и границ. Забывая о том что наш мир многогранен и именно от туда идёт опыт и большинство различных решений.
tac
не распыляйся, или ты там бездонный источник ресурсов и времени?
tac
> Я же уже ответил - агрегация, а вы мне про наследование. Вы понимаете, что это
> два разных вида взаимосвязи между классами? Одно исключает другое.
Вообще ни разу не исключает. Но спроектировать систему которая будет работать одновременно с этими подходами ой как не просто:)
Например определяющее свойство прокидываешь через наследование, а вторичные и опциональные - через компоненты(агрегацию). И в это даже в целом работает.
tac
> Ваша проблема в том, что про ООП что-то где-то слышали, но не понимаете его и
> не знаете терминологию. Я же уже ответил - агрегация, а вы мне про
> наследование. Вы понимаете, что это два разных вида взаимосвязи между классами?
> Одно исключает другое.
Вы видимо тоже не понимаете, что в конечном итоге ваша агрегация превратится в те самые компоненты и не важно основаны они будут на компонентах юнити или нет. Когда элементы равноправны и им нужно взаимодействовать между собой, простая агрегация и композиция не поможет.
Salamandr
Это вы читаете не внимательно, автор утверждает что компоненты не нужно использовать и оставить их только как элементы взаимодействия с юнити.
>tac
Вот теперь можно посмотреть на мой г-код, вот я пишу примерно так, обычно коментариев нет такого количества, так как не нужно, но вот на тему натыканных повсеместно проверок можно посмотреть.
Ссылка
Вконце там можно скачать. Вот я и не знаю, как там ООП, но тут я фактически любую процедуру или функцию беру, и вставляю в любой новый проект, как есть и она 100 работает без всяких извращений наворотов и доделок. И вот было бы интересно как это можно переработать в более правильном виде.
Arclight
> автор утверждает что компоненты не нужно использовать
вы опять что-то напутали :)
Arclight
> агрегация превратится в те самые компоненты
разные вещи
Mephistopheles
> Вообще ни разу не исключает.
имелось введу одновременно, что это разные вещи.
FourGen
> Вот я и не знаю, как там ООП, но тут я фактически любую процедуру или функцию
> беру, и вставляю в любой новый проект
Глянул по диагонали пока, ну конечно не ООП :)
Но это как раз вот какой случай о котором я писал в ютубе:
А специально писать, еще какую то отладочную информацию на постоянной основе. Зачем? Это так же замусоривает код. И полезно, только если ты пишешь некий ассет для других, чтобы они могли разобраться в твоем компоненте не залезая в его код, если например, провели не правильную его инициализацию.
т.е. в здравом уме никто не докапывался бы до этих проверок .. ну есть и хорошо, нет юзер получит баг.
Но и тут надо разделять, если проверяются параметры введенные пользователем - это одно. Это своего рода реализация "интерфейса с пользователем".
Надо правильно понимать, что в случае игры - это интерфейс/управление в игре - и там этого нет, потому что во время игры ты не можешь игроку выкинуть окошко мол ты неправильно тут что-то повернул, или нажал. А раз не можешь - тебе и не нужно реализовывать с ним диалог через проверку параметров. Вместо этого ты можешь просто продумать как там будет действовать персонаж когда он сталкивается со стеной или чем то таким ...
Проверки же своих private полей - опять же бесполезны даже в случае ассета.
FourGen
> было бы интересно как это можно переработать в более правильном виде
для ООП вначале нужно убрать все static, убрать вложенную struct, выделить основной класс - у вас создание миникарты, а такого класса нет. Добавляете класс MiniMap, переносите туда то, что к нему относится - свойства и методы. Это уже довольно не тривиально - мне бы понадобилось несколько часов ... Но вместе с этим появятся контуры ООП.
А пока да - это скрипт :) а не код
и вот я нашел источник дурного запаха
MapStep = 100;
ParamsFileData[2] = MapStep.ToString();
MapSizeX = 200;
ParamsFileData[3] = MapSizeX.ToString();
MapSizeZ = 200;
ParamsFileData[4] = MapSizeX.ToString(); // а тут наверно баг :) Кстати, это как раз тот случай когда можно применить мою систему сохранения DirectConvertor - прямые конвертации альтернатива сериализации [сохранение ваших игр]
Пока я не нашел в себе желания показывать как переделать это под ООП. Хотя материал есть, да и случай массовый на самом деле. Если сделали бы, что-то полезное для моего проекта - то тогда другое дело. Но и тогда мне нужен проект юнити с тестовым примером и роликом как сгенерировать мини карту, или что-там оно умеет. Если будете выкладывать в ассет стор - то это все равно понадобится, голый скрипт там вряд ли даже возьмут.
Сейчас в машине чуть позже осмысленней прочитаю. У меня багов нет. :)
FourGen
> я фактически любую процедуру или функцию беру, и вставляю в любой новый проект,
> как есть и она 100 работает без всяких извращений наворотов и доделок
вы о себе слишком хорошего мнения :)
если серьезно, я даже не знаю, откуда у вас эта иллюзия.
private void SaveParams(string SavePath)
{
bool IsParamFileExists = File.Exists(SavePath);
StreamWriter sw = new StreamWriter(WorkDirPath + ParamFileName);
for (int i = 0; i < ParamsFileData.Length; i++)
{
sw.WriteLine(ParamsFileData[i]);
}
sw.Close();
if (IsParamFileExists == false)
{
AssetDatabase.ImportAsset(WorkDirPath + ParamFileName);
AssetDatabase.ForceReserializeAssets(new List<string>() { WorkDirPath + ParamFileName }, ForceReserializeAssetsOptions.ReserializeAssetsAndMetadata);
}
}Угадайте почему ваше утверждение на этой функции не работает?
тут нарушено, даже не ООП, которого ок нет ... но тут нарушен и процедурный подход - опятьже угадайте почему?
наличие самого метода
private bool ResetValues()
само по себе ужасно ... но это понятно из ООП уже .. да и если присмотреться и в процедурном подходе это не правильно ...
пока вы не делаете утверждение "работает без всяких извращений наворотов и доделок" то куда не шло ... вы на самом деле не видите проблем?
Не, я "добью вас" :)
catch
{
Debug.Log("ERROR: Ошибка получения значения одного из параметров.");
return false;
}как думаете на сколько бесполезно это сообщение? почему вы не довели до абсурда и не проверили все сколько там 15 свойств и не сказали какой параметр вы не получили?
может быть я спровоцировал вас на разбор вашего кода зря ) Кажется еще рано про ООП говорить ... надо немного раньше ...
вот так вы вызываете ваш метод, который я показал выше ... мм ... это точно говнокод - без обид ...
if (File.Exists(WorkDirPath + ParamFileName) != false)
{
SaveParams(WorkDirPath + ParamFileName);
}Еще не доехал, сорри так бегло пока, я первый раз в жизни читаю из файла на с#, ассеты тоже первый раз гружу, что оно делает не оч понимаю. Работает и ладно, если можно, скажите плз как вызвать ошибку.
>u960
Вы сами много написали... я пишу, криво косо, но у меня все работает. Я в состоянии сделать инвентарь не глючащий от 1 нажатия и который работает так как мне нужно. Я уже все писал. Есть разница между хотеть и сделать.
Не проверяю все 15, потому что все проверяется ранее и это исключение не может произойти если вручную что то не поменяют.
Чем плоха процедура инициализации переменных?
FourGen
да, я понял ... понимаете, чтобы все разложить по полочкам - мне требуется много времени ... из плюсов - ваши примеры кода хорошие для этой цели и вы вроде как готовы воспринимать информацию (в отличии от некоторых тут) ... из минусов - это занимает много времени ...
FourGen
> Не проверяю все 15, потому что все проверяется ранее и это исключение не может
> произойти если вручную что то не поменяют.
и следовательно, что? Вы
1. или игнорите "если вручную что то не поменяют" и выкидываете это исключение из кода
2. или проверяете все 15
не добавлять бесполезного кода в код - оказывается тоже важно )
а фраза "потому что все проверяется ранее" и я еще раз проверяю - алогична.
ну и потом, вызовите ту же функцию проверки. Почему так не делаете? Потому, что у вас все проверки разбросаны по коду беспорядочным образом.
А на самом деле - вам просто лень проверять все 15, ведь так?
Я тут подумал, и мое предложение такое: за бета-тест моей игры с фэдбэком, видео-стримом и выкладыванием у себя на канале я могу записать серию обучающих видео с разбором вашего кода.
P.S. хотя больше всего мне нужна помощь художников и 3d моделлеров
Это предложение для всех, но наиболее актуально сейчас для FourGen
за бета-тест
Да потесть я и так могу, но падать он оне должно каждые 2 минуты от неправильного действия.
Вот добрался до клавиатуры )
Теперь могу описать свой подход более подробно.
Сначала хочу обратить внимание, что я ни скольк оне сомневаюсь в качестве своего кода, если это г, значит г. Тут у меня заблуждений нет нисколько. Почему я считаю что он лучше многого, чем даже у профи, по одной простой причине:
1) Он не тормозит (сеньор еле еле на 2.5 объектах выдат там 60 fps еле еле у меня на экране в 10 раз больше моделей и текстур в 20 раз больше + террайн + логики больше 120-180fps и я знаю как его поднять еще, так как оптимизаций 0 кроме включенных статик на объектах)
2) У программистов которых этот сеньер назвал крепкими мидлами, баг после каждого нажатия (это не утрирование - это реальный факт)
3) Я за 3 месяца сделал больше функционала (первый раз сел за юнити) и более серьезного чем 3 программиста + какой-то человек который должен был сценой заниматься.
4) у меня все работает, у них нет.
Я не говорю, что это круто, реальный профи это сделает значительно лучше и быстрее, я это превосходно понимаю. Я в общем целом о подходе. Вот u960 и бесится ой криво написано, ой лажа, но работает значителньо лучше как же так, нет тут что от не так все равно он лошара а вот те кодеры круты и я все гоню. Самому, как Санычу судя по всему хочется но не можется кроме болтовни ))))
По проверкам:
- Проверки ни в коем не раскиданы рендомно. Если вы обратите внимание, то они идут везде при обращении к массивам, при работе с элементами интерфейса, при проверках выхода за границы тех или иных элементов, то есть всегда одинаково. (И да обычно я столько не делаю, просто это решил выложить, напихл несколько больше чем нужно)
нет юзер получит баг
У меня подход такой: багов быть не должно. Все что я точно знаю как проверить я проверяю, то с чем не знаком (например загрузка и иницализация асстов, сделал как получилось, лишь бы работало и минимум, что бы мои действия не вызывали исключений)
наличие багов приводит потом к невозможности починить код за адекватное время, а так функция отлажена, проверены все что можно подать на вход, проверяется все, что идет на выход и готово. Можно не сомневаться, что оно будет работать в этой части.
Проверки же своих private полей - опять же бесполезны даже в случае ассета
Я лично встречал исключения при работе с антивирем. Он оч неплохо лезет в память. Нет 100% гарантии, что в 1 прекрасный момент у вас не пропадет или не поменяется или не запишется некое значение, что вызовет падение если нет проверки.
выкинуть окошко мол ты неправильно тут что-то повернул
Почему не могу? У меня в проекте все ошибки будут отправлять на сервер. У меня все подготовлено для этого: Я делал журнал лога, и так же выкинул все ошибки:
Вот такого плана:
Я могу и не только могу но и сделал.
Далее так по общим вопросам
провели не правильную его инициализацию.
Пользователь не должен ничего инициализировать. Для запуска надо просто с скопировать папку в проект. Какой смысл что-то делать для людей, где что-т надо доделывать?
Все работает как есть, просто зная, что куча народа начнет делать непонятную фигню, я на всякий случай указал, что прога рабоатет с файлами и они могут быть удалены, что бы не сделали криво.
убрать все static, убрать вложенную struct
У меня не класс, у меня набор процедур, к которым можно обращаться. Если мне будет необходимо где-то когда-то этот функционал, я выкину весь юзер интерфейс и буду пользоваться внешними функциями свободно. Кроме того чем static плох? Память выделяется? Так написав 50 скриптов разных памяти больше уйдет?
переносите туда то, что к нему относится - свойства и методы
К созданию миникарты относится все, что в этом модуле. Он полностью самодостаточен.
А пока да - это скрипт :) а не код
ВО вы правильно проидентифицировали, к стати. Тут соглашусь.
MapSizeZ = 200;
ParamsFileData[4] = MapSizeX.ToString(); // а тут наверно баг :)
В инт нельзя простыми методами записать не инт, можно но уж точно не пользователем. Тут вроде как безопасно +-, кроме того оно проверяется. Если что оно раньше определиться.
DirectConvertor - прямые конвертации альтернатива сериализации [сохранение ваших игр]
У вас сохранение идет из единой точки? Если поле было инт, а станет сринг оно присвоит значение или наоборот? 1 файл для подключения?
вы о себе слишком хорошего мнения :)
Если не сложно, скажите из-за чего оно может упасть в том куске?
Не, я "добью вас" :)
catch
{
Debug.Log("ERROR: Ошибка получения значения одного из параметров.");
return false;
}
Я ни сколько не стесняюсь и не огорчаюсь, без проблем. Как написал выше, одни могут слюнями брызгать и только болтать, а другие могут писать, криво, косо но делать.
Как написал выше, эти параметры могут измениться только вручную, если что-то что то делает намерено, нет смысла делать глобальные проверки, не упало и ладно. В консоли выведется и будет понятно, что что-то произошло не то, главное ошибки нет. Все эти параметры ранее проверяются. Так что не совсем пока добили :)
Спасибо за консультацию в любом случае. Я ни скольк оне наезжаю и не оправдываюсь, я ваши слова воспринял, просто объясняю подход.
(Но для чистоты эксперимента, попробовали бы вызвать исключение, просто интересно получится просто или нет)
По вашему сохранению:
Почему мне подойдет