Finishing Up Coms

I'm finally wrapping up coms work (for now). This ended up being quite a detour, and I'm not sure how much of it will actually be player-facing in the next release, but it was all work that needed to be done eventually, so time well spent, I think. That said, I am definitely ready to move on.

Coms Mast

We now have a stowable/deployable antenna mast which includes all the transmit & receive hardware for the 3 new coms modes:

• Radio (RF) - Medium bandwidth, omnidirectional. Some signal degradation over long distances (i.e. limited range).
• Laser (FSO) - High bandwidth, directional tightbeam. No appreciable signal degradation over Solis-scale applications when sufficiently powered. Required for secure coms & most local STC communication.
• Ansible (FTL) - Low bandwidth, directional, high energy use. Standard coms mode while in warp. Requires target lock handshake with other end before entering warp.

RF works normally while stowed but with a limited range (higher signal degradation). FSO also works while stowed, but the nose of your ship must be pointed directly at your target. FTL is unavailable when the mast is stowed. Mast stowage during high acceleration maneuvers is recommended because, yes, it can break.

When deployed, mast hardware can be tilted & rotated to acquire coms targets rather than having to point your nose. Once acquisition is locked, the mast can be set to automatically track the target as long as it remains in range.

Ship sensors use RF mode, which propagates at light speed. This is a problem for a ship with superluminal warp capabilities, especially during interplanetary travel. The ansible (I'm reading a lot of Le Guin lately) provides magic instant communication, but with a very limited bandwidth (single target & reduced significant figures, basically) so that you can maintain an accurate sensor lock while warping.

Coming Up Next

Close range physics & collisions are the next big item on the to-do list. This is an area with LOTS of room for improvement, but will also involve a lot of research & testing on my part, so I expect it to get off to a slow start.

Next month's devlog will likely be more of a year-in-review kind of thing, unless I end up making crazy progress on the close range stuff.

The Train Remains on the Tracks

Well, as expected, very little development progress this month. Just had other shit going on. I did manage to do a little work here & there, so I haven't lost track of what I was doing, and life-things are calming back down to normalish. I handled all my bizniss without burning out or losing BRS motivation, so that's better than most years. This is usually the sharp bend that derails me, then the winter dark sets in & the beers start tasting better than usual, and then FUCK it's spring.

I mean, that still might happen, but I feel pretty good & am the good kind of anxious to get back to work properly, hopefully next week. I'm still working on this coms system sidequest, which I should be done with & ready to talk more about next month. Until then!

System Scale & Building Out Nav/Com

Kind of a slow month due to my actual job & spending most of my free time performatively reading Gravity's Rainbow. Still, decent progress!

System Scale

I have once again, and hopefully for the last time, reimplemented the system-scale architecture. More detail than you probably want incoming:

Basically, it's not possible to accurately simulate small-scale actions (e.g. cockpit button presses, or even the ship moving in space from frame to frame) in a world that spans billions of kilometers because the numbers get too big and you run out of decimal places. The solution is a floating-origin, which just means constantly moving the player back to 0,0,0 where all the decimal places live, while moving the rest of the universe in the opposite direction. So in Black Road Sky, and probably any other similarly scaled game, you don't really move the ship in the direction you want to go, you're actually moving the universe in the opposite direction while you stay put. Maybe that's how conscious reality works, too? Trippy, man. There's some additional voodoo required to make everything work (camera tricks that I haven't got around to worrying about yet, implementing double precision math in the places where Unity doesn't support it, etc.), but that's the gist.

This was fairly simple to implement, mostly because I already figured it all out in the previous version, so it was just a matter of getting it working with the current improved game architecture. The end result is that the BRS universe now includes 2 cubes spaced a few billion kilometers apart, and you can travel between them without reality exploding.

Building Out Nav/Com

Now that we have distant objects to visit, I wanted to spend some more time on the new navigation & communication system. Previously, sensors worked magically and were completely divorced from the coms system, which was literally just a big red button that asked the nearest station "cool if I dock?" or "cool if I undock?" depending on context. So lots of room for improvement, and I'm excited about how it's shaping up.

My first task here was to implement a "Transmitter" class, which I can add to any object in the game. The transmitter defines signal type and power (more on that next time!) and constantly blasts out basic info like ID, position, and velocity, on a particular frequency, propagating at the speed of light. Nothing is actually being blasted around at the speed of light (simulating a universe of elementary particles is a bit out of scope), but a clockwork of timers and message queues provide sufficient illusion. Data is passed from communication to navigation for calculating useful values like relative velocities and, eventually, for drawing a new & improved sensor display. Not quite there yet, though.

Communication frequencies in BRS are hidden under a layer of abstraction and are presented in a sort of IP address-like format. I took a silly detour to formally define that format (part of the Solis Unified Transceiver Standard), so even though no one will ever notice, these frequency identifiers represent not only a unique ID, but also indicate the signal source type (ship, station, nav beacon, etc.), province of origin and other context-specific information. Maybe got a little carried away, but if I wasn't the type of dude who gets a little carried away I wouldn't be making this game at all, you know?

Coming Up Next

I've still got a lot of nav/com work that I'd like to get done, but if I feel myself getting too far into the weeds then I may put some of it off until later. After that I'll be working on close-range physics, which was a major weak point of the previous version and is in serious need of an overhaul.

I expect development to continue a bit sluggishly for the next month or two due to the labor that I must sacrifice to Capitalism in return for the right to live (can we get this class war started already? Counterforce unite!) and, less depressingly, end-of-summer honey harvesting. Work tends to derail me around this time of year, so wish me luck as I hold on tight and try to keep the torch above water.

Propulsion Hardware & The Road Ahead

With the internal propulsion hardware complete, I've FINALLY ticked off the last to-do item on the first official (also, as it were, internal) version of the new Black Road Sky. I'm fucking stoked.

There's not enough game here to warrant a public release, but check out the tentative roadmap at the end of this post to get an idea of where we stand in the bigger picture.

Refueling, Coms & Utility Dock

An initial refueling implementation is in place, and I don't expect it to change much as development continues. Instead of docking internally, walking through the station to a terminal, and pushing the magic instantaneous refuel button, there is now an actual refueling procedure!

Refueling requires a connection to the new utility dock located on the nose of the ship. This will eventually be achieved either by docking externally, or by manually connecting a pump mechanism from the station if docked internally. Refueling requests are made from the cockpit via the newly (& very sparsely) implemented Coms System. This will probably be some sort computer terminal accessible from the pilot seat. Once fuel is flowing from the station to the ship, there's a refuel valve in the engine room that you'll have to open in order to actually accept the fuel, which arrives at a rate of less than infinity, unlike before.

A cool consequence of all this new complexity is that you can also open the refuel valve when undocked to vent fuel. I don't expect this to be very useful, but because the utility dock is right on the nose of the ship, this can provide weak but usable aftward propulsion in a hypothetical MacGyver-like emergency.

For now, most of this happening virtually, but it's ready to be hooked up to gamespace controls in the near future (see roadmap below).

Propellant Control

In other engine room news, the propellant manifold & pump functions are now complete.

We have manifold valves to adjust the flow of fuel to each booster as well as to individual RCS thrusters. The main purpose of these is to compensate for uneven thrust due to hardware damage. Limited booster valve control is also available via a yaw trim slider which will live in the cockpit, within easy reach of the pilot seat. On the RCS-side, there is an additional valve for dialing in the 'docking power' mode to your preference.

The pumps, which will eventually use electricity, adjust the response rates of the boosters & thrusters. Again, this can be used to compensate for uneven wear, but it can also be used to improve the response of a cheap piece of equipment at the expense of increased wear damage and, eventually, power draw.

This hardware (as well as the utility dock itself) is all implemented by the same system as the rest of the ship hardware, meaning that I can easily make it all breakable, repairable & upgradable if that ends up feeling like a good idea. For now, I'm just leaving them as stock parts baked in to the ship, for fear of making shit too complicated.

Tentative Roadmap

Of course this will change, but here's the roadmap as it stands today. We've got a long way to go, but I don't think there's anything standing in my way now except myself, and that guy basically does whatever I say.

Newtonian Flight Systems In Place

I'm back in the groove, as the pendulum swings, and more or less caught up to where I left off last summer. Which isn't terribly far, and it took longer than expected, because it always does, although 'caught up' isn't really accurate with all the improvements made along the way. Systems that I felt were too shallow are a bit deeper, while overcomplicated aspects of the codebase have been simplified.

Everything is more stable and better optimized. I'm fixing problems as they occur rather than adding them to a to-do list and focusing on blasting through to the next feature. Feels good, man.

Main Flight Systems

The RCS, booster, and gyro systems are all in place now, rounding out the basic flight controls. I still have a lot of features that I'd like to add to those systems, but the foundation is built in a way that should be conducive to adding new components with minimal pain-in-the-ass.

Those additional features will be things like startup procedures and system-related engine room equipment, as well as power & heat management, two things I kept putting off in the previous project once I realized what a mess it was going to be to implement anything beyond the absolute basics. This time around, I've kept all of those future problems in mind while building the initial system implementations. It won't go as smoothly as I'm expecting it to, I've learned to distrust that instinct, but it should be a hell of a lot easier now.

Interior Fuel System Components

Fuel System Diagram

I'm currently working on the first bits of engine room hardware for the RCS & boost systems. These pump & manifold systems can be adjusted to compensate for asymmetric wear as well as to generally tune your engines, either by pulling back on power to conserve fuel and protect the hardware from wear damage, or to hot rod yr shit with abandon.

The controls for these pieces of equipment will be mostly located in the engine room, associated physically with the equipment itself, but some functions may be available in the cockpit for convenience; most likely, at least, some sort of yaw trim for keeping your boosters from pulling in one direction. This is a problem that can also be corrected with the new auto-stabilization options, or of course by dealing with it manually like a heathen.

I'm just getting started on all of this, so I may have more to say about it next month. In the meantime ...

Check out Sylph!

I've been getting my sci-fi flight sim kicks from Sylph for the past couple of weeks. It's a small-ish game (I think?), but if you're into the genre enough to be reading this then you'll probably dig it.

I made this long-winded (as is my wont) tutorial video if you get stuck at the beginning, but I encourage you to give it a good try on your own first. You don't get many opportunities in life to figure out how a spaceship works, after all.

Easy Does It

The work continues, but alas, nothing exciting to report this month. A busy-as-usual spring beekeeping season, a weeklong camping trip, and Dave the Diver all conspired to slow my progress. So it goes.

I haven't even got to the booster system yet, to be honest, but I also put a bit more effort than expected into finishing the damage, repair and upgrade systems. Since they'll be shared by probably all of the remaining systems, I want to get them as right as possible the first time, and I think they're there now.

So all good in a no news is good news kind of way, and I think I should be able to buckle down and get back to it properly this month, now that the bees are done acting swarmy and Dave's done diving.

Item Skin Maniac

Nothing too exciting this month, still reimplementing systems and catching back up to where I left off back in August.

The systems architecture that I wrote about last time is in place, although it took longer than expected to finish up because I, like, forgot how programming works. Been a minute since I finished that CS degree. But it feels good to get back into a software engineering mindset, and I'm very happy with the result.

Fuel, RCS & Gyro Systems

The development of this new version has been pretty abstract up to this point, so I figured what this spaceship flying game could really use is the ability to fly a spaceship. To that end, I got to work on reimplementing the RCS system. I talked about this back in June & July, so you can scroll down for more info, but basically the thrusters now work in a more realistic (and satisfying!) way, they can break and wear down, you can fix them and upgrade them, and I've added a few new in-cockpit features. I mean, the cockpit doesn't exist yet, I haven't got to the 1st person stuff, but it's all working with default keyboard controls.

Getting the RCS system back up & running required that I reimplement the fuel tank, which is also now upgradable. The tank & it's fuel have mass, so it'll be up to you whether you prefer a smaller tank for a more maneuverable ship at the cost of more frequent refueling, or a big-ass long haul tank for the full lonely space bastard experience.

The RCS thrusters can now provide auto-stabilization c/o the gyro system, which means that I also had to reimplement the gyro system. Again, I wrote about this in more detail last summer if you want to dig deeper, but basically everything is cooler than it was before.

I should be clear here that shops don't exist in the game yet, so you can't actually upgrade anything, but the systems are in place & ready to be eventually hooked up to a shop UI of some sort.

Coming Up Next

I've still got work to do on all the systems mentioned above, but they're just about done. Next up is the booster system, which should go pretty quickly. With a flyable ship back in the game, I can move on to system-scale simulation which should catch me up to where I left off last summer.

Epilogue That Nobody Asked For

numbers unknown to science