Это всё относится к работе с файловой системой (пример с FileSystemDataStorage). Название или целый путь до файла — это ключ, по которому происходит запись.
Сформированный путь до файла может храниться как готовый ключ в KeysProvider (типа "Game/Save/Data.ini").
Но если помимо этого хранилища в проекте используются другие, то скорее всего ключ будет иметь укороченный формат (типа "Data"), и тогда для реализации с файловой системой потребуется ключ как-то декорировать, чтобы получить полный путь.
Декорировать нужно как: префиксом к ключу (корневая директория) и постфиксом (расширение файла).
Это можно сделать в самой FileSystemDataStorage (см. метод GetFilePath).
Или наделать декораторов для IKeysProvider (пример с KeysProviderPrefixDecorator).
Сложность итогового решения зависит от того, насколько гибкое и разнообразное поведение нужно иметь в проекте. Чем меньше гибкости требуется, тем меньше необходимость во всяких избыточных абстракциях, декораторах и сущностях.
Они никогда Unreal Engine и не догонят – ни бюджеты, ни масштаб не сопоставимы. 3D Engine – лишь более широкое позиционирование, не исключающее из себя разработку игр. Час назад вышло наглядное Live Coding видео с фестиваля про прототипирование игры на Unigine: https://vk.com/video-43210579_456239527
Команда у них большая и подразделения разные. Копошатся и в рендере, и в других аспектах продукта. И будут копошиться дальше, пока движок существует. Что подразумевается под Game Framework? Unigine – это игровой движок, на котором разрабатываются в т.ч. и игры. Список выпущенных проектов приведён на скриншоте. В разработке находится GoRace. Множество энтузиастов делают пет-проекты. Какой ещё фреймворк нужен?
Приведу, всему своё время. Подобной базы может и полно, но почему-то понятнее от этого многим не становится. В первой части я свою позицию обозначил. У этих статей есть определённая ЦА и уже обкатанный порядок повествования. Если для вас данные выкладки понятны и известны, то и поиск нормальных качественных примеров неткода уже не будет проблемой.
Больше – говорящая голова, но разрабатывать тоже доводится 🦜 Делал разнообразные игры и околоигровые приложения. Последний релиз, которым можно публично поделиться – RuStore(https://clck.ru/3CAjuM)
Основной поинт скорее в том, что если хочешь пробежать марафон, то сначала нужно потренироваться на более коротких дистанциях.
В текущей ситуации без опыта игроделам сложно устроиться в серьёзную студию разработки, где бы им платили и поделились опытом. Поэтому они часто попадают в самопальные стартапы или самоорганизуются в инди-группки, для которых актуально изложенное в посте.
"Игры мечты", как правило, слишком амбициозны для таких команд. И перед тем, как делать подобные проекты, нужно научиться работать в команде, планировать и вести разработку, изучить все этапы и процессы разработки. Результатом этих навыков будет, может и не в срок, но худо-бедно хотя бы завершённый проект.
Маленький проект - не означает проект, в который разработчики сами бы не стали играть. Это как "тёплое с мягким". Начинающие команды просто хотят "всё и сразу". А нужно начинать с "чего-нибудь, но законченного и реализуемого". Если нет идей по более скромным проектам, всегда можно "игру мечты" упростить. И постепенно дальше её развивать патчами, сиквелами или аналогами.
Стим, Google Play, AppStore и множество других площадок – это , в первую очередь, площадки, куда можно и своё портфолио сгружать. Это нормальная практика увеличить ценность своего резюме ссылками на завершённые и опубликованные проекты. Сколько они там получили денег и внимания – вопрос уже второй. Тут покупатели сами "проголосуют рублём". Кому нужно, те пройдут мимо и даже не узнают о таких проектах. А кто любит поделки из "нижнего интернета" будут рады новинкам от начинающих игроделов. Тем не менее, команда получит необходимые навыки и станет на шаг ближе к своей "игре мечты" или к найму в серьёзную организацию.
Думаю, что в контексте повествования этот вариант был предложен как "простой" и "бесхлопотный" для начинающей аудитории, чтобы не усложнять видео и не распыляться на косвенные темы по детальной настройке. Может быть в других роликах этот вопрос раскрывается более подробно.
Преимущественно для тестирования приложений на различных реальных моделях смартфонов. Это позволяет штатно (а не у реальных клиентов по факту) убедиться в корректной работе на конкретных представителях целевых устройств. Соответственно чем больше и разнообразней ферма — тем больше выборка.
Вариантов устройств много, у всех разные версии ОС и аппаратная часть — сложно сделать что-то так, чтобы это гарантированно по умолчанию работало на всём и хорошо.
Также парк устройств позволяет делать замеры фпс, нагрева, энергопотребления и пр, контролировать изменение этих показателей от версии к версии и проводить более конкретные работы по оптимизации на тех устройствах, где наблюдаются наиболее серьёзные проблемы.
Похожий опыт, только я после двух лет на M1 уполз обратно на Win и не могу нарадоваться. По Spotlight — у Win есть Power Toys. По играм — на Mac отлично играется. В 32-битное "ретро" или в самый "некст-ген", думаю, не получится, но в остальном: у доли проектов есть нативная поддержка, а где нет — работает эмулирующий софт. Но это всё мб действительно не про Air-версию. Если совсем приспичит — есть облачный гейминг. Для не скоростного геймплея гоняется весьма недурно.
+
Это очень хороший вопрос 🙏 Ранее верно подметили - ассет для Unity. Добавил уточнение в заголовок 📝
Благодарю за замечание, smoke test не провёл – обновил 🥲
правы были старожилы — надо было котиков, зря не послушал
Не эквивалентен, но включает в себя
Unity сейчас посажена на .NET Frameowk 4. Последние несколько лет пытаются обуздать CoreCLR, но по этому фронту пока всё тихо
Полностью согласен 💯
Да хоть в `.жпг` 😁
Это всё относится к работе с файловой системой (пример с FileSystemDataStorage). Название или целый путь до файла — это ключ, по которому происходит запись.
Сформированный путь до файла может храниться как готовый ключ в KeysProvider (типа "Game/Save/Data.ini").
Но если помимо этого хранилища в проекте используются другие, то скорее всего ключ будет иметь укороченный формат (типа "Data"), и тогда для реализации с файловой системой потребуется ключ как-то декорировать, чтобы получить полный путь.
Декорировать нужно как: префиксом к ключу (корневая директория) и постфиксом (расширение файла).
Это можно сделать в самой FileSystemDataStorage (см. метод GetFilePath).
Или наделать декораторов для IKeysProvider (пример с KeysProviderPrefixDecorator).
Сложность итогового решения зависит от того, насколько гибкое и разнообразное поведение нужно иметь в проекте. Чем меньше гибкости требуется, тем меньше необходимость во всяких избыточных абстракциях, декораторах и сущностях.
Они никогда Unreal Engine и не догонят – ни бюджеты, ни масштаб не сопоставимы.
3D Engine – лишь более широкое позиционирование, не исключающее из себя разработку игр.
Час назад вышло наглядное Live Coding видео с фестиваля про прототипирование игры на Unigine:
https://vk.com/video-43210579_456239527
Команда у них большая и подразделения разные. Копошатся и в рендере, и в других аспектах продукта. И будут копошиться дальше, пока движок существует.
Что подразумевается под Game Framework? Unigine – это игровой движок, на котором разрабатываются в т.ч. и игры. Список выпущенных проектов приведён на скриншоте. В разработке находится GoRace. Множество энтузиастов делают пет-проекты.
Какой ещё фреймворк нужен?
На этапе форматирования отвалилась, добавил 🫠
https://leanrada.com/notes/sweep-and-prune/
Хотел предложить
Приведу, всему своё время.
Подобной базы может и полно, но почему-то понятнее от этого многим не становится.
В первой части я свою позицию обозначил. У этих статей есть определённая ЦА и уже обкатанный порядок повествования.
Если для вас данные выкладки понятны и известны, то и поиск нормальных качественных примеров неткода уже не будет проблемой.
Да
Комментарии, которые сами о себе говорят лучше других, мета-бесценны ❤️
Если вижу кривой сгенерированый комментарий, то считаю, что сам автор сгенерирован.
Зачем он нужен? Впрочем как и комментарий.
Больше – говорящая голова, но разрабатывать тоже доводится 🦜
Делал разнообразные игры и околоигровые приложения.
Последний релиз, которым можно публично поделиться – RuStore(https://clck.ru/3CAjuM)
Основной поинт скорее в том, что если хочешь пробежать марафон, то сначала нужно потренироваться на более коротких дистанциях.
В текущей ситуации без опыта игроделам сложно устроиться в серьёзную студию разработки, где бы им платили и поделились опытом. Поэтому они часто попадают в самопальные стартапы или самоорганизуются в инди-группки, для которых актуально изложенное в посте.
"Игры мечты", как правило, слишком амбициозны для таких команд. И перед тем, как делать подобные проекты, нужно научиться работать в команде, планировать и вести разработку, изучить все этапы и процессы разработки. Результатом этих навыков будет, может и не в срок, но худо-бедно хотя бы завершённый проект.
Маленький проект - не означает проект, в который разработчики сами бы не стали играть. Это как "тёплое с мягким". Начинающие команды просто хотят "всё и сразу". А нужно начинать с "чего-нибудь, но законченного и реализуемого". Если нет идей по более скромным проектам, всегда можно "игру мечты" упростить. И постепенно дальше её развивать патчами, сиквелами или аналогами.
Стим, Google Play, AppStore и множество других площадок – это , в первую очередь, площадки, куда можно и своё портфолио сгружать. Это нормальная практика увеличить ценность своего резюме ссылками на завершённые и опубликованные проекты. Сколько они там получили денег и внимания – вопрос уже второй. Тут покупатели сами "проголосуют рублём". Кому нужно, те пройдут мимо и даже не узнают о таких проектах. А кто любит поделки из "нижнего интернета" будут рады новинкам от начинающих игроделов.
Тем не менее, команда получит необходимые навыки и станет на шаг ближе к своей "игре мечты" или к найму в серьёзную организацию.
Про сами процессы и их выстраивание – в приложенном стриме. Я только оставил свои мысли про отсутствие этих процессов во многих инди-командах.
Думаю, что в контексте повествования этот вариант был предложен как "простой" и "бесхлопотный" для начинающей аудитории, чтобы не усложнять видео и не распыляться на косвенные темы по детальной настройке. Может быть в других роликах этот вопрос раскрывается более подробно.
виноват 😟
Преимущественно для тестирования приложений на различных реальных моделях смартфонов. Это позволяет штатно (а не у реальных клиентов по факту) убедиться в корректной работе на конкретных представителях целевых устройств. Соответственно чем больше и разнообразней ферма — тем больше выборка.
Вариантов устройств много, у всех разные версии ОС и аппаратная часть — сложно сделать что-то так, чтобы это гарантированно по умолчанию работало на всём и хорошо.
Также парк устройств позволяет делать замеры фпс, нагрева, энергопотребления и пр, контролировать изменение этих показателей от версии к версии и проводить более конкретные работы по оптимизации на тех устройствах, где наблюдаются наиболее серьёзные проблемы.
Похожий опыт, только я после двух лет на M1 уполз обратно на Win и не могу нарадоваться.
По Spotlight — у Win есть Power Toys.
По играм — на Mac отлично играется. В 32-битное "ретро" или в самый "некст-ген", думаю, не получится, но в остальном: у доли проектов есть нативная поддержка, а где нет — работает эмулирующий софт. Но это всё мб действительно не про Air-версию.
Если совсем приспичит — есть облачный гейминг. Для не скоростного геймплея гоняется весьма недурно.