I got to the point where I was writing a lot of code in my experimental builder project. I wondered at what point I should move all of this stuff into the main project again, so I asked reddit for best practice and got some reasonable replies. I decided to move the code immediately into the main project and create a new scene.
Making a new scene inside the main project for building-only didn't work very well in this case because there were loads of things that I needed to deal with in the main game. For example, I wanted the menu controls to be the same as the movement controls, so I needed a way to switch them off. If you set up an "experiment" scene then you need to carry over all that functionality. You end up rebuilding the main scene! If I need some sort of deep "undo" then I have source control to help me with that.
Some refactoring was required too. I moved the flying physics out of the enemy and player and into its own class.
Build menu
The next piece to solve was the "building menu". I've always wanted the barrel to turn to show new widgets and gizmos and for the menus to be in the 3D world rather than a 2D overlay (which would be easier). The end-goal is to have buildings grouped into types so you select a type and then choose a building for its type. I won't have lots to start with, so the menu needs only to be a single thing.
I really enjoyed getting back into Modeler and creating the updated barrel controller. I decided to let the player build while on the move. You can't change the heading or thrust of the Cloudship in build mode but you can see around and switch by pressing B. You can see me testing that below.
New models!
The current Cloudship was a placeholder, hurriedly put together. For the builder to work, I need models that can be used with the builder grid. The player will start with a smaller Cloudship base and then as they grow, can choose to jump to a different base with different properties - such as maximum speed, torque, health and damage when ramming etc. I decided to just have one somewhere in the middle of the size range to test building. I'll add base updating in the future.
I've added in the steam vents underneath (like the original game had) and they will have cool particle emitters that will puff along at the correct speed. I want to add more stuff to it later but it will do for now. I don't like leaving something not-finished but this is an important way of working: doing just enough and then iterate over and over. I'll need lots of these bases in the end.
The sharp eyed will also notice that the dark patches of the Cloudship have gone. This is an old rendering trick I've taken from Lightwave. Rather than have light bounce off the ground (expensive), create a light of the same colour and shine it up. Works rather well.
Next up
Putting buildings of different sizes into the menu and then getting them onto the model. I'll need a bunch of models for that. Then I'll add economy and start getting the Cloudship's movement parameters to be based on the buildings that have been chosen.
Comments
Looking good
Is that artifact on the ground with the odd grid lines lighting or non seamless texture or some sort of polygon mesh issue?
Dunno if you've seen this...a game that has been floating around for a while with some similar concepts (though seems to be leaning more towards a Sea-of-Thieves-the-air vibe, with ground-based exploration and less ship-to-ship combat shown such as Skull and Bones will be). It's back-ended by SpacialOS, which (to my ignorant mind) sounds like a MMO-service, but it links into Unity, which I think is what you're using.
I'm glad you asked! I know about this one...
Each of the sand tiles are boring flat meshes. When they are loaded into the scene, I use Perlin Noise to move each vertex up and down to create the bumps. Once I've moved them, I tell Unity to recalculate "the normals", which are vectors that are used to calculate light and dark (and physics, I think). Because of the way I've set it up, each flat mesh tile doesn't know about its neighbours. It thinks that it's the edge. So, when "the normals" are calculated for lighting, each tile doesn't know that the curve continues so calculates itself on its own tile.
I worked this out originally by switching off normal calculation, at which point there's no light/dark on the undulation but you can see that the vertices of the mesh line up perfectly.
The solution is to let Unity calculate most of the normals and then reuse their method to recalculate the normals for the edge vertices, feeding it vertices from its neighbours - or more realistically, re-running the noise function one vertex over.
Does that make sense? Not sure if any of those words will mean anything.
@Babyc
Thank you! that game looks ace. I'll be all over it when it hits early access. They do look similar, although Cloudship is aiming more for a "Town Management Sim where you Take Your Town With You". Having said that, the difference between that and an FPS in Unity is about an hour's work. I think Worlds Adrift might be a good candidate for a Sunday night game; it already has a load of content and looks like good fun.
Didn't know about SpatialOS, I'll take a look and yes, I'm using Unity! :-)
I wasted 15 minutes this morning trying to work out why I couldn't see a building that was inside the menu wheel. It was in exactly the right place and moving correctly round the wheel but I couldn't see it...
I was inside it.
Now the big question, when's the battle royal mode coming :P
Ah normal problems I've seen that with generated meshes in stuff I've done before I remember manually replacing the face normals for each triangle in the strip with ones pointing up as a poor solution for good looking lighting replacing that by ones based on calculating the different heights of the points worked better. With that I had complete control over the vertex and fragment shader programs and the VBO's in triangle strips and was using a heightmap rather than perlin so it was a different sort of thing I'm not sure if Unity allows that level of fine tuning.
Everything needs a Battle Royale mode.
Unity gives you both the detail and the abstraction, so you can use either or both. That's pretty much what I'm doing with the sand: I'm literally moving vertices and then using their Normal Mapping. When I come to fix the bug, I won't use their Normal Map function but I will use the Normal Calculation function (which is one step deeper) and feed it the right points. I quite like that: it means that I can do something that's just good enough and then when I get a better understanding or need more control, I can have it.
Build Me-and-You
The spinning build menu disc has six holes in it. I will have more than six buildings (and eventually more than six categories of things). So I needed to create an infinitely scrolling menu. I faffed quite a lot with this; eventually deleting a lot of my code and starting again from first principals (and lots of scribbling in notebooks). My solution had one tiny bug in it that made the whole thing just not work.
The algo is: work out what angle each hole was at (0,60,120, etc) and how far from the centre (point of rotation) and then spawn the objects in at a rotation * distance away, keeping track of which building is next.
The problem I had was that when I was rotating, the vector that represents the axis of rotation was backwards. So the buildings were being put in the wheel backwards. Confused the hell out of me. In future, I'm going to use Debug.DrawRay more often. You use the "throttle up/down" keys to navigate.
Exciting change coming to Unity in the next few weeks
Shaders are the code that generate the actual pixels on the screen. If you want stylisation or post-processing then you need to write a shader. They are built in C++ and can get quite complex. I've had a quick go but didn't find it much fun. I could learn it and get better but I don't really care that much about it!
What I wanted is a tool where I could build up shaders (textures/materials etc depending on your choice of 3D program) by plugging in pre-baked pieces like I can in the "node graph" in Lightwave. And so they have!
Here's the GDC talk on it.
It will mean immense amounts of buggering about in my future but lots and lots of fun too.
Next!
Putting buildings onto the actual model. I think I might need real buildings for this, tho because it'll look odd with spheres etc and that's not helpful. So a bit of modeling first.