This update felt like I have done a whole load of stuff but really, I've learnt a load of stuff. I put a new menu, which I won't dwell on. It's just a nice new picture. None of it has been brain-taxing like sodding building placement was. Here's the video:
Sound
I've started putting sound into the game. I watched a lot of YT on the matter (particularly the excellent Brackeys. He's outlined a neat way to control all the sound for the game in one place. I like this collectivist style and it fits well with the agent-like design style that Unity uses. I downloaded some free "Wind noise", wrapped a class around it and then calculated a simple function that says "when you go fast, increase volume and pitch". It works well so far. The general advice is to do most of the sound "last" and then mix it together to make sure that the soundscape as a whole makes sense and that one sound isn't drowning out everything else.
Building Game Mechanics
I've introduced a new concept into the game: building abilities. Before you can move you need a boiler (chimney) and a bridge. The more boilers you have, the faster you go. It's overly simplistic right now and there isn't need for houses but I have some of the structure in that will allow me to build on it later.
Buildings also have hit points and take damage. If they run out of hit points, they disappear. I had a humorous bug where shooting would cause all the cannons to disappear. The very act of shooting meant that destroyed themselves! Ooops. It's quite fun if you lose your bridge in a battle then you can't change your speed/heading. You have to get into the build menu and plonk one down fast!
I'm really glad I removed the building grid although I do want a "snap to" feature.
Cinematic Camera
Making videos for the game is important and the controller, while cool, does get in the way of nice screenies. I extended the animator that swivels the controller around for building and give it an animation state where it slides out of view. I used F1, like Minecraft. I need to tweak the values a bit because it's not as smooth as I hoped for.
Progress and Up Next
Working an hour in the morning before anyone else is up works a treat. My brain isn't quite as fired up as it is when I get to work but I do manage progress. I've also been fiddling with Icar in that time slot for variety.
My commits each week have been pretty consistent. Not bad seeing that I was on holiday for 3 days of last week.
What's next? To be honest, I'm not sure. I have a backlog I'm working through (full backlog here):
But there is a tension between sorting out the look of the game (I know it can be better) and getting it to a point where it is complete - if a bit ugly. You can see that Player Death is a little way down the list. To make it a full game, I need that (quite tricky as I need a new menu) and the creative/survival mode (not difficult). The rest of it is graphical.
Here's a question for you: should I move up player death or do graphics first?
One other thing...
The video music was created algorithmically by JukeDeck. Few clicks and you have rather bland but nice filler music.
https://www.jukedeck.com/share/47ff7e6f8f31f497cb1bf518cd0fc3a7e8635f808...
Comments
My vote would be for functionality over looks.
Make it look pretty once you are fully committed to what the game is and how it will work.
The last thing you want to do is add loads to work to something that is dependant on a certain type of gameplay only to discover the gameplay isn't fun.
Thanks, Big R. I think you've got a very valid point. It's not much fun to play just yet, so that's what I have to work on.
I'm all about functionality over looks.
On that topic, I've moved up "Make Enemy More Interesting to Fight". That needs a bunch of tuning and some AI too.
I've now got player death in as well as creative/survival modes. Now I'm looking at making the enemy more interesting to fight. At the moment, he just drives inexorably toward you, shooting without stopping. There are other tactics easy to implement: running away, and looping around the player. However, it draws and interesting point about the enemy itself...
The enemy is currently a single model that just magically spawns cannonballs. I am tempted to make the enemy out of standard cloudship parts, so it looks like you're fighting someone like you (but change the colours and stuff). I was thinking about procedurally generated but that's a lot of effort for not a lot of fun, so I'll create an array of random enemies and then save them into the project. I can have the enemy use the same physics calculations as the main cloudship.
I am thinking also of making only those cannons that are facing the enemy to actually fire, that will make combats more interesting.
I've removed the "Make Enemy More Interesting to Fight" item in favour of more granular, and less nebulous tasks.
This week has been a good bug fix week so far - mostly found in testing. I've fixed some issues about placing buildings down when the Cloudship isn't completely level (like after you get thumped by the enemy). I also set it that a cannon only fires when there is an enemy is within 15 degrees of its arc. There are fewer balls in the air now and it looks much more like a battle rather than just random models.
This morning I've been playing with how the enemy works. Before adding more AI states (which is pretty easy), I wanted to make sure that the flying physics were similar to the main Cloudship. The enemy always felt slow, sluggish and easy to outrun. I fixed that and it became really quite quick. It felt OP. No amount of sodding around fixed it.
Then I realised that what it needed was to be built under the same rules as the player's Cloudship. The physics model is the same in both but the player Cloudship's parameters for thrust, torque, etc are specified by the buildings you put on it.
So, the enemy definitely needs to be built out of the same stuff as the player Cloudship. This is going to require a bit of refactoring, code reuse and separation. Nothing too bad. I've used this opportunity to build another Cloudship base, so that the enemy is smaller than the player. More for fun than anything else. Once I have the base in, I'll attach buildings to it. This is all stuff I know now. I can visualise how the code needs to change to make the "abilities of a flying thing as derived from its buildings" more generic rather than just being about the player.
Once the enemy is manoeuvring like the player - and shooting like it, then I can work on some tactics.
Added treat (because I like you), here's a picture of the new Cloudship base.
This morning, I just about got the enemy working with the standard building assets and it's become a little bit lethal! I think I'm going to put a new release out with this change - because it is kind of fun, before I start working on the next glaring thing...
Mass
The Unity physics engine is great. Love it. There's a thing that I've been skirting around for some while now: mass. Everything currently has a mass of 1. And that's been fine.The Cloudships have bounced off each other nicely and have skittered around over the sand how I want. However, now that the enemy and the player both use the same buildings, there is a problem: I need to start considering mass or things look a bit odd.
This will be as easy as setting the mass on the RigidBody component to the correct value. The question I'm not quite sure on is:
Is mass purely the mass of the Cloudship base (as pictured above) or does it include the buildings?
From a physics point of view, it would make sense to include the buildings but from a fun point of view, I'm not sure it adds much. There is some fun to be had right now squeezing as many sodding buildings on top to make it a gunship or drag racer and I don't want considerations of weight to be brought into that. You're limited to the size of the base anyway, so it makes sense for bigger bases to have more mass because they can fit more.
One instance where including buildings in the mass calculation is when you're taking damage. If half of your buildings have been destroyed but you still have your boilers, then you should be able to run away more easily. This doesn't count for destroying boilers, because they are what give you thrust in the first place. As long as their cost-benefit is in the right direction then that should be fine.
Oh, and one note, there is no performance hit for this. Mass would be updated when buildings are added and removed, I actually turn off physics for the buildings for simplicity.
Can you see any other instances where including the building mass is important? Thoughts welcome!
My initial (off the top of my head) suggestion would be to maybe add mass only to offensive and defensive buildings and possibly engines.
The more guns you run with, the slower you are.
Maybe give larger engines more power and mass, so they don't only make you go faster, but make ramming a more viable tactic.
I am sure there is some way you could combine boilers, funnels and exhausts to let the player mix things up a bit.
As I say, just off the top of my head, thy are not thought through, just ideas to mull over.
As an example, boilers could have a potential max power, but the amount they deliver is based on your throttle, the size of the boiler determine the max power that can eventually be applied, funnels could determine how fast the boiler can change power level, and the exhausts determine the rate at which that power can be converted to thrust.
Possibly you could also make it so other things use steam power to run, weapons, other types of rooms etc.
Brilliant ideas, thanks Big R. Definitely worth talking about the economy soon; for mass alone you're right that being heavier means better ramming ability. Good call.
Mass implemented! Took about an hour. I've currently got all the buildings (apart from the infrastructure) set to 0 mass because I wanted to tune the existing system. I also rescaled again. The mass of the medium Cloudship is now 1000, so all the forces needed changing by a factor of 3.
There was a side-effect of including mass in the game: the effect of the wind is different to each. This makes for some interesting play: when I shoot the boilers off the enemy, it will be adrift; pushed only by the wind. As it is a smaller infrastructure, it has less mass and so the force applied by the wind has a greater effect. I set my speed to 0 and drifted along with him... but... he started to gently move away. I hadn't planned that but it did make sense.
There is another parameter I'm tempted to generate by Cloudship: drag. This is how much the environment slows you down. Currently, it's fixed. If I change it dependent on the Cloudship then I'd need to make some of the maths more complex; which is OK. I might give it a go later on.
Release, as always, available for download.
Go home, Jeff, you're drunk
Improving the enemy AI... well, I say improving.
What has happened there is quite clearly that you have created the worlds first sentient AI, and understanding the state if the world instantly drove it insane ... or it is just trolling you.
Oh God, I hope you're wrong, Big R because I've just fixed that "bug". If it was sentient (even a troll), I would hope that I would recognise it in time. In this case (because I cocked it up a few other times after this vid), what I think I did was two things wrong: I was applying the torque along the X and Z axis and I was applying the torque at 90deg to the desired heading.
Also, you might notice that the video above is an mp4 hosted on imgur, rather than a full YouTube video. I like that!
Project managing myself
I've started using Issues for tracking my changes in Github. The issue tracker is really good, I've used it elsewhere but I felt before it was a bit heavy for using just as a "to do" list. However, now I want to know why I changed a piece of code and although git commit messages can give me a little of that, attaching code to an issue gives me more background. I can now organise releases (Milestones) and GitHub will create release notes too (no example just yet but it's coming). The code base is growing and so this is going to be come more important if I am going to keep motivated.
In the project window, the issues show up with their state and changing the issue will cause it to move column (I had to set that up but it was simple to do). I still have "notes" in there before converting to issues. I'm going to use it as "when I am sure I need a feature, I turn a note into an issue".
I can use colours to show when something isn't working quite right, such as yellow for "waiting on release of Unity 2018.2", blue for feature, red for bug.
The new state machine states of "loop" and "run away" have made the game into something very different indeed. You have to plan your approach and attack and if you decide to pursue, then the rear cannon the enemy can whittle you down. The advantage the player has over the enemy is making decisions based on the prevailing wind streams. As the enemy is just charting a course "roughly away from player", then you can use the wind direction to gain on the enemy. Unfortunately, it's difficult to see the wind patterns right now but I have a plan for that when I come to change the environment.