Comments 12
Добились того, что в случае ошибки выполнения запроса для него откатываются все произведенные действия, а следующий запрос в очереди, если он присутствует, отменяется. Откат действий программируется вручную.То есть, если в очереди 2 совершенно несвязанных запроса, то при ошибке в одном из них отменяется и другой? Зачем? К примеру, 1 запрос на строительство чего-то, а второй на скликивание ресурсов/выполнение задания. Пользователю придётся заново второе действие повторять? А если это действие выполняется где-то во внутреннем окне, то это может быть сразу несколько лишних кликов.
Резонное замечание. Суть в том, что с вероятностью 90% запросы, которые выполняются по такой схеме, зависят друг от друга, т.к. используют различного вида ресурсы. Так же помимо ресурсов есть и другие виды логических зависимостей. В вашем примере всё выглядит логично и нет никакого смысла отменять второй запрос. Но на деле нужно либо руками помечать такие команды, либо писать механизм который будет это как-то эвристически определять.
В Unity отсутствует файл с описанием проекта: весь код, который находится в папке Assets, попадает в билд. При таких условиях создавать несколько проектов с общей код-базой сложно. Мы решили, что будем использовать общий репозиторий, в котором проект лежит не в виде Unity-проекта, а в том виде, который нам нужен. С помощью скрипта, который создает симлинки на папку с кодом, мы разворачиваем Unity-проект.
Что-то странное. Можно ведь компилировать сборки вообще отдельно от Unity, и потом подкладывать в проект. В нашем проекте, к примеру, вся кодовая база в виде отдельного солюшена и компилируется в VS в кучу сборок. А в проекте Юнити только пустой объект со ссылкой на стартовый behavior в одной из таких сторонних сборок. И всё прекрасно шарится, делаются нормальные общие библиотечные сборки для разных компонентов. Никаких махинаций с проектом юнити и симлинками.
В этой цитате показывается неосведомленность о том, как Unity собирает проект на самом деле. Если коротко, то из папки Assets в проект попадает только то, что используется на сцене, которая попадает в проект (в настройках билда), либо через префабы которые используются на сцене попадающей в проект — т.е если есть прямая ссылка на asset со сцены тем или иным образом.
100% в билд попадает только содержимое папки Resources и папки Streaming Assets. В первом случае к ресурсам можно обратится через Resource, во втором через File.
Простой способ увеличить скорость компилирования проекта, засунуть библиотечный (не ссылающийся на код игры) код в папку Plugins. Вообще я видел проект на гитхабе который с помощью симлинков тюнил скорость компиляции и гибкий шаринг скриптов между проектами.
100% в билд попадает только содержимое папки Resources и папки Streaming Assets. В первом случае к ресурсам можно обратится через Resource, во втором через File.
Простой способ увеличить скорость компилирования проекта, засунуть библиотечный (не ссылающийся на код игры) код в папку Plugins. Вообще я видел проект на гитхабе который с помощью симлинков тюнил скорость компиляции и гибкий шаринг скриптов между проектами.
У нас все DLLки, собранные VS, кладутся в Assets/Lib. Редактор там их видит (позволяет навешивать behavior'ы из них на объекты сцены, и всё работает при запуске из редактора). Насчёт попаданию в сборку не помню, у нас после сборки Юнити отрабатывают ещё дополнительные скрипты, которые формируют окончательное содержимое пакета, для каждой из платформ. Там и эти библиотеки могут куда-то копироваться, и дополнительные сторонние зависимости, и формируется конфигурационный файл mono, в котором прописывается, где искать различные нативные системные библиотеки на каждой платформе, типа libpng или sqlite).
Кстати, было бы интересно почитать статью об организации подобного проекта, как у вас в комментарии.
Я сейчас занимаюсь разработкой чего-то подобного, и, похоже, собираю грабли ;( от чего проект движется как-то медленно.
Я сейчас занимаюсь разработкой чего-то подобного, и, похоже, собираю грабли ;( от чего проект движется как-то медленно.
Статью, наверно, не осилю (главным образом, потому что в основном занимаюсь разработкой других компонентов на Линуксе, и на Windows и VS переключаюсь с большой неохотой), но здесь в комментариях могу проконсультировать по возникшим вопросам. Почитайте несколько моих новых комментариев, я там в общих чертах описал принципы.
Что значит «стартовый behavior»? То есть на сцене висит GameObject, на котором MonoBehaviour из Dll?
Это используется в качестве точки входа?
Это используется в качестве точки входа?
Да, пустой объект, к которому подцеплен Behaviour из DLL проекта, собранного в VS. Юнити видит все эти дллки и behavor'ы в них, и позволяет выбрать нужный. Связь сохраняется по GUID дллки в meta-файлов проекта юнити.
Ну и дополню, что этот пустой объект единственное содержимое сцены, всё создаётся из кода при старте. В проекте Юнити только ресурсы (картинки, меши). Чтобы можно было использовать VS, нужно в солюшене сделать ссылку на UnityEngine.dll из поставки Unity. Также для VS есть свободный плагин, позволяющий подключаться отладчиком к редактору или плееру (так же, как раньше было в mono develop в комплекте с Юнити). В общем, процесс разработки кода достаточно удобно организуется при таком подходе.
Sign up to leave a comment.
Особенности разработки мобильной MMO RTS. Часть 2