Фреймворки обобщают и стандартизируют подходы и практики в разработке. Таким образом они действительно ускоряют разработку но я бы не сказал что это резко. Скорее в твою работу становится легче вносить правки. Проще дебажить и расширять архитектуру игры.
Новичкам нет смысла применять фреймворки пока просто на языке не научишься писать сносно ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Воскресенье, 26 Мая 2019, 21:01
Ваще не понимаю, зачем нужны все эти ::, auto const &[]:, <type>, <<, >> и прочая бесовщина.
Да и не надо понимать если не хочешь : )
ЦитатаTimKruz ()
Если отбросить инфантильные мечты — ничего по-настоящему не хочется, и это вгоняет в депрессию. Если фокусироваться на тех мечтах — реализовать их не выходит, и это вгоняет в депрессию.
И про твой оффтоп.
ЦитатаTimKruz ()
если бы увидел в этом значимость выше своей идеи-фикс
Исходя из поста у меня не сложилось впечатления что тебе ничего не хочется. Кажись тебе бабы хочется XD Нормальное такое желание. Роботяны и прочая хренота просто отмазы
ЦитатаTimKruz ()
малейшие неудачи заставляют меня всё бросить и углубиться в страдания ("аааа! опять как-то не так рисуется! какое же я ничтожество, даже такую бесполезную фигню сделать не могу!")
Ну смотри, мы с тобой в одной лодке. Я рисовать тож не умею. И кучи вещей делать не умею. Но эт не делает меня ничтожным по отношению к тем кто умеет. Ты то должен понимать что любой навык это пот, труд и опыт. Почему ты позволяешь себе неуважать чужое ремесло считая что у тебя вот просто так что-то должно взять и получится на одном только твоем желании?
Нормальная реакция для человека обесценивать то, что ему нравится, но получить не может. Мозгу так проще.
Не надо быть 7 пядей во лбу чтобы быть счастливым. Не надо чего-то сильно хотеть чтобы быть счастливым. Надо принять себя и двигаться дальше. Всё нытье что ты писал - эт не ты Это та матрица что ты себе придумал чтобы не было больно по-настоящему.
Искренне желаю тебе найти сил разобраться во всём этом. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Воскресенье, 26 Мая 2019, 06:30
Но я уже смирился, что мой путь — это к тем поехавшим одиночкам, которые мнят себя великими изобретателями, а на деле несут какой-то бред, в огромных масштабах (для примера, есть один форум по ИИ, так там как в дурдоме — все такие сурьйозные, а говорят в основном о совершенно бредовых вещах, далёких от практической разработки). Так-то нет особой разницы, пытается человек изобрести вечный двигатель, найти философский камень, сформулировать общую концепцию всего или запрограммировать компьютер на человекоподобное поведение... Короче, всё очень плохо у меня.
Ты просто честно-честно ответь себе чего ты действительно хочешь. И все встанет на свои места : ) Не прячься и не играй в игры разума. Все на поверхности. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
(Это основная причина, почему я пилю велосипеды и ненавижу обмазываться готовыми библиотеками. Моя мечта (одна из) — сделать свой ЯП, на котором никогда не будет чужих библиотек, и писать на нём лично. В гордом одиночестве. Что мне будет угодно.)
Зачем ?
ЦитатаTimKruz ()
Проблема тут только в том, что не все могут правильно разделить проект на самостоятельные и независимые уровни. Например, я уже писал тут, что код должен работать даже отдельно от остального кода — это означает не только то, что любая из подсистем игрового движка должна запускаться отдельно от остального кода движка, но и любой существенный фрагмент кода не должен зависеть от всего остального кода (т.е. если воткнуть в другую программу, его поведение не изменится).
Как я понимаю, в этом и должно заключаться ООП. Мы создаём "объекты" как нечто, что существует само по себе, и нас не должно волновать, какие внутренности в них спрятаны (пока эти внутренности оправдывают наши ожидания). Но это возможно, только пока объекты остаются маленькими и понятными (подразумевается собственный код объекта, а не суммарно с вложенными объектами)
Решается через ecs. Ненужны сложные классы, интерфейсы, "объекты" , наследования и прочая муть Есть данные, есть обработчики. На ооп языках реализуемо. Клац
Непонятно о чем именно идет речь. О каком коде мы с тобой говорим? О коде игры или движка?
У меня код условно разделен на три дома:
->Фреймворк и общие утилиты. Максимальное абстрактный код идущий под все проекты. ->Общие игровые системы подходящие однотипным играм. Они переносятся так же под проекты без перезаписи. На самом деле у меня таких систем оч мало. В основном это системы инпутов, простой физики и движений. И то в чистом виде обычно переносятся только инпуты. ->Специфические игровые системы под конкретную игру. Хотя архитектура позволяет скопировать все компоненты и системы в другой проект в этом нет никакого практического смысла. Они необходимы только в контексте конкретной игры и трата времени на излишнюю абстракцию в попытке сделать их "универсальными" только мешает работе.
Если кратко: оптимизации кода не должны быть во вред читаемости кода.
ЦитатаTimKruz ()
Эм, где-то вычитал, что по отношению к коду "красиво" = "понятно".
Цитата
Ты прав. Лишние вызовы ни к чему. Поэтому мой игровой движок максимально прост: Код begin GameEngine := TGenGECore.Create(Configuration); GameEngine.Run; end.
Понятно - растяжимо. Тебе может быть непонятно в силу того что твои знания недостаточны и ты просто не в состоянии адекватно оценить этот кусок кода. Не надо за уши притягивать и показывать свои сахарные обертки. Сокрытие работы не имеет ничего общего с понятностью. Те кто будут именно поддерживать твой код будут работать не с обертками а с тем что ты скрываешь за своим Create. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Пятница, 24 Мая 2019, 13:12
CodeMyGod , возможно тебе кто-то сказал что стримить круто. Или ты сам себе это придумал, но это не так. Посуди сам. Стримеров как собак. Знаешь почему? Порог вхождения ниже чем даж у тех же недоразработчиков на конструкторах или юнити. Ну по чесноку. Снимаешь же видосы чтобы хайпануть? : ) пользы то никакой. Бывают развлекательные видосы про разработку, но там решает харизма человека. Более того как правило он разбирается в теме и это видно.
Судя по профилю тебе 16. Я хз что ты там думаешь себе, но лучше потрать пару лет на реальное обучение а потом уже думай о своем предназначении и роли в социуме / заработке. Вот пример полезного канала по играм Парень на пару лет старше тебя, много практикуется, есть стиль. Да, большая часть его видосов могут быть наивными по юнити, но для небольших игр он отлично освоил инструменты и ремесло. И его интересно слушать.
Сделай правильные выводы : ) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Четверг, 23 Мая 2019, 11:12
1. Каким бы понятным код не казался автору - другие не всегда будут его таким находить, ты то его видишь каждый день и очень долго. В слепую можешь сказать примерно что где. Более того скорее всего уже давно в голове визуализировал ( мнемотехника ). Абсолютно не имеет значения для посторонних как ты пишешь. Ваша группа должна быть на одной волне и писать единообразно. Тем кто работает над конкретным кодом он должен быть "понятен" и не более. Если все адекватно и структуризировано можно разобраться при необходимости в чужом коде даже если ты находишь его "некрасивым". ( Тому кто тебе платит глубоко ***** красивый код или нет )
ЦитатаTimKruz ()
И не надо про оптимизации, что лишний вызов подпрограммы замедляет программу, что длинные имена занимают больше места на диске и т.д. Мы не в 90-х,
Ты очень, очень сильно сейчас заблуждаешься : ) Нормальные люди ( я даже сейчас не применяю это к сфере программирования ) стараются не усложнять себе жизнь. Программиисты тут ничем не отличаются. Но если бы было все так просто все бы писали игры на lua. Ну ты ж не думаешь что одной половине открыто сакральное знание простоты, а эти казалось бы умные программисты зачем-то пишут непонятную простым смертным херь. Просто чтобы позлить другую половину.
Фантазии, амбиции и масштабы игр растут быстрее чем обновляется железо которое на тех же консолях оставляет желать лучшего ( ровно столько сколько надо ).
Оптимизировать все подряд - глупо, но точно не надо принижать труд людей которые делая низкоуровневые вещи позволяют тебе писать так высокоуровнево как ты хочешь : ) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Среда, 15 Мая 2019, 10:22
Есть пример программы aseprite, которая есть на github, но также продаётся и в steam. Готовы ли вы выложить код на github, чтобы любой желающий мог понять как ваша игра работает? В таком случае возможно что её никто не будет покупать, все будут качать на github. Я бы например не хотел бы выкладывать код. Пусть мне и нравиться как код написан, но я всё равно не хочу, чтобы кто нибудь его читал и играл бесплатно, кроме меня.
Кому надо найдут и прочтут ; ) Например на юнити сейчас каждая третья игра) ну в любом случае оч распространненый движок. Если собран под моно то открыть код игры не сложно.
Скажу больше - еще заинджектить можно разного чтобы интереснее игралось XDD Вопрос твой не имеет смысла ибо выложив проект в доступ ты уже поделился своим кодом.
Цитата
Так что, возможно, брать за основу сложные проекты даже проще, чем какие-то простые, потому что в них всё за тебя уже сделали)
Не проще. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Вторник, 14 Мая 2019, 07:52
Последний плюс у годота - мне не обязательно для создания синглтона иметь какой-то объект на уровне, чтобы из этого объекта инициализировать первый раз синглтон, в годот можно синглтон не вызывать из какого-нибудь объекта с уровня, а просто добавить в таблицу синглтонов.
Тебе не обязательно создавать синглтоны на юнити объектах - можно на обычном классе сделать : ) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Вот смотри у тебя допустим есть дети, дети растут развиваются, втягивают в себя всю доступную информацию, и ты думаешь что система устойчива и работает как надо. Но в один прекрасный день ты узнаешь что твое "дите" ушло с головой в порно индустрию или сразу в "эскорт". pixeye насколько твоя радость будет велика?
Очень абстрактный пример. И не совсем уверен, что он имеет отношение к теме этого разговора. Я был бы крайне наивным человеком если бы полагал что все устойчиво и работает "как надо" ( кстати, кому надо-то? ) Тогда уж почему бы не оградить ребенка 4 стенами и не отключить интернет. Будет расти в зеленом мире фантазий и того что ему скажет родитель.
Я привык отвечать за выбор, а не дуть на последствия. Если ты дал доступ к интернету значит автоматически принимаешь факт что ребенок может увидеть что-то нежелательное ( и кстати я не про порно, пусть смотрит ). И никакая сила уже не оградит его от получения информации. Так какое моральное право имею я быть довольным или недовольным выбором ребенка в его деятельности и жизненном пути?
Хочет заниматься порно - его право и жизнь. Как и последствия если они имеются. Вот это бы я постарался ребенку с ранних лет объяснить: любое деяние ведёт к цепочке последствий. Если ты это обдумал и принял - все хорошо.
ЦитатаRage_of_life ()
то в реале когда на тебя давят и за твой счет самоутверждаются проблема, так как ты теряешь ресурсы и положение. Ну а если вы так же реагируете на вирт как на реал то тут серьезная проблема, есть над чем задуматься.
Для меня нет разделения "вирт", "реал". Это разделение вообще-то ближе к шизе уже Я живу в реальном мире. Слова как и поступки имеют вес. Не имеет значение где это происходит.
И я не уверен чего именно хочешь добиться ты. Посуди сам. ТС тебя не услышал и агрится. Значит мысль до него ты не донес. Так к чему тогда всё эт? : ) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Несмотря на бесполезность канала, я не понимаю реакции Rage of life. Ну новое поколение смотрит на ютуберов, хочет так же. Критиковать - нужно и полезно. Унижать, оскорблять и самоутверждаться за счет других - нет. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Если все происходит в одном кадре, как на скрине, то ничего качать не надо. Есть такая штука:
Чтобы пользоваться этой штукой надо кучу строчек написать и еще в конце вызвать дебаг лог. Я же предлагаю это в три строчки ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Жрёт ли GetActive() ресурсы системы или это работает также быстро, как проверка boolean?
Если это хотя бы на миллисекунду дольше, то я тогда лучше буду и дальше дополнительные переменные создавать. Оптимизация очень важна.
Очень важно не нервничать, правильно питаться, крепко спать и совокупляться. Это гарантированно избавит тебя от оптимизации ради оптимизации.
Прежде чем ты будешь говорить об оптимизации - оптимизации чего? Памяти, быстродействия или твоего воркфлоу? Ведь оптимизированный код как правило далеко не самый читабельный и удобный в работе. Ты создаешь вот bool - а зачем? это 1 байт.
Вместо кучи булевых переменных почему бы не сделать bitarray ?
Чтобы не мучаться вопросами как делает это юнити надо смотреть на методы юнити : )
Да - это тоже прослойка, обращение через нее будет ЧУТЬ медленее но настолько ли чтобы ты парился об этом? Если тебе интересно узнать об этом больше, почитай статьи этого мужика.
В общем вот тебе совет 1) знай проблему в лицо. 2) всегда проводи тесты сам. Сомневаешься в чем-то - протестируй. Как это лучше всего сделать? Скачай профайлер. Это два скрипта. После этого ты сможешь делать так
В твою консоль в редакторе будет выдаваться время за которое операция между start и end произошла. В райнтайме записывается в лог. Оч удобно. 3) Тестируй всегда на собранном проекте, тесты в редакторе не дадут точных значений. В редакторе можно тестить только относительно старого результата ( типа быстрее/медленее ) 4) Удобство работы важнее оптимизации. 5) Оптимизируй только узкие места к которым ты потом будешь оч редко возвращаться. Как правило это относится к системам, движкам и прочим подобным штукам. Оптимизировать кучу игровых скриптов чтобы потом из-за изменений в дизайне их выбросить малоприятное занятие 6) Это не значит что надо писать треш. Многие мелочи которые ты бы назвал оптимизацией я бы пометил как понимание инструмента с которым работаешь. 7) Код логики игры как правило последнее что создает проблемы для производительности. Особенно если твоя игра несложная и содержит мало элементов. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Четверг, 04 Апреля 2019, 12:11
Не могу относиться серьезно так как явно анализ высасан из пальца и очень поверхностен. У того же юнити есть прекрасный БОЛТ Как по мне лучше сделать удобными ( что субъективно ) те движки которыми реально пользуются - а пользуются юнити. И тот же болт активно процветает на нише фреймворков без кода.
Ну и как по мне это все хрень и вот почему.
Программирование не про знание языка как по мне, а про логику. Чтобы чет сделать нужно осмыслить, сформулировать задачу, подобрать инструмент и провести реализацию. Как ты это сделаешь - на кубиках или текстом - это второй вопрос. Но чтобы эффективно что в визуальном вариате что в IDE чет написать надо понимать куда копать. У абсолютных новичков нет этих навыков и соответственно нет разницы для мозга что учить - язык или методы API твоего конструктора которыми ты забьешь их неокрепший мозг. Второе даже хуже потому что скорее всего они придут к мысли что надо переучиваться и переходить на что-то более гибкое.
Окрепнув возникает резонный вопрос - что быстрее. Напечатать текст емко и понятно или сделать лапшу из блок схем.
Давай поставим вопрос так. Я не хочу учить русский язык. Сложный, мутарный и долгий. Может будем говорить на ЭМОДЗИ?
Твой рейкаст возвращает структуру типа RaycastHit2D - он ее всегда возвращает независимо от того стукнулся об объект или нет. А вот collider - это уже собственно компонент тела об который рейкаст бьется. На следующей строчке ты пишешь Debug.Log("Hit with: " + hit.collider.name); так будто бы гарантированно знаешь что столкновение произойдет
Код
var hit = Physics2D.Raycast (new Vector2(transform.position.x, transform.position.y), Vector2.right, RayLenght, 0, -1, 1); if (hit.collider != null) Debug.Log("Hit with: " + hit.collider.name);
Это на тему твоей ошибки.
Теперь насчет того в чем проблема луча. Помимо прочего если твои коллайдеры - триггеры то помочь может это Queries Hit Triggers -> true в настройках физики2д
Я бы первоначально не менял слои и не делал никаких доп настроей в рейкасте
Код
Physics2D.Raycast (new Vector2(transform.position.x, transform.position.y), Vector2.right); типа такого
