Offworlders Announcement/Feedback thread

[LordFowl]

I would also like to say that Skull's analysis of bloat ignores a third of the ratio - gameplay bloat. Codewise I personally have ideas where it being a "disability" would actually not be that bloatful, lorewise I've long ago given up on, and gameplay wise having it be a species is bloat. Don't believe me? Let's walk through it.

1) The most obvious repercussion is that it creates another entry on our species selection screen. Not terrible but certainly not great, especially since IPCs (who in many ways define bloat) already occupy a large chunk of this real estate.

2) Applying it to nonhumans amplifies this bloat, and so we create an arbitrary limit specifically in an attempt to cost-optimize our bloat.

3) It's a subspecies, which on their own tend to be just replications of the major species with a few wrinkles. This is alleviated greatly in the fact that all species are practically (although not technically) children of the human species, but it still can create wrinkles if we try to create further mechanics regarding subspecies. You can see this in action with code currently attempting to handle IPCs. Everything mechanical for an IPC needs to be consider about 5 extra times because of the five subspecies and the minor but distinct differences between them.

I disagree with skulls depth to purpose ratio analysis. I don't think the mechanics of this species are deep enough to justify creating another subspecies. I do however think that making it a "disability" represents an interesting scenario that should be investigated. Skull is write in that this would require some additional back-end bloating (because while the "disability" datums are not currently designed to do this I think I can figure a few ways to replicate a lot of these features using them.), I think that the code minor bloating there can be cost-optimized a lot better than the major gameplay bloating here.

Some advantages of it being disability based:

1) The species selection screen remains uncluttered and obvious.

2) We remove a child species (Children species can cause some unexpected inheritance behaviors). We should really only be creating children species if they have very deep mechanical impacts. Really I would say only if we need to insert things into spawning or life(). Minor variable coefficient changes can be done in a plethora of better ways imo.

3) "Disabilities" are not inherently attached to any given species, meaning that we can create a disability for "space adapted" and it is a template that can be applied to any species. I think this is one of the biggest points in favor of disability, because it removes the arbitrary cost-optimization I mentioned above.

I disagree with the idea that this cannot be implemented via "disability". I can already think of a few easy ways to replicate half of this using code that already exists. The only problem that requires serious consideration imo is incorporating the RIGsuit limitations into disability.

Analyzing gameplay bloat is a complex and tricky substances. IPC subspecies represent the worst bloating pretty much imaginable. Each one is pretty much just an icon change and a few changed variable coefficients. It's even worse because we already have a prosthetics system that can handle this. Aut'akh, for all their flaws, represent something that pretty much can only be done via subspecies, because they have so many unique organs compared to baseline Unathi.

Edited February 20, 2019 by LordFowl

[Itanimulli]

54 minutes ago, Zundy said:

They should be attached to current factions. Solarians can live in low g space stations. Elyrans can. Dominians can. Don't seperate em out imo.

This, perhaps. But then that might get into the issue of faction specific colors. NOt exactly necessary, but definitely a nice touch.

[Itanimulli]

5 minutes ago, LordFowl said:

I would also like to say that Skull's analysis of bloat ignores a third of the ratio - gameplay bloat. Codewise I personally have ideas where it being a "disability" would actually not be that bloatful, lorewise I've long ago given up on, and gameplay wise having it be a species is bloat. Don't believe me? Let's walk through it.

1) The most obvious repercussion is that it creates another entry on our species selection screen. Not terrible but certainly not great, especially since IPCs (who in many ways define bloat) already occupy a large chunk of this real estate.

2) Applying it to nonhumans amplifies this bloat, and so we create an arbitrary limit specifically in an attempt to cost-optimize our bloat.

3) It's a subspecies, which on their own tend to be just replications of the major species with a few wrinkles. This is alleviated greatly in the fact that all species are practically (although not technically) children of the human species, but it still can create wrinkles if we try to create further mechanics regarding subspecies. You can see this in action with code currently attempting to handle IPCs. Everything mechanical for an IPC needs to be consider about 5 extra times because of the five subspecies and the minor but distinct differences between them.

I disagree with skulls depth to purpose ratio analysis. I don't think the mechanics of this species are deep enough to justify creating another subspecies. I do however think that making it a "disability" represents an interesting scenario that should be investigated. Skull is write in that this would require some additional back-end bloating (because while the "disability" datums are not currently designed to do this I think I can figure a few ways to replicate a lot of these features using them.), I think that the code minor bloating there can be cost-optimized a lot better than the major gameplay bloating here.

Some advantages of it being disability based:

1) The species selection screen remains uncluttered and obvious.

2) We remove a child species (Children species can cause some unexpected inheritance behaviors). We should really only be creating children species if they have very deep mechanical impacts. Really I would say only if we need to insert things into spawning or life(). Minor variable coefficient changes can be done in a plethora of better ways imo.

3) "Disabilities" are not inherently attached to any given species, meaning that we can create a disability for "space adapted" and it is a template that can be applied to any species. I think this is one of the biggest points in favor of disability, because it removes the arbitrary cost-optimization I mentioned above.

I disagree with the idea that this cannot be implemented via "disability". I can already think of a few easy ways to replicate half of this using code that already exists. The only problem that requires serious consideration imo is incorporating the RIGsuit limitations into disability.

1) The species selection screen is literally a non-issue, unless for some reason it causes issue in code that you simply don't want to deal with. You click species. You scroll through the species. You pick the species. No one complains about there being hair bloat.
2) Idk what this is.
3) Why the heck would there be *any* space adapted Taj? Space adapted unathi?
 

Edited February 20, 2019 by Itanimulli

[LordFowl]

I think I've already been over that.

[Snakebittenn]

The species is already in the codebase, though.

[LordFowl]

I think I've already been over that, too.

[Guest Marlon Phoenix]

There will be dominian spacers, elyran spacers, etc. The scarabs are the flagship of the group in a way that we can better portray them as a society for the purpose of character foundation and development.

[Alberyk]

I am the coder working on this project, you can see the pr here: https://github.com/Aurorastation/Aurora.3/pull/6078

To answer some questions and concerns:

It is possible to link some of the mechanics of the off-worlders to a trait/disability, however some features will be lost:

-their unique human sprites won't be added

-their loadout will have to be unrestricted, if added at all, which means that anyone, even people without the trait/disability, will be able to spawn with it, further restrictions being only species and job related

I do believe that adding them as a species is the best option, to avoid "snowflake" checks, since the species one uses more generic ones that could be used for other species and etc. And it feels more in line with the narrative that it is being put here.

However, I am not against changes in the pr, but it is not my decision to make and I am following the request/direction of the lore team here.

[Icuris]

Voidborn-ripped straight from whichever media resource...

Stellernaughts

Overlanders, if it’s decided that they are strictly from space?

 

main concern is: Making the new subspecies and mechanics easy to understand and easy to use.

If both can’t be achieved the new role will be underused or not used to it’s full potential.

 

[Doxxmedearly]

The lore seems solid, the mechanics are interesting, and the way you are gathering feedback and planning to introduce them are wonderful. I'm very much in support of this addition. Great job.

[GreenBoi]

I think everyone is overreacting. Yes, it's a human subspecies/potential disability, but does that really matter? The only thing that really bothers me is the name, but not like what other people are saying. No one has or ever will refer to someone who lives in space as an "offworlder", the term wasn't even thought to be used in conversation until literally now. We've been using the word Spacer forever, no need to suddenly go "But what am I to be called other than an offworlder?"

 

I think, that in general, Offworlder is a wierd term to call them. They should just be called Spacer or Space-adapted. "No-G's" could even stand as a nickname for them, Offworlder just sounds...oddly specific and wierd?

[VUX]

i go into this argument with the understanding that the thematic purpose of the spacers has been stated to be a 'more alien human subspecies'.

if their thematic purpose is to be an alien sort of human subspecies, right? in giving them a reliance on human aids - rigs, bracing, splints, what have you - you are subtly enforcing the idea that they are normal people with birth defects, which, while that may be accurate, it undercuts the weirdness of them and wastes an opportunity. in this case, they might as well be pale humans that spawn with broken legs.

rigs, braces, etc. are fine as an option, but they should be an option or a cultural thing, rather than a mandated one. this opens the door for more 'alien' aesthetics for some spacers, and a more humanlike one for others. i have a very specific vision, myself, of a spacer being a tall and lanky creature with a creepy face, maybe a tapetum lucidum (cyber or otherwise) to give them sharper low-light vision while making them creepy (since they do the laser eye thing). the slow, awkward, wheezing, but otherwise entirely normal spacers as depicted in things like The Expanse are pitiable rather than foreign, and the requirement for large amounts of supportive gear heavily favors the latter interpretation over the former.

i do not mind if braces are required if rigs are not required, and if the braces are unobtrusive. i do not agree with braces being necessary, but that is a less important point than removing the necessity of a rig.

i am also not saying they ought to be superior to humans stat-wise -- they should have other drawbacks and other benefits. gameplay wise, being without a backpack is crippling for almost every job. do away with that. make them more susceptible to brute and burn damage in exchange for greater environmental tolerance and less bleeding.

[kyres1]

Hi again. The lore team has come to a conclusion that the ESS will be optional, though default. Other forms of standing upright comfortably will be sought out and available as optional alternatives to using the ESS wherever you go. This way, you may seek any aesthetic you desire, any background you desire and still maintain the downside of being a offworlder. More details will be added to the post shortly on this once coder input is gathered.

Edited February 23, 2019 by kyres1
I mean offworlder whoops sorry dude haha

[kyres1]

Main post updated with alternatives to the ESS, such as RMT pills, prosthesis or augmentation.

[makkenhoff]

I like this. The only concern I have is the nullification by pill; this cheapens the disadvantage, as I see it. Future research options that mechanically remove the limitations are fine, because that's progress, like curing the blind. The ESS is fine, as I believe it strengthens the idea that you are forced to accept robotic assistance in order to work on the station - on the part of built in weld protection, I love the idea of it not being a hassle to have to fumble around with it.

 

As for the whitelist concerns.. the only thing about this race that might warrant a whitelist is the ESS itself. And really, it's not a huge advantage on a heavy roleplay server.

[GreenBoi]

I don't think the pill should nullify. I think it should half it instead so it's still a prevalent issue.

[kyres1]

On 20/02/2019 at 14:52, Skull132 said:

Lore wise. Ayy, probably bloat. Why are they being added as another human faction? (The scarabs.) On top of the already existent set of human factions, which count way more than any other species in our lore. Can they perhaps be implemented to represent or build upon an already existent major faction? To the point of near ubiquity. That way, you could have a clear defining trait for that faction, and something which can be leveraged in game play far better than random pieces of clothing or just names that we have now.

After some discussion we decided to replace Yinglishen in the Frontier Alliance with the Scarabs in accordance to this. They will be added soon TM to the spot seen below.

https://wiki.aurorastation.org/index.php?title=The_Frontier_Alliance#Yinglishen

It will remain in canon due to Frontier character creation rules, just not seen on the wiki for the time being.

Also, the name "Offworlders" has been decided to remain, while subtypes of them (and the term "spacers") will be used independently, which will be described in further detail once the wiki pages go up.

 

[kyres1]

On 24/02/2019 at 07:17, makkenhoff said:

I like this. The only concern I have is the nullification by pill; this cheapens the disadvantage, as I see it. Future research options that mechanically remove the limitations are fine, because that's progress, like curing the blind. The ESS is fine, as I believe it strengthens the idea that you are forced to accept robotic assistance in order to work on the station - on the part of built in weld protection, I love the idea of it not being a hassle to have to fumble around with it.

 

On 24/02/2019 at 14:25, GreenBoi said:

I don't think the pill should nullify. I think it should half it instead so it's still a prevalent issue.

While I'll ask about the pill mechanics or seek something else, these different options are pretty pivotal in being unique crutches for the Offworlders to lean on. They are intended to be entire alternatives to the ESS, rather than just an excuse to take it off.

[kyres1]

Information on the Scarabs has been placed on wiki pages seen here, (also it replaced yinglishen)

https://wiki.aurorastation.org/index.php?title=The_Frontier_Alliance#Scarabs

https://wiki.aurorastation.org/index.php?title=Scarabs

and the wiki page for Offworlders is complete and can also be seen here,

https://wiki.aurorastation.org/index.php?title=Offworlder_Humans

All of this is heavily WIP and all subject to change based on majority feedback.

Edited March 2, 2019 by kyres1

[BurgerBB]

When will they be playable?

[kyres1]

4 hours ago, BurgerBB said:

When will they be playable?

The time for the introduction event, which will come directly before implementation, is being juggled back and forth right now. We're having trouble getting a date settled but the final date will probably be announced a day beforehand. Most likely no further than next week.

[Jessica_Stark]

ESS still lacks weld protection. Please fix this so I can stop grabbing mesons to have mining press them at the beginning of each shift

Also, we still pop lungs at below 17  kpa

 

[Scheveningen]

Report mechanical issues to github, please.