Question: shouldn’t you optimize and then playtest? just curious :3
Optimisation refers to reducing the processing power needed to render the game close to the desired quality. They all got beefy machines so the game always runs really smooth while doesn’t on low-end hardware. Eventhough performance should always be considered in every step of a map’s creation, performance issues still need to be analysed and solved so that it runs smooth on most machines.
Playtesting can always be done and helps finding gameplay issues and bugs. It doesn’t depend on how smooth the game runs on low-end hardware and hence performance optimisations are irrelevant for playtesting.
Ah, alright. I thought playtesting was to find if one side had an advantage over the other and balance it out or something like that. But you answered my question through a very good explanation. 
That’s what I’d consider a gameplay issue and therefore it is part of playtesting. So you were right if you thought that.
Woah, could this come out with the next update 
Nope:
You should always check Trello to see and vote on what’s up next
https://trello.com/b/6BwRMiPw/tower-unite-roadmap
1 Like
I do check it…
Nothing on the Trello is finalized. Things can be added and removed at any moment, as it’s all estimates.
3 Likes
You guys have a very unique art style. Looks great.
Well this just sorta vanished out of history 
2 Likes
tru
Just casually waiting alongside his bro Prism
The biggest thing is that in both of these maps (as well as a portion of the Ballrace maps) there are a lot of individual actors (or objects, however you wish to call them), which all require drawcalls. This means that if there is a big section that is made of lots of tiny parts, the engine will try and calculate if all those objects need to be rendered. Sounds good, right? Well, if it’s there are a lot of objects in your view, it all adds up to the render time. In the current state, all of those castles in this map are made very, very, very modularly: a model for the base wall, another for the top of the wall, another for the wall corner, another for the top of the wall corner… The result: too many drawcalls to call acceptable.
And all that for some flexible level design in the editor.
But then, Unreal Engine 4.12 came to the rescue with their actor merging feature, which allows you to merge multiple actors into one, reducing the drawcall count of all those individual wall actors to 1. The problem is: we don’t work with 4.12 yet, because converting the entire project to a new version always breaks something, if not a lot. So we postponed the conversion to at least after the Casino comes out, so we don’t break the casino and have to delay it more.
TL;DR: lots of individual models adding up to render time, gotta wait for UE4.12.
Other than that, it’s pretty much done.
6 Likes
You working on any more maps in the mean time ?
I do have an early draft for a Ballrace map, but that one is on hold as I am working on some other stuff for the upcoming Casino update.
1 Like
I think that you should add a logic that synchronises only those actors in Ballrace and Minigolf stages / holes that are currently played. You could still play some animations that rotate actors in these levels but only synchronise those actors that are necessary for the current hole /stage you are playing.
1 Like
I actually did something like that in Prism. The code looks like the biggest fucking mess, and it is. But it works.
… consider redoing it and integrating it into a proper blueprint class
Wow, telling the devs how to do their job totally isn’t rude at all! 
1 Like
He’s not telling them how to do their job. He just made a few optimization suggestions. Thats not rude at all.
just asking, is this still happening?