So What's New?
Visible changes in the last couple of weeks are...
Crushers!
No trad sci-fi would be complete without crushers trying to stamp on you at some point. There is no plausible reason I can construct for their existence, so I shan't. CRUSH!
You can shoot switches to turn them off, or even use gravity bubbles to hold them open...
Checkpoints and Respawn
I've been putting this one off, but with the demo looming I can't ignore it any longer.
The last checkpoint the player reaches is serialised with their game state so that when the level is (re)loaded the ship is simply moved to the location of the named checkpoint.
I was expecting this to be trickier than it turned out to be. In fact all I had to do was decide which objects should survive a level reload, and which should be destroyed. Unity takes care of the rest.
The UI
The original UI was just made of two things. A round button and a radial menu layout (of round buttons).
This was all fine until my needs changed. The worst thing about radial menus is when some of it is off-screen. What do you do? Do you put the menu not where the user clicked so it can all be seen? Do you try and cram it in the visible space?
I tried all of those and more. They all sucked.
I'd had the opportunity to build a more flexible UI system back when I wrote the repair screen. Sadly, I didn't take the opportunity and instead built something task specific. Now I had two bits of UI that shared no code :(
Eventually it was time for the fabrication and inventory screens. Uh-oh! I don't want a third different way of doing the UI! Time to smash it all apart and built something engineered to handle all the jobs.
Turns out that the core classes were fine, I just needed easier ways to make variants. I added different layouts for menus (grid and hex) in addition to radial (still useful) to use in the different screens and situations.
Finally the flexibility of UI I needed. Phew.
Grav weapons time out
Previously gravity wells and bubbles stayed around until they went off-screen. Now they last a few seconds then flicker out. All the balancing of how big, strong, and long lived they are is yet to be done.
Camera Shake
The sharp eyed among you may have noticed that all camera shake originated from the bottom left of the screen. At some point 2D Toolkit updated to allow the cameras zero point to be central. Switching this on obviously broke all the places where I'd compensated for zero zero being bottom left. An hour later it's all looking good again, and best of all the camera now shakes in the middle.
Fixing The Intro
Almost everything broke when I swapped 2D physics engines a few weeks ago after Unity introduced a proper 2D one. In theory the 2D engine would be faster than clamping the 3D one. This meant re-working every physical asset in the game. I even had to re-scale the whole game down by 100 because of a fixed speed limit per frame the 2D engine has - that was painful to do, and even more painful to work out what the problem was in the first place.
The only thing I didn't fix at the time was the Intro. I finally got tired of that task lurking in the background. Of course, while I was there I couldn't help but add a bit more to it ;)
It's still incomplete compared to the storyboards I have for it, but it's getting there. I had no idea the intro would eat so much time in general, but that first introduction is crucial.
So What's New Under The Hood?
Some things just can't be shown by picture or video.
Object pooling
This is something I wish I had done a bit earlier, but my creative side kept insisting I added more features rather than spend time re-engineering.
Up until quite recently I was instantiating prefabs on demand. For UI buttons, bullets, ships, missiles, everything. For a long time this didn't matter, but there came a point when making videos that I started to notice it skipping. I'd been blind to it until recently, it just hadn't been important enough.
Instantiating prefabs is slow. One technique to avoid slow creation times is to keep a pool of spare ones kicking around ready to be used. I researched different pooling styles in Unity and, like every creative engineer, decided to do it my own way :)
So now, when you need a new bullet, or UI button, or baddie, instead of having to instantiate a brand new one (which can be slow) you take a spare from the pool. If the pool ever becomes empty it creates some more spares.
There's some balance to get your pool levels right, but on the whole you should see far less performance dips. And I did. Hooray!
Audio controller
For sounds I was just using Audio Sources directly on objects, or one shot sounds. Nice and simple, super quick to get going with. Except when you need more control, and now I wanted sounds to speed up and slow down with time. When you need that type of control you need all the sounds to go through your own audio managing code, one central point in code where you can control everything. Now it does.
What's Next?
All my work is focussed on getting the demo finished. To that end upcoming tasks will be...
- Checkpoints: The planned flow of how checkpoints are used in the game is designed but not yet implemented.
- (Re)Loading: Serialisation of inventory/fabrication state, so that it can be reset on respawn.
- Baddies: More baddie and wave types to show off different weapons and strategies.
- Music: Boss music. Noyj has supplied many boss tunes. I need to pick one and make it work, then pop back to the normal music.
- Weapons: Backward shot (as it should be quick and easy to implement).
this is just a really freaking cool idea. well executed.
Thank you!