Good Morning from my Robotics Lab! This is Shadow_8472, and today, I’m changing my goalposts and slapping a finished sticker on last week’s project. Let’s get started!
The Design
Where to start now that I’ve “finished” this project? The hull is defined by ship’s systems, but ship’s systems have to fit inside the hull. The whole point of this craft was to make a craft that could bore in its own silhouette without as much overhead, and the simplest way to do that is some take on the cylinder.
In the interest of added visual appeal, I played around with different angles all along the length of my design. The cockpit is as close to a sphere as I can get and still have major flat regions. I added a skinny neck just because, then a larger habitation section with two decks: a multipurpose room and fuel storage/airlock. My cargo hold also houses most of the ship’s batteries, and engineering has a bunch of engines I’m basically lugging around and a tiny secondary cockpit in the very back. Each section listed above — aside from engineering and auxiliary control — is individually pressurized using doors.
When I went to start adding thrusters, I found all my fancy angled hull sections lacked adequate mount points. I adjusted my spreadsheet to find I could boost my effective thruster power by adding nine small thrusters to each big one, at the cost of an extra couple blocks footprint. I sent my new number through my spreadsheet again, and found I’d only need about ten “super thrusters” to hover.
Oversight
I totally forgot about the weight of the ship. In fact, I couldn’t figure it in because of the way the game reported my mass including the ground-based station I was attached to, as well as any ships docked to it. As a result, when I went for my first nose down test, I wasn’t able to back out of my hole, even though it was a third full, tops.
And with the power of extra thrusters comes greater draw on the power grid. I totally neglected to run the numbers before taking off, and found my batteries maxing out while accelerating upwards. I can probably hover under max load, but I’m also looking at the overall battery life. There’s also the fact that I’d like to relocate my base to a nearby mountain top for a bit more light. The air up there is thin enough to where the thrusters I’m using are not as effective.
Game Boundaries
Many games hint at their boundaries before you run into them. They may take the form of an invisible wall marking the edge of a level or a second stack of objects denoting a limited size inventory.
Space engineers has a feature that lists every intractable part of a ship or base your interfacing with. User-defined groups let you manage several parts at once so you can do turn on all the drills or toggle the lights. Maybe all the batteries need to recharge. What this feature lacks is a means to select a range of parts. (Edit in post: Feature does exist, it’s just my right shift key closes the window.) When I found myself with 300+ small engines, I had to click on every last one of them, and it wasn’t fun.
Another lacking feature as I’m finding is the inability to manually move items around. After a marginal amount of research on the official Discord server, someone introduced me to sorter blocks’ unadvertised function of pumping ships’ inventories dry of all matching items.
Takeaway
Game developers will generally have an idea of the scope of the stuff their target audience of players will be doing. Wandering off the intended set of use cases can lead to frustration, but every so often, it can lead to art.
My ship isn’t the easiest thing to look at. It’s covered in way too many engines for its own good, and it still accomplish its mission of hovering while pointed straight down under full load. It’s still more capable than my first ship, which I’m thinking will make for a nice shuttle pod later on.
Final Question
Have you ever set expectations high for a project, only to settle with something that’s still better than you presently need?