Шаблоны - это SO ( Scriptable Object ) отвечающие за настройки игровых систем, базовые параметры для компонентов и объектов. Шаблоны так же полезно использовать как скрипты благодаря возможности писать логику. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Понедельник, 22 Октября 2018, 12:13
- Атрибут [RequireTag] для компонентов - Actor перестали принимать апдейты и сигналы ( в виду бесполезности при ECS подходе ) , если это все же вам нужно наследуете от MonoActor - Добавлена структура EntityComposer позволяющая собирать или добавлять к имеющимся сущностям новые компоненты в безопасной манере ( инициализировать все компоненты и только потом запустить в системы ) - Чистка API, убирание лишнего функционала. - Samples переименованы в Template - IData интерфейс убран, остался IComponent, ВНИМАНИЕ, сохраните на всякий случай интерфейс IData, он наследовался от IComponent так что на худой конец обратно закинете после апдейта и аккуратно компоненты поправите. - Официально DataComponent теперь просто Component, но можете использовать старые названия если нравится - Рефакторинг - Оптимизация - Поправил работу с акторами при загрузке аддитивных сцен, теперь они должны подгружаться корректно.
Начал работу над wiki - ( установка фреймворка, философия, книга рецептов, основные штуки ) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
У юнити оч много методов связанных с векторами - Не знаю какая у тебя среда но ты можешь кликнув на тот же .forward у transform и зажав f12 посмотреть методы юнити через декомпиляцию
Но скажем так новых законов юнити не придумала) как бы векторы считаются одинаково что на юнити что без юнити )) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Пятница, 19 Октября 2018, 07:37
как можно быть без определенного места жительства в плане денег? Ты непонятный : ( ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Мне хочется попробовать сделать игру из разряда they are billions с большим кол-вом ВСЕГО на экране : ) На скринах 2500 истребителей нападают на базу игрока.
Ну как по мне экономия ~100 фпс существенна. Я могу их использовать где-то еще. Это безу учета того что АИ обрабатывался все равно в системе ( поиск цели, расчеты, выбор поведения ) - если и аи вынести в апдейты то фпс бы дропнулся еще больше.
Насчет современных компов - я вижу моду на miniITX, которые часто собирают не оч мощными. Для инди опять таки сейчас хорошая платформа- nintendo switch, далеко не самая мощная машина. В общем если есть возможность на чем то экономить и это не мешает работе ( реально, код что я выше показал не настолько сложен, жуток или неудобен) - то почему бы и нет. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Пятница, 12 Октября 2018, 11:31
с другой стороны, зачем писать лишний код, ухудшая читаемость и повышая риск допустить ошибки при рефакторинге?.. лучше наоборот весь часто используемый бойлерплейт вынести в расширения/в методы базового класса/в статический класс/еще куда-то, лишь бы не писать это каждый раз
Ну так и есть, опять таки - все эти магнитуды, расчеты углов и прочую муть можно вынести в свои библиотеки. Как по мне вызов рассчета магнитуд два раза и есть лишний код : )
Цитатаdrcrack ()
так, а это что crazy :D
Ты этого не видел XDD, рудиментарный код, можно отрефакторить XD ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
public class ProcessingMove : ProcessingBase, ITick { public Group<DataMove> groupMove; public Group<DataTorque> groupTorque;
private float delta;
public ProcessingMove() { Timing.RunCoroutine(_Tick()); }
public IEnumerator<float> _Tick() { while (true) { for (int i = 0; i < groupMove.length; i++) { var dMove = groupMove.component[i]; dMove.nextRotation = dMove.transform.rotation; }
yield return Threading.SwitchToExternalThread(); for (int i = 0; i < groupMove.length; i++) { var dMove = groupMove.component[i]; var speed = Maths.Min(dMove.speed += dMove.acceleration * delta, dMove.template.speed)*delta; var pos = dMove.nextRotation * new Vector3(0.0f, 1f, 0.0f);
public void Tick() { delta = Time.DeltaTime; for (int i = 0; i < groupMove.length; i++) { var dMove = groupMove.component[i]; var body = dMove.transform; var v = body.position; v.x += dMove.nextStep.x; v.y += dMove.nextStep.y; v.z += dMove.nextStep.z; body.position = v; body.rotation = dMove.nextRotation; }
Согласен с drcrack в том что это все микрооптимизации. Они имеют смысл только при очень частом использовании и это редкие случаи. Если в игре от силы сотня сущностей одновременно что-то делают ( что в общем то не мало ) - то смысла в этом нет + дело вкуса. Например я получил уже магнитуду вектора, а потом мне где-то дальше по методу потребовалось его нормализовать. Если использовать юнитивский метод нормалайз то можно увидеть что внутри он опять таки считает магнитуду. Зачем мне это делать повторно если я уже провел эту операцию? : ) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Пятница, 12 Октября 2018, 10:03
Да, досих пор имеет смысл кешировать трансформ как и в общем любой компонент юнити и вообще обращаться к ним как можно реже. Кешировать будет иметь смысл всегда в виду того что обращение к трансформу идет через нейтив код ( тоесть идет обращение из managed C# в C++ ) - это всегда издержка.
Это справедливо только если мягко говоря у тебя очень много обращений к трансформу. Очень много это тысячи обращений в кадр : )
Я например делаю класс Monocached : Monobehavior - и там пишу selfTransform. Все мои классы уже наследуются от Monocached. Ну это если следовать по ООП )
PS - гораздо страшнее Time.DeltaTime XDD
Код
public void Tick() { delta = Time.DeltaTime; for (int i = 0; i < groupMove.length; i++) { var dMove = groupMove.component[i]; var body = dMove.transform; var v = body.position; v.x += dMove.nextStep.x; v.y += dMove.nextStep.y; v.z += dMove.nextStep.z; body.position = v; body.rotation = dMove.nextRotation; } }
обычно как то так выношу дельту ) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Четверг, 11 Октября 2018, 18:59
1.как оказалось пошаговые стратегии на тему второй мировой войны очень не популярны)
Популярность тут не при чем. Как и сложность. Просто это уже 1000 и 1 раз было. Вот если бы ты сделал пошаговый тактический симулятор партизан на тему второй мировой войны аля BattleBrothers/АгонияВласти - разговор бы пошел совсем другой. ( Утрирую ) В игр про вторую мировую просто так я уже наигрался. Но мне нигде еще не давали попробовать себя в роли лидера партизан, чтоб я грабил КОРОВАны нациков, делал микроменеджмент небольшого отряда "живых" бойцов со своими потребностями, проблемами, да там много чего можно сделать на эту тему ( Silent Storm не в счет, давно это было )
Рынок перенасыщен однотипными играми, дело не в механике игры, а именно в переживаемом опыте. Раньше игр не было поэтому вообще любая добротная игра имела шанс стать культовой, востребованной и тп. Сейчас же больше имеет смысл фокусироваться на нишах. Аудитория у пошаговых игр более чем достаточная. Люди выросшие на цивилизациях, героях меча и магии и прочих подобных игр никуда не делись. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Да все у тебя нормально с компом. C кодом скорее все в пределах разумного. Раз ты сказал что плавно все когда двигал через трансформ, могу предположить что у тебя есть камера которая двигается тоже когда куда-то бежит герой. Тогда у тебя рассинхрон между камерой и героем.
У меня тоже самое бывало - это все решаемо.
1) Делай рассчет движения в Update 2) Героя двигай в FixedUpdate
Именно двигай.
Код
// кусок из "Update" - считаю следующий шаг. Я это даже не каждый кадр делаю. if (UnityEngine.Time.frameCount % 2 != 0) return; for (int i = 0; i < groupMovement.length; i++) { var dataMove = groupMovement.component[i]; var spOverride = dataMove.speedOverride; var spActual = dataMove.speedActual;
Тебя иментересует метод MovePosition. Не переживай, он будет учитывать коллизии.
Дальше камера. Апдейт делай в LateUpdate. LateUpdate отыгрывается после всех остальных апдейтов и он идеален для камеры : все рассчеты уже завершены. Тоесть камера спокойно будет работать с уже гарантированно изменившимися значениями за кадр. Метод который тебя интересует - Vector3.SmoothDamp
Код
public class ProcessingCamera : ProcessingBase, ITickLate { public Camera cam; public Transform trCam; public Transform target; public Bounds bounds;
private Vector3 velocity;
private float smoothTime = .15f;
public ProcessingCamera() { cam = Camera.main; trCam = cam.transform; }
public void TickLate() { if (target == null) return; var boundsCam = cam.OrthographicBounds(); var position = target.position;
Ты можешь мне объяснить откуда ты вычитал про "параллельную обработку" столкновений? любые инструкции выполняются последовательно. Что в юнити что в ГМ Если у тебя сталкиваются два врага и на обоих есть триггер проверяющий что нужно добавить очки при столкновении друг с другом то они все логично делают.
Что можно сделать. 1) создаешь глобальный скрипт. Например ProcessingCollisions 2) добавляешь туда в список всех врагов 3) каждые пару кадров запускаешь вокруг каждого врага Physics2d.OverlapCircleNonAlloc какойнибудь 4) собираешь полученные коллайдеры от OverlapCircleNonAlloc - если там кто то есть то уничтожаешь себя и первого из списка попавшегося врага а всех остальбных игноришь. Очки начисляешь там же
если сложно то пиши) вечерком накатаю тебе скрипт)) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Вторник, 11 Сентября 2018, 18:41
Огромное обновление c новым примером и фишками. Добавлен полноценный ECS паттерн, можно делать как абстрактные сущности так и сущности с GO телом ( Actor ) Документация обновляется.
public class ProcessingShadows : ProcessingBase, ITick { [GroupExclude(Tag.StateInAir)] public Group<DataShadow> groupShadows; [GroupBy(Tag.StateInAir)] public Group<DataShadow, DataMove> groupShadowsInAir;
public ProcessingShadows() { groupShadows.OnAdded += OnAddedShadow; }
void OnAddedShadow(int index) { var data = groupShadows.component[index];
foreach (var node in data.nodes) { node.tr_shadow = node.sr_shadow.transform; node.sr_shadow.color = new Color(0, 0, 0, 0.5f); node.tr_shadow.localEulerAngles = new Vector3(node.angle, 0, 0); node.tr_shadow.localPosition = new Vector3(0, node.posY, 0.2f); node.tr_shadow.localScale = new Vector3(1.1f, -1, 1); } }
public void Tick() { for (int i = 0; i < groupShadows.length; i++) { var data = groupShadows.component[i]; foreach (var node in data.nodes) { node.sr_shadow.sprite = node.sr_view.sprite; } }
for (int i = 0; i < groupShadowsInAir.length; i++) { var data = groupShadowsInAir.component[i]; var dataMove = groupShadowsInAir.component2[i];
var y = groupShadowsInAir.GetActor(i).selfTransform.position.y; var depth = dataMove.jumpDepth - 0.3f;
foreach (var node in data.nodes) { node.sr_shadow.sprite = node.sr_view.sprite;
var posX = node.tr_shadow.position.x; node.tr_shadow.position = new Vector3(posX, depth, 0.2f); var magic = Math.Abs(0.7f - y - depth); var scale = new Vector3(0.5f, -0.5f, 0.5f); scale.x *= magic; scale.y *= magic; node.tr_shadow.localScale = scale; } } } }
Сейчас 2D игры могут быть мощнее 3D, посему нужно брать актуальный для всего.
делают школьники навешивая over 9000 ригидбоди и коллайдеров на 1 одного моба так что да - рукожопость будет любой комп убивать. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Среда, 05 Сентября 2018, 18:51
ты комп в раза два мощнее соберешь за 70 тысяч чем купишь ноутбук который интенсивно отработает в лучшем случае год. Учитывая что для 2д тебе особо не потребуется видяха сможешь еще сэкономить и лучше прокачать оперативку/ссд и купить два монитора) а еще лучше три. Я серьезно, лишних мониторов не бывает XDD ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Это не велосипед) нормальная внутреигровая логика - можешь сделать глоабльный статик скрипт со списками интересующих тебя объектов и внутри этих объектов использую методы OnEnable / OnDisable подписываться на эти списки/отписываться ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
поэтому средний процент увеличился с 20-25 до 50-55% дохода для разработчика.
Что ты предлагаешь беря такой конский процент?) сегодня издатели обычно работают по схеме 70/30 - 80/20 в пользу разраба. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю