Sergei Kushnirenko @dalerank
Люблю (ш)кодить, алгоритмы и старые авто.
Information
- Rating
- 4-th
- Location
- Москва и Московская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
Software Developer, Game Developer
Senior
From 300,000 ₽
Git
C++
Multiple thread
Applied math
OOP
да сделать такое действительно просто ( в качестве эксперимента добавлю в билд ), город при этом будет смотреться менее однообразно.
___________*______*____.___*____.
________________..__*____o
______________o___*__.____*
________________________
_______________(________)
_______________|____o___|
_______________|_o____o_|
_______________|___o____|
_______________|_o____o_|
_______________|_o__o___|
_______________|______o_|
_______________(_o______)
________________\___o__/
_________________\____/
__________________\__/
___________________||
___________________||
___________________||
___________________||
___________________||
___________________||___
_______________/___||___\
_______________\________/
1. для объекта доступна только одна текстура
2. здания не имеют параметра вход
Использование похожих текстур подходит не только для домов, а для большинства объектов в игре, проблема в их создании )))
Reverse — повторение логики игры на основе наблюдений, сажусь я играть в цезаря, строю фермы и вижу что тайлы пшеницы меняются в соответсвие с прогрессом производства и вношу это в ремейк.
В проекте в полной мере присутствуют оба направления, но конкретно в этих статьях 90% все таки back-инжиниринга, я сейчас практически не касаюсь логики, до которой не удалось добраться через IDA.
1. Большая нагрузка приходилась на алгоритм поиска пути, сначала использовал Беллмана, но он зацикливался на перекрестах и петлях, позже был введен A* для расчета перемещения по всей карте, Беллман остался для расчета путей обслуживающего персонала, так как из него можно вытащить информацию о всех проверенных машрутах. Предполагается, что позже он будет вынесен в отдельный поток — задержку в несколько мс на поиске игрок не заметит, но общая картинка будет более плавной.
2. Потом проседания начались при поиске подвижных объектов вокруг, они все были свалены в одном массиве и его перебор обходился дорого, это я обошел введением доп. карты, в которую перед каждым кадром записываются подвижные объекты по тайлам. Это требует времени при старте кадре, но практически убирает фризы при поиске.
3. Основная же нагрузка приходилась на загрузку и поиск текстур, каждый тик что-нибудь да меняется, это победили предварительной загрузкой и введением класса Picture, который реализует своеобразный shared surface, храня указатель на конкретный surface. Еще большего увеличения производительности удастся добиться введением текстурных атласов и сведением текстур анимации в одну.
Пока решено сделать упор на восстановление функционала. Вот, надеюсь я ответил на Ваш вопрос, если есть еще задавайте, постараюсь ответить.