Various base design considerations

If you have any feedback, we'd love to hear from you!
User avatar
Petty Officer
 
Posts: 47
Joined: Mon Sep 02, 2013 9:59 am

Various base design considerations

Postby PensiveElephant » Sat Sep 14, 2013 12:17 pm

Various base design considerations.

There are still plenty of things for us to find out about the developers’ vision of the game, and many others that I am sure haven’t been decided yet. While we wait I thought it would be interesting to engage in wild speculation and simulation - care to join me?

The purpose of this thread is to explore the core gameplay mechanic, basebuilding, as well as exploring various gameplay elements that might influence the range of choices available to an Astrobase Commander.

The focus of the game is supposed to be story, and that means that all systems introduced in the game should be conducive not simply to gameplay, but to story generation as well.

To break up this gargantuan post, and to help in visualising possible stories resulting from the choices presented here, I decided to include a character - please meet retired Commander Noah Good - as represented by his personal memoir-log:

Noah Good wrote:Commander’s log. Stardate: long, but one day after the last one.


Bad name-puns aside, do note that this post is essentially a building and design guide for every possible system I can think of in a game that hasn’t even seen alpha yet.

As such I am making lots of assumptions. Noah’s version on the other hand will assume that all the design choices I will outline here constitute different types of Astrobases.

The obvious question qould be: why don’t I just make this in the form of a question. My answer is: a. what would be the fun in that, and b. the creative process sometimes work better uncontrolled.

So, developers, if any of the points here prompt your comments before I’ve formulated a question: please do.

So, whilst you question my sanity let us move on:


Section Zero: Modules
There is much we do not know about modules.

Will they come in different sizes? Will it be possible to adjust said size? Will they be upgradable? We know that their layout and/or content will be updatable.

One of the most basic aspects of gameplay will be placement of modules - some modules might work better when close together, others might actually work worse in proximity.

Noah Good wrote:When I took over the Astrobase at Roj’ab IV - it immediately became obvious why I had been sent to replace the old Commander (other than the fact he had a Tetrian baseball called ‘Bob’ made his First Officer).

The base layout was awful - the place he designated for the cantina was next door to waste processing, so nobody wanted to rent it. Explosives Labs shared a bulkhead with Residential and people were drowsy from lack of sleep.

If that weren’t enough - the armory was placed closer to the brig than to security - was that man hoping for an armed riot of escaped prisoners?


Attractiveness, noise, traffic - all those could serve a part in the positioning of individual modules.

Section One: The first module

An important question - what does the player start with? What is the first module(s) he sees right after the race design screen?

Starting with the dock would make a modicum of sense, seeing as the astrobase needs means to exchange personnel and resources with the outside world. Starting with anything but the dock means that you have to account for how materials and staff are delivered aboard in these early construction stages. You could also leave it unexplained, I guess.

Beginning with ops has merit, as this is the nerve centre of your base - it is generally easier to plan from such a point.

Assuming that astrobases will have corridors at all (and I’ve seen the word ‘promenade’ thrown about) it might be interesting to build your base around those instead.

Another choice is a special ‘starting’ module - which can serve many basic functions that a small Astrobase requires, but becomes ineffectual after your base grows a bit. One could build the base outward from that point and later replace it with something else.

Noah Good wrote:Some astrobases “hatch”, so to speak, out of all-purpose modules called ‘Hubs’. A hub can serve as a limited docking and administration facility, until more permanent ones are established. The hub can later be reappropriated to serve a more specialised function once your astrobase has grown.

I once remember holding on to a hub for the longest time - it had those wonderful floors from timber from Glaza VII - I just couldn’t let it go.


The following seems to be more an option for a game mode than something that needs a design choice (perhaps an idea for a brief campaign): where you arrive at a pre-designed Astrobase that you have to fix.

That mode could actually be a good way to test the systems and UI in Astrobase Command - if a player had to interact with a station he/she hadn’t built - would he be able to figure out what was what based on the data the game provided?

Noah Good wrote:I remember one base I took over… It was called Anar and it had been suffering pirate attacks for months. I get onboard and it’s a mess - morale had been low for a while and the whole place was falling apart at the seams. The bloody Chief Engineer I got stuck with didn’t even care to give me a proper report. Not that I’m surprised seeing as he hadn’t been doing maintenance checks since the old commander walked through the wrong door and ended up flying out with half a section sucked into space after him.



Section Two: Systems
I cannot discuss systems without talking about FTL - the rather fun game from a few months back - if you haven’t played it, I thoroughly recommend it.

FTL did many things right - but it got one thing too simplistic in my mind - a given system was operational if the room it was in was undamaged. But systems don’t work because the rooms that operate them are alright - because in order to work, your CO2 scrubbers have to be linked with the rest of the ship so that air is delivered there - this means that you may have systems that are operational in some sections, but unresponsive in others.

Here are some systems of this sort:

Life Support and Fire Suppression
Comm and Surveilance
Emergency and Security Forcefields
Control (being able to remotely operate equipment and doors without personnel present)

Noah Good wrote:My most memorable workday?

I was serving on Targa III and a fire broke out near one of the cargo bays - the cargo was volatile - pure Kaboombium. Surveilance and comm to that area were down, and crew had trouble accessing it since the fire was spreading.

Life Support was still working though and I could cut the oxygen supply to the cargo bay to prevent the fire from reaching it and igniting the Kaboombium.

Problem was - there had been people working in that cargo bay who could still have been alive…


Such systems require command pathways, pipes and tubes placed through the station to allow your crew to act more effectively, and various aspects of your base to be directly controlled by you.




Section Three: Power

Most spaceship games I can think of deal with power management to a certain extent.

Star Trek games - Starfleet Command and Bridge Commander devoted a huge chunk to power management. Star Wars games, which were basically fighter simulators, allowed you to divert power between shields and weapons.

And where would all spaceship battles be without saying “Divert emergency power to shields.”

Noah Good wrote:You know, it’s a little known fact, but Commanders are basically useless. We serve no purpose. We provide morale to people and then, at key moments yell something obvious, like: “Shields!” or “Evasive Maneuvers!” or “Red Alert!”, or if you’re stumped for things to say, you just yell “Damage Report.”

It’s also useful to delay firing weapons until some random moment and then give the command to fire very passionately - your crew will not understand why you had chosen that particular moment to unleash your weapons, and they will think there is some brilliant strategy to it!


I have already seen that you plan on having different types of generators, which is great. I can see a lot of different applications for different types of generators, but on the level of actual base design I am most inerested in Power Distribution systems.

There are several ways to go about power distribution
1) Each power plant has a range - every module placed within that range is powered by said power plant. If one module is within range of more than one power plant it thus has backup power in case one of the generators fails. Range can be expressed by number of modules away from a power source or by a circular range indicator.

2) Distribution can be a separate thing to design. Apart from placing power plants, the player would have other power-related utilities available for construction: conduits, capacitors, exhaust pipes. There are many ways to go about the mechanics of such a design:

Let’s say that each power plant has 4 slots for conduits (I will use precise numbers rather than ‘x’ or ‘y’ as placeholders) - these can go from that power plant and be steered by the player through other modules (they don’t need to physically occupy any space on their own). So let’s say that you have 4 modules in line:

Power Plant - Barracks - Ops - Weapons - Bar

You can drag up to 4 conduits from that one power plant. So you drag one to the barracks, one to ops, one to weapons and one to the bar.

This would mean that there would be 4 conduit lines going over the barracks, 3 over ops, 2 over weapons and 1 reaching the bar.

That would be quite expensive and inefficient.

So maybe a single conduit could power any module it goes over? Then it would only require 3 lines to power all the modules - because you could have the bar and weapons powered from the same conduit - it is unlikely that both would be oprational at the same time.

3) Another way to go about distribution is jefferies tubes - small utility corridors that have conduits running alongside them. Jefferies tubes interesting for their security considerations - how do you place them to not decrease the overall security of your Astrobase.

The above are underdeveloped and probably unclear examples (for the lack of visuals) but my point is that designing distribution of particular systems is as important as placement of the rooms and it is actuallythe aspect that might govern various design choices.[/color]

User avatar
Dev Team
 
Posts: 151
Joined: Wed Aug 21, 2013 2:00 am
Location: Canada

Re: Various base design considerations

Postby MaxShields » Sat Sep 14, 2013 2:26 pm

@Pensive: What an outstanding post!

I'm going to need some time to digest this if I hope to provide some useful input in here too.

I think that this page detailing the building process and components of the ISS could be a great reference for how an early stage astrobase can be built: http://orbiterchspacenews.blogspot.ca/2012/11/iss-5000-days-in-orbit.html.

User avatar
Dev Team
 
Posts: 151
Joined: Wed Aug 21, 2013 2:00 am
Location: Canada

Re: Various base design considerations

Postby MaxShields » Sat Sep 14, 2013 6:03 pm

Attractiveness, noise, traffic - all those could serve a part in the positioning of individual modules.


I believe this is a solid assumption since the game does appear to revolve around the characters. As the astrobase will be central to their existence, it would be logical to have it influence them beyond simply giving them a place to work in or fight from. Although I wouldn't want to be sucked into a Sim City in space, I think there's lots of fun to be had in incorporating these dynamics. If I remember right, Startopia (http://www.youtube.com/watch?v=ftqGpsXQZeI) had some interesting ideas at that level.

User avatar
Dev Team
 
Posts: 151
Joined: Wed Aug 21, 2013 2:00 am
Location: Canada

Re: Various base design considerations

Postby MaxShields » Sat Sep 14, 2013 7:03 pm

PensiveElephant wrote:
The following seems to be more an option for a game mode than something that needs a design choice (perhaps an idea for a brief campaign): where you arrive at a pre-designed Astrobase that you have to fix.

That mode could actually be a good way to test the systems and UI in Astrobase Command - if a player had to interact with a station he/she hadn’t built - would he be able to figure out what was what based on the data the game provided?

I like this, particularly as a separate game mode (suggesting a/multiple campaigns, as well as distinct scenarios or missions as possible game modes), as few would have the privilege of inaugurating a brand new astrobase from inception, but many would have the chance to take command of one that has been in service for years or even centuries, each with their own history, vices, and advantages. Besides, Bob was almost as useless a First Officer as the base commander was, anyway.

PensiveElephant wrote:
I cannot discuss systems without talking about FTL - the rather fun game from a few months back - if you haven’t played it, I thoroughly recommend it.

FTL did many things right - but it got one thing too simplistic in my mind - a given system was operational if the room it was in was undamaged. But systems don’t work because the rooms that operate them are alright - because in order to work, your CO2 scrubbers have to be linked with the rest of the ship so that air is delivered there - this means that you may have systems that are operational in some sections, but unresponsive in others.


I agree. It makes sense if the room providing a service is damaged or destroyed for the rest of the systems to go down throughout every area serviced by that room. Conversely, it should be possible to damage that same service in only certain sections of the base without losing it everywhere at once. This could create interesting game opportunities for sabotage or boarding actions, where certain services are cut (say gaining control of life support and venting atmosphere in sections of a ship, or sabotaging it by venting a pathogen through the air ducts) to gain an advantage without disabling the entire craft.

It would therefore be useful to be able to install smaller, less costly auxiliary systems as backups to the main system throughout the station. Rather than have multiple rooms with identical function to the main service provider, you could therefore more efficiently provide a capability by having a powerful central system and several smaller auxiliary systems distributed across the starbase that could be activated only when needed. This would make it easier to maintain, less costly to run, and more robust in the event of an emergency.

I see power in terms of a grid with a total power supply that will supply anything connected to that grid. The grid need not be a single continuous grid throughout the station. The player could choose to create compartments that are each powered by separate reactors, but I think limiting by range is extremely gamey, particularly over the small distance that small-medium bases would cover. The Death Star on the other hand...

The capability of the power grid to handle demand could be divided across two tiers. Low and High power. Each module could come pre-wired with a low power grid that can automatically supply power for lighting, basic life support, and simple systems. High power systems would need dedicated conduits as you propose. High power systems could include weapons, shields, and certain key life support or high end science systems and sensors. The more the points, the larger the power conduits needed until you progress into absolutely needing Jeffries tubes (which I really like the idea of) or service corridor modules that will help distribute power, data, and life support, facilitate maintenance, provide rapid transit of material and personnel without hindering the base's main functions, etc.

User avatar
Petty Officer
 
Posts: 47
Joined: Mon Sep 02, 2013 9:59 am

Re: Various base design considerations

Postby PensiveElephant » Sat Sep 14, 2013 11:44 pm

MaxShields wrote:
PensiveElephant wrote:The capability of the power grid to handle demand could be divided across two tiers. Low and High power. Each module could come pre-wired with a low power grid that can automatically supply power for lighting, basic life support, and simple systems. High power systems would need dedicated conduits as you propose. High power systems could include weapons, shields, and certain key life support or high end science systems and sensors. The more the points, the larger the power conduits needed until you progress into absolutely needing Jeffries tubes (which I really like the idea of) or service corridor modules that will help distribute power, data, and life support, facilitate maintenance, provide rapid transit of material and personnel without hindering the base's main functions, etc.


This is an excellent idea, actually!

As far as supply and demand goes it would be important to remember that unused power has to go somewhere - it can be stored of course, but once you go over storage capacity it has to be discharged somehow or risk overload. This would mean that cutting conduits or destroying modules that consume/discharge power could lead to said reactor overload.

User avatar
Dev Team
 
Posts: 151
Joined: Wed Aug 21, 2013 2:00 am
Location: Canada

Re: Various base design considerations

Postby MaxShields » Sun Sep 15, 2013 1:21 am

The large number of modules that will make up a station, and the individual customization that each can undergo will need to have a streamlined way to ensure that components can be upgraded without becoming soul-crushingly dull or missing components that simply go unnoticed in the process of modernization. As an astrobase commander, you're going to be busy making important executive decisions about which trade route is the best to take over so you can regain access to your supply of contraband Ilonian cigars, not running around the base on some mini-game to find spinning spanners before the time runs out.

A method of upgrading: the player would select the component to upgrade in a given module, and then select the modules he wants that component to be upgraded in, or identifies a radius within which all similar components are selected. The components in each module are highlighted to allow the player to quickly ensure that everything appropriately selected. An associated cost for the project is presented and the player accepts or refuses. An option should also be available to simply upgrade all, or a certain percentage of, identical systems within the station to save effort.

User avatar
Dev Team
 
Posts: 151
Joined: Wed Aug 21, 2013 2:00 am
Location: Canada

Re: Various base design considerations

Postby MaxShields » Sun Sep 15, 2013 3:05 am

PensiveElephant wrote:
As far as supply and demand goes it would be important to remember that unused power has to go somewhere - it can be stored of course, but once you go over storage capacity it has to be discharged somehow or risk overload. This would mean that cutting conduits or destroying modules that consume/discharge power could lead to said reactor overload.



Yet another great opportunity for sabotage, or catastrophic critical hits during space battles.

User avatar
Dev Team
 
Posts: 151
Joined: Wed Aug 21, 2013 2:00 am
Location: Canada

Re: Various base design considerations

Postby MaxShields » Wed Sep 25, 2013 7:32 pm

If you're looking for more inspiration for the components that can fit into a base and some game mechanisms to support them, the Battletech Strategic Operations (CAT 35004) pages 122-161 has plenty of great ideas.

User avatar
Dev Team
 
Posts: 99
Joined: Thu May 16, 2013 9:32 pm

Re: Various base design considerations

Postby Dave » Fri Oct 04, 2013 7:00 pm

PensiveElephant wrote:
Will they come in different sizes? Will it be possible to adjust said size? Will they be upgradable? We know that their layout and/or content will be updatable.

One of the most basic aspects of gameplay will be placement of modules - some modules might work better when close together, others might actually work worse in proximity.


I'm reading this thread as I'm digging into the dark details of modules!

What kind of makes sense right now is when you design a module, you pick a shell (options are things like shielded, armored, insulated, standard, etc) and then fill in the 4 quadrants with duty stations. Duty stations can take up 1, 2 or in some cases all 4 quadrants. The shell restricts the choices that goes in. So for example, sub-atomic reactors (fission, fusion, etc) can go in armored and shielded shells, but quantum reactors can only go in temporal or shielded. Biochemical reactors are insulated and armored. And so forth

Shells modify basic properties of the module such as power draw, structural integrity, and resistance etc. (I should probably talk about how station power works, as it's something we prototyped very early on and it has a good feel to it. I can do that for the next blog post on Tuesday). But I do like the idea of low/high power maybe we can incorporate that. :)

Then you have build skills and use skills.

There are also type-specific properties. So for reactors, this is accident frequency, severity and type (based on use skills of the person assigned). For medical it's wounds healed/time, based on the use skills of the assigned doctor. Note if he fails his checks, he can inflict wounds/kill a patient. And so forth.

After you have designed your module, it adds up the properties. So you're balancing things that can live in a given shell type vs what you want the module to accomplish (maybe you want a maintenance terminal in one of the quadrants for your reactor room, maybe you don't) vs the build and use skills. So a module with quadrants that check a lot of different build skills will be harder to build (because the metaphor treats the construction crew like a mission).

Once the module has been designed, you assign the build crew and select any spot that's adjacent to an existing module (x y or z axis). Then you see the build crew building the module, and a progress bar. As the skills of the build crew are checked, attributes are cumulatively added to the module.

As for size... I'm kind of split on this. I'm of the design opinion that you don't want to add elements that detract (or don't support) the core fun. It would be cool to have different footprints for modules, but I wonder if that really adds anything to the gameplay. We'd probably have to playtest that, unless anyone feels super-strongly.

Since I'm currently doing the detailed system design
(think: massive spreadsheet with every property of everything module related) nothing is final :) Just throwing out the direction I'm exploring right now.

The GUI limitation is that it has to work well as a "datapad program" (which I just discussed last blog post)

User avatar
Petty Officer
 
Posts: 47
Joined: Mon Sep 02, 2013 9:59 am

Re: Various base design considerations

Postby PensiveElephant » Fri Oct 04, 2013 9:14 pm

Will there be corridors?

Have you considered modules larger than 2x2 or perhaps linking same-type modules if they are next to one another?

Next

Return to Feedback/Suggestions