Hey folks,
It's been another busy week on Jack Move. Some more optimisation stuff and some cool new bits to show. It's a big post! :D
On the optimisation side, I knocked up a script that builds meshes for items and then combines and saves them. Here's a bunch of code for that, you might have to edit a bunch of stuff to get it working and I've not had time to clean it up. Hopefully it's self evident what everything does though.
https://gist.github.com/empika/f1ec6735b1959738e79c30c6d88088aeAfter combining a ton of objects in my test scene I've managed to get the draw calls down from ~3000 to about 150 or 330 with ambient occlusion turned on, which is pretty awesome. I've had Jack Move running on my iphone 5s at a pretty solid 30fps :D
Gary has been doing a few days on and off over the past month, working on some dialog portraits. This past week Joe had some free time to finish those off with all the expressions needed. They've turned out suuuuuper good <3 <3 <3
It's been really fun getting them in game and deciding which portrait to use for each line of dialog. I have a certain tone of voice in my head when I write stuff, but given a limited amount of emotes to accent the lines with has made me change the way I thought certain lines read. I'll be expanding the amount of portraits in the future, so can hopefully cover all eventualities
Here's an in game gif:
Lastly I've been working on setting stuff up ready for Joe to do some work on the battle backgrounds. Originally I was just going to remove the top section of the grid and replace it with a static image
A few months ago Joe had suggested doing something a little fancier involving adding some items around to give the battles a bit more depth. He brought this up again earlier this week and sent over a quick mockup. So I spent a bunch of time working out how to translate that mockup in to an actual workable system
Uh huh. That UI is awesome, but no time for that right now! Hopefully in the future
The main issue with something like this is that I have to deal with varying screen widths, from tiny 320x240 (smallest) to super wide 688x310 (biggest). The obvious answer is to anchor things in the UI to certain percentages across the screen. This is something I already do with the player and enemy positions, so that was what I tried for my first attempt.
It looks pretty good, but it was quite difficult to easily see how this would look at different resolutions, bar iterations of playing the game and adjusting things little by little. So I rolled up my sleeves and got to work on some tools that would allow me to do that.
Battle scenes are composed from a number of layers:
* The backdrop, which is a worldspace canvas. This allows me to place things on screen using RectTransforms, rather than just normal transforms, and still shakes everything with any screenshake.
* The world. Noa, our player character and the enemies.
* UI, a screenspace canvas.
(There's actually a bunch of other stuff for rendering the background grid floating in the scene too. This is just a ton of animated line renderers and some cameras that render to render textures.)
(Ignore the "no cameras rendering", I just turned off the main fullscreen rendering UI (which takes the 1x size output and displays it at the full display resolution) so it didn't get in the way).
The main problem with testing within this set up is that the worldspace canvas just has an arbitrary size. In order for it to layout correctly we need to set the same size as the UI screenspace canvas that gets automatically updated when you change the size of the game window. Surprisingly the way to do this is not call Screen.width/height from your editor script (because that obviously returns the width/height of your inspector window!!), but to call Camera.pixelWidth and Camera.pixelHeight on our main camera. Once this was figured out, setting the canvas size was pretty trivial and I could set the anchors of background elements and preview them pretty easily.
The next "problem" I hit was that I wanted to be able to see the player and enemies in position also, this lead me down a long and wacky path of being able to do this in game too. Here the issue was that whilst it was pretty easy to be able to reset positions of the actors when they are stationary, it's not so easy when they are halfway through an attack or are in the process of moving in or out of an action. The answer was to put everyone inside an anchoring container. The anchor container would be the one that would get repositioned, and the actor would rest at a local position of 0,0,0. As I never anticipated this kind of thing, a lot of my movement code uses world position to work out where to move to. This now needed to be translated up and down from local to world and back to local positions. Not too bad once I figured where the issue lie.
The only bug I have left is that I use DoTween for movement, it's a fantastic library but once you set and play a sequence you cant change it's values, which results in actors ending up in weird places if the resolution is changed mid move. This isn't so bad when moving towards the target as they'll end up somewhere in the right direction, but moving back means they'll be in completely the wrong place when they come to rest. My quick fix here was just to check if the local position is 0,0,0 when they're done, and if not then just force them to that location. In reality I don't think you'd really notice too much.
Here you can see the elements as they would look at 320x240
...and at 688x310
Notice how they are anchored to a certain percentage of the screen width. So the wider the screen, the more of the element gets shown
The last piece of the puzzle was just hooking up some data objects to hold references to the images for a "backdrop set", which then gets set on a random encounter area and then passed into the battle scene to be set up :D
I can't wait to properly set the proportions of all the elements and get some proper art work in there, as it give the battles so much more depth.
I hope that was interesting and that I'm not teaching people how to suck eggs!
Till next week
Community
