In the last article, I described what kind of movement I want to be in the game. Iterating on that, I came up with some of the character stats that are related to this. These probably aren’t going to be visible, but communicated through visual cues (can jump/cannot jump, that sort of thing). I’m gonna be referring to actors in the game, player controlled and enemies both as “models” for lack of a better term.

Character height: There is a “base” height for every character, and this is modified if the character is crouching, or going prone. Probably should be the same for all mercenaries. Maybe some armors/equipment can modify it, and alter the hitbox?

Horizontal/vertical jump distance: How much of a horizontal gap can a model clear. Vertical jump distance is meaningless in itself, it comes into play when a target ledge for jumping is of a different height. Jumping downwards should add some bonus as well.

Vault/Climb height: The maximum height of an obstacle that can be climbed, or vaulted over. Should be relative of character height, and can go over 1, meaning you can do a “muscle up” if you want.

Climb angle: This one is tricky. Basically it means “how steep of an incline you can walk and stand on”. But not all surfaces are created equal (some could be slippery, or sticky). It is not really a factor of skill, but equipment.

I’m not sure how much of this should be communicated to the player, but we are not there yet. For now, these should affect movement. Character attributes will come later – I plan to flesh out the movement/environment system first and derive the attributes from that.

As I wrote this, and prototyped, a few questions popped up.

• How do I handle falling? Can I fall voluntarily?
• Vertical jump distance is one thing, but what if I get a running start? Should there be a sprint jumping mechanism?
• And most importantly, how do I signal all of this on the UI?

With game development, there is the fact that a lot of people do it, or attempting to do it, so if your problem is somewhat common, usually there is a solution already or at least someone tried and failed.

Turns out, Unity NavMesh had pretty much what I wanted, down to the actual properties I listed. It can even handle jumps! After some tinkering, I got it mostly working.

I added some selection logic as well – I intend this to be a turn-based game, but I’m not a 100% sure if it will be a “your team/their team” thing, or alternating activation.

While I was there, I played around with highlight and selection logic as well. This is when Is started to get into a bit of an analysis paralysis about architecting. I tried out different schemes, and really needed to get a grasp on how Unity works. Sometimes it is frustrating doing it this way, but in my experience, learning by doing is the best way.

I also decided to build up the project properly. So far, I have been working on a test project, but I started a new one, with version control and all that jazz. I’ll be continuing to have a sandbox project of course, but the actual game source I will try to keep tidy.

And with that, I started brainstorming on names, and just what it is about. I wanted to call it Void Marauders first, but turns out there is already a game named that. It is also similar in style. Oh well, great minds think alike I guess? I wanted a name that describes a criminal crew assaulting trading spaceships.

For now I settled on the name Skywaymen. It might be a bit goofy, but I like to sound of it, and it is not taken yet. There is a silent film named The Skywayman from 1920, but I believe 100 years is enough for people to not confuse the two.

Lore

I started to brainstorm on some background lore as well. I want this to be a game about boarding spaceships, and decidedly not spaceship combat. Let’s say that in this universe, merchant ships are forbidden to carry weapons on them (meaning actual ship-scale guns, not small arms), and mercenaries/pirates are instead just board ships. There are of course military vessels who will hunt them down, but they might not get there in time. Of course, this being a sci-fi game, there should be faster than light travel, so why don’t the military just warp there, or the merchant jump away?

Let’s use another sci-fi trope: For whatever reason, small ships are not able to perform FTL jumps by themselves. Jump gates/ferries are used, but they can only work outside gravity wells, and even weak fields interfere with their function, so they are positioned right outside planetary systems. And/or they are always a set distance away so they won’t just warp a hostile military force in.

Travel within a planetary system is done with sublight engines, but of course there is magic future technology that makes it feasible, even though it takes days, or weeks. So the mercenaries trying to rob trading ships have this time window to make their move.

Now, this is just something I came up with in a few minutes, and of course it should be fleshed out much more – but as a guiding framework for the lore, it will suffice for now.

Anyway, back to the game dev part.

Further complicating movement

The Unity Navmesh component is pretty good, but at a first glance, it seems to assume that all the agents (player characters, currently) are the same size, and cylindrical to boot. The way it works is you “bake” a navmesh, and your agents will use that map for pathfinding.

I intend to have characters and enemies with different sizes, and in some cases, the agent being cylindrical doesn’t make a good fit. Two examples being shimmying between narrow surfaces, and crawling through a tube – both of these are something I want to implement.

A cop-out would be to only allow these as actions – you could do it as a discrete action, but couldn’t stay inside there – I would just play an animation and place the character at the other side. I want to improve upon existing movement systems, so let’s try to avoid that.

NavMesh is just one tool, and I don’t need to use it for everything. I decided to implement it where I can (it is good practice in any case), then handle the edge cases. Going in blind was an exercise in frustration. My goal was to have an agent navigate around an obstacle in a “standing up” position, then press the crouch button, change the agent size, and now the new navigation would take it under the obstacle.

After two days I figured out that you can’t edit NavMesh properties, and the agent parameters – such as height – cannot be changed. What did work was to precalculate multiple navmeshes, and switch between them, while visually changing the agent height as well.

Anyway, that is enough for a devlog as of now – I have quite a lot to learn about Unity, and game development in general, and I intend to give at least semi-frequent updates. Thanks for reading!