- endeavour_pr
- Постоялец
lolol
> Бухучёт игроделу нужен не больше чем язык австралийских аборигенов. С аэродинамикой та же беда.
Ну в целом может оно и так, но не знание математики у кодеров регулярно плодит лузлы на этом форуме. В этом смысле Роннико самый веселый парень в нашей деревне
Чур меня не закидывать помидорками.
Была слабость в ковид решил подкалымить в Юнити
пошел искать в hh.ru столкнулся с тем что на Юнити ищут
не людей кто знает ООП и знает как лучше выжить из движка что то крутое.
А казуалки точнее МНОГО И БЫСТРО казуалки
по 1 игре в мес нужно выпускать. То есть ищут тренд дергают графон
и ты уже хреначишь.
Поверте ни о каком ООП вообще не думаешь а тупо делаешь прифабы и копипастишь
другие даже наследования не используешь(из общения от одного работника)
Так что плюнул я на игрострой и только для души програмирую на разных движках Юнити\годот
а для всего остального есть питон (8
DanQuimby
мб он свою игру хочет сделать.
PeeKay
> Я вот начинал не с ООП языка, там не было классов и в итоге что бы делать объекты приходилось размахивать нунчаками из костылей собирая эти объекты из глобальных переменных или утилизируя существовавшие в движке нерасширяемые объекты. Это было ужасно.
Ужасно то, что за все эти годы ты так ничему и не научился. Были изобретены для таких случаев базы данных, если много однотипных объектов. В них есть графический инструментарий даже.
lolol
> без которых можно разве что в php несложные сайтики пилить.
Одно, другим можно заменить.
lolol
> ООП - это не клад и не военная тайна. Это инструмент, без кторого в современных языках вообще нечего делать.
Мне кажется под этим термином каждый понимает что то своё, но сейчас в треде ЕСЦ. Да и раньше как то обходились, если ты чего то не можешь, это не значит что другие не могут.
ildarin
> Как писать на C# не используя классы? Все в один метод напихать? Или в js не используя объекты? Там вообще всё есть объект.
Написал выше, а в юнити можно геймобъекты использовать.
Обычно инструмент подбирают под задачу.
RikiTikiTak
> Мне кажется под этим термином [ООП] каждый понимает что то своё
Всего три варианта:
- Первый путь - классический. Представления мира, в котором живет программа, в виде строгой иерархии "объектов". Если один объект является частью другого, считается, что в реальном мире этому соответствует связь "part_of" - "крыло - часть птицы", если же объект наследуется от другого - "is_a" - "аист тоже птица" (и значит, у него тоже есть крылья). По идее, такой подход должен давать возможность программе свободно ориентироваться в сложном мире и писаться на естественном языке.
Но, ловушка здесь в прилагательном "строгая" в первой строке. Допустим, я построил эту самую иерархию и написал нужную мне программу. И тут, как обычно, мне понадобилось ее изменить. Фигушки!
Во-первых, т.к моя иерархия изначально "глубоко продуманная", то как я заставлю себя ее перекроить? Не то, чтобы жалко, но просто мозги так не повернуть, чтоб "систему мира" переделать.
Во-вторых, во всех существующих системах ООП, переделка "мира" (рефакторинг) вещь практически неосуществимая, вызывающая лавинообразный рост ошибок.
Поэтому первый путь, столь любимый классиками, в дикой природе практически не встречается.
- Второй путь - быдлокодерский. Как "современный программист" решает задачу? Он ищет подходящую библиотеку. А для удобства применения сложных библиотек тупыми кодерами, первые естественно снабдить этой самой, описанной выше "иерархией".
"Найти в окне X кнопочку Y и запретить ее нажатие" == X.Y.ЗАПРЕТИТЬ().
"Сделать еще такую же кнопочку, но разместить левее" == Z-КЛАСС УНАСЛЕДОВАТЬ-ОТ Y-КЛАСС; Z-КЛАСС:РИСОВАТЬ()={ПРЕДОК.РИСОВАТЬ(); ПРЕДОК.СДВИНУТЬ-ВЛЕВО();}; Z=НОВЫЙ-ОБЪЕКТ Z-КЛАСС;"
Как-то так...
И многие "современные бейсики" этот механизм в себе имеют. Еще один стимул применения подобной схемы: вся привычная визуальная фигня - окошки, рамочки, кнопочки, прокрутки и менюшки - еще в 70-е годы прошлого века была создана объектно-ориентированной. И остается такой по настоящее время.
- Третий путь - обфускационный - "чтоб как у людей". Просто группирование разнообразных данных, а, если поднапрячься, и кода, в одном месте. Чтоб было!
На Форуме традиционно рассматривается последий.
gudleifr
> На Форуме традиционно рассматривается последий.
Тут про наследование что то вроде писали, а это больше подходит к первому пути. Так что действительно каждый по разному понимает.
RikiTikiTak
> Ужасно то, что за все эти годы ты так ничему и не научился. Были изобретены для таких случаев базы данных, если много однотипных объектов. В них есть графический инструментарий даже.
это был 2010 год, это был движок Warcraft III, к нему нельзя подключить базы данных.
И да, классы > чем бд. И для операций внутри движка тебе всё равно нужны объекты, в который ты превратишь данные из бд.
Ужасно то, что за время пока меня не было ты так и не остепенился и не успокоился.
gudleifr
> - Первый путь - классический.
> - Второй путь - быдлокодерский.
> - Третий путь - обфускационный - "чтоб как у людей".
полностью согласен. И что переделывать иерархию мира больно, и что существующие библиотеки (а в особенности ГУИ) склоняют использовать ООП пусть даже чисто синтаксически, и что тем кто едва освоил его оно кажется чудом и "как у людей".
Поэтому я за то чтоб игры делать на ECS а не ООП. олеоле ECS!
gudleifr
> Но, ловушка здесь в прилагательном "строгая" в первой строке. Допустим, я построил эту самую иерархию и написал нужную мне программу. И тут, как обычно, мне понадобилось ее изменить. Фигушки!
> Во-первых, т.к моя иерархия изначально "глубоко продуманная", то как я заставлю себя ее перекроить? Не то, чтобы жалко, но просто мозги так не повернуть, чтоб "систему мира" переделать.
> Во-вторых, во всех существующих системах ООП, переделка "мира" (рефакторинг) вещь практически неосуществимая, вызывающая лавинообразный рост ошибок.
не "Фигушки!", а множественное наследование. Сколько энергии чтобы не учить азы программирования! За то время, что ты писал этот пост, можно было разобраться с ООП.
RikiTikiTak
> если ты чего то не можешь, это не значит что другие не могут.
В анриле нет такого шаблона как ECS и это никому не мешает.
lolol
> не "Фигушки!", а множественное наследование.
Это проблема, а не решение.
lolol
> В анриле нет такого шаблона как ECS и это никому не мешает.
Как никому не мешает писать ОО программы отсутствие поддержки ООП в ЯП.
lolol
> В анриле нет такого шаблона как ECS и это никому не мешает.
Видел проекты на entt+UE4. Да даже тут на форуме был такой.
gudleifr
> Это проблема,
Для кого-то может и проблема, но для большинства программистов - нет.
gudleifr
> Программистов не бывает.
https://track24.ru/google/?q=%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0… 0%D0%B5%D1%82
gudleifr
> Корова, ты че?
Яблочка хочется ;)
totoro
> Ну не скажи, для стоматологов это например повод содрать с тебя экстра кэш, поскольку «итшникам» хорошо платят.
Помнится они в договоре об оказании услуг просят указать чем занимаешься.
Когда я попросил в договоре указать вид услуги который я сейчас буду проходить, а именно просто "обследование" и цену на это, там началась паника и бегание девочек к вышестоящим управляющим, в итоге долгих споров они указали в дговоре что я просил, остальной народ я так понимаю любые договоры подписывает не читая, а потом удивляется почему их опрокинули на деньги.
