Pull to refresh
9
Karma
0
Rating
Волошин Юрий Александрович @Neongrey

User

[Анонс] Global Game Jam 2020 в конце января

Я разработчик Unity. Планирую принять участие. Ищу людей/команду.

Игра за час или убиваем время в Unity

А что делать, если я не хочу двигать объект физикой?
Мне нужно двигать объект и считать его коллизии. Например, у меня Tower Defence или клон Zuma. Мне нужно просто, с постоянной скоростью двигать объект из одной точки в другую.Но коллизию можно посчитать, только если есть ригидбоди.
Как именно вы предлагаете двигать объект, если не через трансформ? Вместо того, чтобы просто задать объекту новую точку, постоянно прикладывать и убирать силы?
Или через трансформ, но в Fixed Update?

Игра за час или убиваем время в Unity

А можете мне пояснить ваш пункт 1?

Unity: система сохранения для любого проекта

Хм. Меня, похоже, не поняли. Синглтон я использую только как демонстрацию наследования статических полей. И попутно показываю, что есть такой способ делать синглтоне, если кому надо. Моя система сохранения не основана на синглтоне. Она основана на обобщённом классе поведения (контроллере), которому можно передать любую модель и таким образом легко получить сохраняемый объект, просто определив поля и не реализуя один и тот же функционал каждый раз. А потом все такие объекты можно сохранить вызовом одной функции.

Unity: система сохранения для любого проекта

Блин, классы взаимодействуют, куда от этого деться? Я предполагаю, что если человек использовал синглтон, значит, ему реально позарез надо обращаться от одного класса к другому. Для примера можно взять игрока. Методы получения урона и гибели одинаковы у игрока и врага. Но на гибель игрока игра должна особым образом реагировать. Посылается событие person.ondead, а игра должна проверить, не игрок ли преставился.
Это для примера. Я пытался сказать, что если синглтон кажется разработчику подходящим решением, то недостатки сильной связности можно устранить интерфейсами и наследованиями


Ну и компоненты у меня — тоже тут никуда не денешься. Шутер, коллизии, физика, трансформы всякие. Тут единственный способ избавиться от юнити — писать свой движок

Unity: система сохранения для любого проекта

1) Чтобы кто угодно не изменял, делаешь public get protected set
2) Я делаю следующим образом: все поля в модели public, но сама модель видна только своему контроллеру
3) Статичные публичные — у меня обычно методы. Вот тот же SaveLoadBehaviour. У него
protected static List All
А вот методы SaveAll, LoadInitAll — публичные.
4) Мне надоело писать для синглтонов MyClass.Instance.DoMethod(), я делаю MyClass.DoMethod() и в нем уже на статический инстанс ссылаюсь.
Т.е. может дело не в синглтонах, а в том, чтобы правильно их готовить?

А повышение связности когда — опять же, помогут прямые руки и ООП. Для заменяемости/удаляемости пользуйся интерфейсами, и будет тебе счастье.
В моей статье предложен подход:
1) абстрактный класс со статик полями
2) от него наследуется обобщенный класс для работы с разными моделями
3) от обощенного — конкретная реализация

Тот же подход можно применить для синглтонов
1) Интерфейс, определяющий желаемое поведение синглтона IAdapter
2) Обобщенный синглтон GenericSingletone3) Абстрактный класс, наследующий от синглтона и интерфейса.
SingletoneOne: GenericSingletone, IAdapter
4) Если мы по примеру 3 сделаем SingletoneTwo, то у них буду разные static Instance
5) А вот если мы унаследуем от SingletoneOne, то у SingletoneOne_1 и SingletoneOne_2 статический инстанс будет общим!
6) Соответственно, во всем коде работаешь с SingletoneOne.Instance.AdapterMetod()
7) А конкретную реализацию меняй как вздумается.

Unity: система сохранения для любого проекта

Я стараюсь использовать в Unity как можно меньше Unity. Ибо в реальных проектах, которые на работе за зарплат, логика часто shared или серверная.
А еще можно взять shared бизнес-логику, скомпилировать в dll и перенести на Unreal. Поэтому имхо чем меньше ScriptableObject, MonoBehaviour и прочего using UnityEngine, тем лучше.

Unity: система сохранения для любого проекта

А в чем проблема с синглтонами и статичными переменными сложных типов?

За утилиту спасибо: о)

Unity: система сохранения для любого проекта

Но вообще есть нюанс. Из разряда «нам бы ваши проблемы». Переносимость сохранений из МегаИгра1 в МегаИгра2: Воскрешение.
Мы не можем гарантировать, что какой-нибудь умник не переименует класс. Да может быть мы сами в процессе разработки что-то переименуем. И, предположим, у нас есть несколько сохранений, чтобы тестировать игру в разных местах (ну вдруг).
Короче, надо об этом очень сильно помнить.

Unity: система сохранения для любого проекта

1) Я лично слабо представляю, как в PlayerPrefs хранить весь мир Fallout4
2) Ну и переносимость сохранений.
Так что файлы наше всё

Unity: система сохранения для любого проекта

В Юнити нельзя предсказать, в какой последовательности объекты сохранятся. И, следовательно, в какой последовательности будут храниться и загружаться.
Вообще, может, и можно: создать вручную начальное сохранение, а потом читать из него в заранее заданном порядке в начале игры, в этом же порядке хранить в коллекции и в этом же порядке записывать.
Но вообще бывает такая вещь как крафт: о) И расход ресурсов. И смерть (исчезновение) персонажей.
В общем случае набор сущностей в игре непостоянный, поэтому «сразу знать, что и где» — негибко.

Unity: система сохранения для любого проекта

Суть-то как раз в том, чтобы сделать решение, которое ложится на любой проект. Чтобы одно и то же по сто раз не писать.
И у меня пока что нет сохранения в файл, всё хранится в оперативке — и в этом все равно есть смысл, ибо загрузка последнего сохранения (чекпоинта) и рестарт уровня.

Unity: система сохранения для любого проекта

1) Спрячте под спойлер, пожалуйста.
2) Можно ли так сериализовать тип? Чтобы ридер сам знал, что читает из файла?
3) Можно ли так сериализовать всё в один файл (из коллекции) и потом прочитать это же всё и создать нужные объекты?
4) насколько удобно это для передачи по сети?
2-4 — потому что я никогда не работал с бинарной сериализацией, я во многих вопросах еще нуб.

Unity: система сохранения для любого проекта

Выглядит очень похоже на правду.
Я тоже так не пробовал. Если добавить в мое решение автоматическое полное копирование объектов, автоматическую сериализацию и автоопределение типа, то будет полностью завершенное решение.

Unity: система сохранения для любого проекта

Новое поле добавляется в модель. Копирование модели в модель пишешь сам. Хотя по идее должно же быть встроенное средство копирования объектов.
А каркас остается. Я сначала на геймсджем писал игру про котосминогов и сделал там эту систему сохранения. А потом для тестового задания про шутер просто использовал ее же, заменив модели. До самого последнего момента не знал, заработает ли. Вызвал в GameManager AbstractSaveLoad.LoadInit() для рестарта матча — и все заработало.
Конечно, лучший код — ненаписанный код и кнопочка «Сделать прекрасно». Но чем богаты.
Во всяком случае добавление новых сохраняемых сущностей происходит максимально безболезненно, проверено на двух разных проектах.

Unity: система сохранения для любого проекта

Насчет глобальных синглтонов не знаю. Но я у себя сделал самый закрытый менеджер игры.
Он у меня — такой мост между всеми подсистемами. Слушает события и вызывает нужные функции. А к самому нему никто доступ не имеет.
Все, что с ним можно сделать — проинициализировать (ну, чтобы он хоть как-то появился в памяти).

Максимально закрытый GameManager
public class GameManager
    {
        static int EnemiesCount;
        static int EnemiesCountCurrent;
        static float MatchStartSeconds;
        static PlayerController player;

        public static void Init()
        {
            player = GameObject.FindObjectOfType<PlayerController>();
            player.OnDamaged += OnPlayerDamagedHandler;
            AbstractAliveController.OnDead += OnAliveDeadHandler;
            EnemiesCount = GameObject.FindObjectsOfType<NPC.Enemy.EnemyController>().Length;
            UI.UIController.OnRestart += RestartMatch;
            InitMatch();
        }
}

Is Grounded в 2D платформере: как узнать, стоит ли персонаж?

О да. мои звезды благосклонны. Загадка… Можно в ту формулу внести какую-то дельту
if (point.y — bounds.min.y < 0.001) типа того

Is Grounded в 2D платформере: как узнать, стоит ли персонаж?

Уговорили, нате картинку: о)

image

Is Grounded в 2D платформере: как узнать, стоит ли персонаж?

Да. Это делается стандартными средствами юнити. А вот отличить в самом коде платформу, на которой ты стоишь от платформы, через которую ты идешь, отличить именно "коллизию стояния" — это то, что делает моё решение.

Is Grounded в 2D платформере: как узнать, стоит ли персонаж?

Надо, чтобы он прыгал толкьо когда стоит. Задача — в том, чтобы определить, что персонаж прямо сейчас стоит.
Сложно не сделать прыжки и ходьбу сквозь платформу — сложно отследить, что персонаж стоит, с учетом того, что персонаж может прыгать-ходить сквозь платформы, двигатсья вместе с платформами, платформы могут быть наклонными и т. д.
Т.е. ни вертикальная скорость персонажа, ни пересечение с платформой, ни положение платформы и персонажа друг относительно друга не являются показателями того, что персонаж стоит.
Так что недопоняли, да.

Information

Rating
5,901-st
Location
Волгоград, Волгоградская обл., Россия
Date of birth
Registered
Activity