Shipbreaker Salvage - Salvage Rework Proposal (Redux)#630
Shipbreaker Salvage - Salvage Rework Proposal (Redux)#630SlamBamActionman wants to merge 13 commits intospace-wizards:masterfrom
Conversation
src/en/space-station-14/departments/cargo/proposals/shipbreak-salvage.md
Show resolved
Hide resolved
|
Apologies for the scatterbrain, this document is so large and non-atomized it is extremely difficult to properly digest, which.. is another negative against it, sorry: This document is extremely how-sy, describing the entirety of the implemented game mechanic without ever going into the why's of any individual feature's design intention. Design documents are not hows, they're whys and whats. That's a feature list, not a design document, and fails to convey any of the thought or intricacies of the work being done and fails to convey the why of the mechanics. The justifications given at this time are weak (why does the station need resource generation, for example. People barely consume them!) and focus on "given realities" that no-one has bothered to actually give reason to at this time, and those "given realities" are also precisely why salvage has consistently failed and need addressed. Atop that, it's significantly over-length and should probably be split into more than one document, properly describing the individual features at hand, so it can serve as a design reference like it's supposed to. This reads significantly more like a persuasive essay, one that doesn't cover its own negatives, than any sort of actual design documentation. The thing that leaves me very skeptical is quite simple: This is extremely similar to the original salvage document to a T. Like, the one mirror/I/etc worked on. It's just a more complicated (fluff filled) version of that. We, effectively, already know the flaws here! It's just been several years so we're repeating ourselves instead of acknowledging these similarities, because you and others were not here to see it. I, also, realistically think any new salvage documentation needs to fit in a reality where we have, in theory (or ideally practice) entirely removed the mechanic and filled the gaps, to see how we can fit it back into the game in a fresh perspective instead of trying to repair a shattered vase. Most importantly to me: I had the pleasure of removing Salvage entirely from our downstream, and the lump sum of code and functionality was over 26,000 lines of code for mechanics a tiny fraction of people ever see. And I likely missed several thousand! Anything that big needs to have more justification than being used by 4% of players on any given round. That's outright larger than much more 'critical' portions of the game like:
The amount of complexity any one mechanic can be allowed is generally proportional to how many people get to mess with it. Mechanics like physics get huge leeway because that amount is 100%. Atmos gets some because it's a fairly large number as long as you ignore the (frankly poorly designed) job. R&D is something 10-20% of people in a round get to mess with directly, and the 'barrier' between them and a random schmuck (assistant) is very small, so the others can get in on the fun too. Salvage fits none of that. It is still isolated, through mechanics alone the fact it is in space and access locked away in a corner with significant resource requirements to engage mean no assistant is ever gonna overcome the barrier on their own. People can't engage with salvage without being the designated salvage guy or maybe cargo sometimes, so it does not get 25kloc+ worth of development effort and maintenance cost. |
|
tl;dr there's a reason all the original salvage folks want it gone and are more on board with the idea of it being a keystone mechanic like everything else of similar scale (i.e. designated job, but playable by anyone and a focus of the wider game.) see lavalandstation. which, frankly, i doubt it'll ever be a keystone mechanic here, so you're best off making it a keystone mechanic for your cool new salvage downstream |
|
The keystone mechanic is one possible direction to take for the design, but its not the direction this proposal has decided to take. This isn't a new divide, this also happened back in SS13, with the TGstation style shaft miner/lavaland and the Goonstation style station miner. This proposal is much closer to the Goonstation design then the lavaland design. I do agree that a lavaland style idea, or something similar, is more appropriate for a keystone mechanic (e.g. a location with unique plant life, unique atmospheric composition, unique engineering problems, unique fighting tactics, etc....) but this is essentially out of scope for this proposal which is going in the station side design (e.g. making salvage a station-bound role and MUCH more integrated into roundflow). The upside of the keystone design is that it can POTENTIALLY impact more players, with a lot more unique mechanic, but I have to say that in reality, all lavaland implementations seem to be ignored mostly by all the other roles on station, the most promising one I've seen is the SS14 goobstation one, because the mapped access to the lavaland shuttle is open to anyone who wants in, but even then, its mostly used by paramedics to come and help the miners, not by botanists or scientists or engineers or whatever (or at least not yet). The upside of the station-bound design is that it can be integrated a lot more into roundflow, with unique ressources being essentially time-locked, making other departements progress naturally with time as miners get those resources more reliably. You can have unique engineering engine part require special materials to make more power, science mechs or weapons, medical tools or medecine, whatever you want, being essentially time gated, naturally getting introduced into the round as time goes on. Also you can actually find those people reliably in a specific location if you want to interact with them, which goes a long way. The downside of that design was that the core gameplay loop was boring. You call a meteor, you click on it 10 times, maybe you click on some enemies 3 or 4 times and bam, loop over, start again. |
Lavaland is not at all a keystone implementation of salvage/miner. It suffers the exact same issues Moony has outlined, in that it's large-scope content for only a handful of players. It's not at all something that connects the game together by having departments come together; it's an entire side-realm that very few interact with in a given round. Sure, there's been attempts to try to get other departments to interact with it, especially with TG introducing a public shuttle. But at the end of the day, other roles had no reason to visit lavaland due to the equipment gate that lavaland navigation is locked behind, alongside the simple fact that there's a whole dedicated job to exploring, hunting, and mining in lavaland. Even though, ostensibly, anyone could visit lavaland, the reality is that it was still a whole separate game that a small handful of players were socially locked into (through both the server rules and the surrounding playerbase) TG ultimately threw the towel in, and ended up fully embracing miners being their whole separate game, by reworking the role completely into bitrunners. A role focusing on the main highlight of lavaland: the megafauna fights. In our eyes, this makes it a potent alternative to mining/salvage when the concept holds a dedicated job, as it completely drops the facade of "well, other departments could help miners" in favor of just being honest to players and designers. Anyway, what "keystone" implies is axing salvage technician as a dedicated job, and giving the responsibility to the crew as a collective whole-- ideally in a way that emphasizes itself as an option to fill out otherwise idle downtime (which the game currently has plenty of for most roles, especially engineering, cargo, and sec). This isn't exactly exclusive to any particular salvage/mining implementation, though for breaksalv in particular, we feel it'd work fairly well since it already has the seeds for interdepartmental cooperation, but currently lacks an answer to the question of "what do I get out of it?" (when it's a keystone, the answer becomes "fun to fill out your downtime"). Within the design doc discussion thread, we've laid out a variety of major implications that making it a keystone feature would bring to the table. |
EmoGarbage404
left a comment
EmoGarbage404
left a comment
There was a problem hiding this comment.
I left a comment on the first breaksalv doc so I figured i'd give this one a read as well.
Generally, the largest sin about this doc is that it's completely unwilling to commit to it's gameplay decisions, leaving huge elements of the proposal as gaping question marks.
The big obvious question that this doc seems unwilling to answer is the question of whether or not wrecks will be mapped, randomly generated, or fuzzed with some combination of the two.
I know the doc says this but like this is not really a statement:
This document does not make a definitive statement on how the wrecks and wreck types should be implemented technically. There are many options here (some better than others), from handcrafted prefabs to fully randomly generated
For context, issues of premapped wrecks vs. procgen maps was probably one of the single biggest factors in the switch from 2021-era magnet salvage to expeditions as a mechanic. It's been a pretty constant source of maintenance concern and is something which could justify an entire document of its own. It's pretty much indefensible to not actually specify what the plan is for it. FTR i think you could put a good argument for combo mapped + variation passes with spawners but as it stands that's not being made.
The other obvious element which has kinda been left unexplored is this whole notion of "quests" and "relics." I was initially curious when i saw the terms because it seemed like an interesting idea, but looking into the doc, an unbelievable level of detail has not been specified. I'd argue that the doc is borderline unfinished because this extremely important portion of it is just missing a ton of detail.
The doc sorta just poses a bunch of mechanics and outcomes but doesn't really outline how these things would manifest as actual game elements. SS14 is generally a highly immersive and simulated experience, so having something as blatantly "gamey" as an automatic quest tracker just seems like it would be unfitting.
I think there's also a question of maintenance burden when it comes to these quests. Out of the examples given, it appears that every individual quest would need to be individually designed and added to interface with each different job or department in the game. I tried to see how often relics are supposed to appear (every section refers to relics being expounded upon but none of them really do) but at least at a glance it seems like it'd be an obvious weak point where a lack of variation would cause repetitive gameplay.
In general, both the mapping stuff and relic design seems to presuppose that you can just keep making Stuff and gleaning variation and value from it, but from experience with previous salvage systems which had this same exact problem, they tend to be pretty much a spiraling cost that doesn't utilize their potential due to not interacting with each other.
You don't get any combinatorial explosion out of the various salvage elements because all of them are either discrete parts of a gameloop which is itself a fraction of a larger gameloop or are alternate modifiers.
Misc criticism
1.
The whole concept of towing seems really poorly thought out because the doc simultaneously specifies that the grids spawn even closer to the station than the current iteration of the magnet. I don't get why you would need to tow the thing to the station at all.
Regardless, Salvage will want to move the wreck closer to the Salvage Bay, as it will make it easier to extract materials and is necessary to complete the later steps
It says that this will make it easier, but there isn't anything specified that actually clarifies what these processes are which are made easier by being in the station.
Towing
pulling grids is fun idk what else to say yippee pew pew i'm so strong pulling shottle weee
this is only funny if you've actually presented a coherent argument for the actual thing at hand, fwiw.
2.
ok genuinely this is just the 2021 salvage doc but with extra stuff. there were a lot of things about that which didn't work (citation: the 3-5 salvage reworks since then) so i would hope that if this is basically the same thing as that but with additional bells and whistles, there would be some effort put into explaining how those issues were addressed.
From the perspective of the worker, in this current proposal, it seems to be the same answer as with all the other designs out there, where basically, salvage gets upgrades by doing their job, like the classic "mining points" that you redeem at a ticket machine for upgrades that seem to evolve in every permutation of the salvage/mining design. We even have that with the salvage job console right now ! And from the perspective of the crew, they get stuff, like materials and those relics mentionned in the proposal. Its also worth mentioning that it's explicity pointed out that the worker hording their salvage, or benefiting from them without interacting with the crew is explicitly remarked as something to avoid. So if we go by the keystone idea, as long as it follows this proposal, then the reason the crew is doing this activity is purely to fill their downtime, without material incentive, as this proposal rules it out. Otherwise, if the workers are actively getting rewards from the salvage part of the loop that they are using themselves, then it violates this proposal's design.
That is a good idea that I like, but I don't think that it fits with the rework proposed here. If we take a security officer with downtime for example, they go to the bay, put on whatever gear is necessary and do salvage work. That seems like a classic example of role abandonment. Even the reasons listed for this being a good potential keystone mechanic specifically mention that the reason its such a good idea is that these role are literally abandoning their responsibilities, which I guess can be a positive, but seems weird when that was noted as a negative for the current salvage design. It would also need a rewrite of the server rules. Especially if we are going to use this design, as it is written right now, it seems to be a gameplay loop that requires specific equipment to even interact with it (an EVA suit, space towing gear, grid separating equipement) that seems to be on par with any other dedicated role. The barrier to entry is much higher then heading to the arcade and playing an arcade game for example. The last aspect that seem important to decide is if this is going to be essential for a round or not. If its essential for a round to do this task, like getting power up, or healing patients, then a dedicated role is going to de-facto emerge, in practice it's going to be part of a captain's duty, or cargo, or whoever in engineering drew the short(or long) straw to do this task, then it's essentially recreating a job role with extra steps. If this gameplay proves very popular, and the demand for the activity outpaces the equipement available, then it even recreates roundstart jobslot limits ! If its not as essential, to the point of being optional, like playing an arcade game, drawing on the floor, or delivering mail then a dedicated role might be overkill. but calling it a keystone mechanic would also seem somewhat overkill. Maybe in this instance, cargo gets regular material shipments, or materials come from botany, and this entire gameplay loop is a fun little past time, which sounds cool honestly ! But it does sound like a whole different rework proposal. I guess I would be interested if it got a whole document written out. P.S. Now that I think about it, it might suit science to take this approach, as the entirety of the science departement is optional for a round, and all the points raised in what could make the salvage rework a good keystone are doubly true for science, with the additional bonus that the barrier to entry is much lower (one or two doodads to interact with one of science's loops) and that any scientific effort impacts everyone in the round. |
|
@EmoGarbage404 the towing is just pulling the grid into the grinders. You have some valid points but it really sounds like you should at least Playtest whatever version gets pushed as an experiment. For context, independent of this document slam is allowed to run breaksalv as an experiment on vulture for a bit. |
|
Thanks for all the feedback so far, glad to see the document is generating discussion! Let's see if I can respond to some of the critique here, there's some nuggets I think.
I think it's fair to say that it is a lengthy document (being concise is a skill I'm working on, just see this post). Where I disagree on a fundamental level is that the document only describes implementation and is not motivating its design decisions. I can't really cite a supporting example of this here because that's about half the document, so instead I will address why it approaches the design at the level it does. The reason why the document does not go deeper into what's described as the "given realities" is because, in the context of a subdepartment of the game, they are indeed seen as axiomatic. When you describe a desire to see an analysis of e.g. whether resource generation is a desirable feature to have in the game, that is a consideration that extends far into the fundamentals of how the flow of the entire game should be. Resource generation is important to facilitate interdepartment interaction and to allow limiting certain items until later in the round, and making powerful tools harder to acquire in situations where infrastructure had collapsed; this is in furtherance of promoting engaging challenges between players and to deliver the fantasy of an interconnected ecosystem that the game promises. Your claim that the failure to interrogate mechanics on this level led to previous iterations of Salvage failing is, in my opinion, incorrect. Rather, it comes from a not considering the core pillars of the game they were designed for. When something like the VGroid, expeditions and shuttle building can have a hole blown through them by simply asking "Wouldn't this just separate Salvagers completely from the rest of the station? Would this not directly go against the core gameplay we're basing our game around?", then the issue isn't the systems the game is built upon, but a failure on the part of the designers to create content in that space. Just to stress this point. I do not think the underlying systems are the issue. I do not think they are bad. Resource generation, crew interaction interplay, space navigation and hazards, PvE as a concept - while there are certainly elements that can and should be improved in these areas, as fundamental building blocks for gameplay loops I think they serve well to convey the type of game we wish to deliver. If you wish to know why I think that, it's definitely a discussion that can be had, but I've set that aside as out of scope for this job role document.
Having addressed that, why does the document contain that other half focusing on implementation? Part of it is the fact that it proposes a new gameplay loop for Salvage and to make a case for why it is meaningfully different to previous iterations, there needs to be an explanation for what is to be implemented. As seen by Tayrtahn's comment above, just the question whether wrecks should be on a timer to despawn or not is enough to raise concerns about how it will affect gameplay. And these are very valid concerns! Now I do not think everything will survive the playtesting stage remaining exactly as described in the document, and I think there is a case to be made that this doc could have the implementation separated out from it. I opted not to, because...
While I disagree with your framing, you are correct that this is not written as pure design documentation in the vein of the Core Design Pillars or the departmental design documents. It is a rework proposal. I do think it has the contents of a Salvage design document in it (most seen in the "Motivation for Salvage" section), but it is not all it contains, by design.
I agree with you partially here, but I think you are exaggerating the isolation and requirements. The main limiting factor for other players to engage with the mechanics is the smelters and magnet, but in terms of tools and just general access, BreakSalv proposes a gameplay loop that does not put up any major obstacle to participating. In terms of equipment, EVA is a fairly low barrier to clear. Ignoring emergency suits, both Engi and Sec have generally free access to hardsuits, and proper EVA is just asking HoP. While grappling hooks and separation charges are more specialized, there is no need to assume that these would be heavily restricted equipment - hell, these days clowns have a grappling hook in the form of the sticky hand. So to circle back to the smelters and magnet, these do necessitate working in the Salvage Bay. This is about the level of location-specific setup as Xenoarch, but unlike most other activities BreakSalv has a higher limit to the "too many cooks" problem. We ran the playtest with 4 players at one point with no difficulty, and the work available definitely allowed for more. Not only is pulling wrecks easier the more you are, but the Extraction step is made up of many small tasks that can be done in parallel, and Questing can be positioned as parallel tasks as well. This is worth comparing to previous iterations of Salvage which due to its isolation made it a lot more difficult to join up with Salvagers and to know the current state of their work. Why would you ever jump out to a magnet pull? It might despawn you with no warning (to you) and leave you stranded in space, and god forbid you forgot to bring a GPS or jetpack.
This is the part that I find the most validity in, as any rework or addition to the game needs to be examined through this lens. Now, as luck would have it, many of the core systems necessary are already in the game (grid spawning, tile deletion, randomized layouts etc.) and can be either directly used or modified for this. As explained in the description of this PR many of the new systems have been prototyped and tested already, and while there needs to be rewrites (as is to be expected of a prototype) that still clears the hardest hurdle of knowing what needs to be done codewise. So let's address content. There are two areas where you'll end up looking at content being designed instead of general systems: wreck grids, and relics. I think looking it's worth looking at them in the context of previous Magnet Pulls and Xenoarcheology. Xenoarch is on the far end with individual nodes of content randomized together; you have triggers and effects, with no real rhyme or reason for how they fit together but therefore allowing a great many permutations. Magnet Pulls are on the other end of being made up of static nodes, with each node (i.e. grid) having the same challenge and loot every time, allowing for bespoke designed content that also gets stale and leads to maintainance issues (especially when considering how unbalanced pulls are). BreakSalv tries to position itself somewhere in the middle. You have set core with a variation layer applied on top. A good equivalent is Expeditions and Anomalies. Expeditions had dungeongen as its core with modifiers applied on top; the main issue there imo was that dungeongen is fairly unintuitive to add new content to and the scope of a whole planet + dungeon is large (I've seen someone add a "shadow planet" downstream which was a hefty effort). Anomalies provide an interesting mix and match where the core of the APE particles and triggers are consistent, with a variation layer done via the anomaly type itself, and later the transmutations were added as a further layer. This is not nothing and will require work. For a subdepartment offering a unique niche experience, I believe it is an appropriate amount (but feel free to disagree!).
I did not wish to make a definitive statement here because I do not want to lock us out of someone showing a procgen solution suitable for this. Some contributors have posted images of impressive work and I know there are maintainers on the team who think full procgen is the way to go. I have given my own preference in the sentence right after the one you quoted which does align with your opinion.
I tried to keep the sections written such that they could stand on their own without referencing the prototype playtest, but it's hard not to let it color some parts. Pulling grids is fun. It ends up being a small puzzle; where is the grid relative to your position, how do you get it into the Salvage bay, how do you break it up if it's too large, and so on. You get to feel powerful moving these large metal hunks through space. I think I did adequately explain why towing is desirable, though maybe it's only implied through the mechanics of the Extraction section: If you are required to make multiple trips or throw things onto the station, the closer the wreck is to the station, the faster you can work. Doing this towing isn't wasted effort either as it reduces the distance you need to pull the grid during the Processing step.
I plain disagree. The 2021 Salvage Doc contains a whole lot of stuff that is being critiqued in the Background section, including how those things are supposed to be important for Salvage's progression, and I soundly reject that. While there are strong similarities in part, especially regarding Magnet Pulls (as noted in the Background section!), I do not find the contents to be equivalent. I am not including a response to the keystone proposal in this comment because I think Mot2332 already makes a good case for the benefits of having Salvage gameplay be tied to a job role, and also because I don't want to mix my thoughts on that with responding to the doc critique. I think it is an interesting proposition with merit, though I'm weighing it against expanding job tasks and improving round event progression instead. |
sowelipililimute
left a comment
sowelipililimute
left a comment
There was a problem hiding this comment.
This document is effectively incomplete in several key areas, while being long-winded and poorly organized.
We do not need an explanation of how an access-locked job area works, lists of modifiers for magnet pulls, etc.
Guidelines are introduced mid-sentence in sections meant to explain the rationale behind the document, and the core of new fundamental mechanics such as relics and questing are obfuscated in lists of what content they should have.
Do/don'ts are shown next to poorly explicated guidelines—rather than being examples that summarize long guidelines or clarify edge cases/design traps, they're often more verbose than the guidelines themselves and leave it to the reader to infer the rest of the guideline picture.
Above all else, I cannot critique a design from a poorly written document, as I don't see the design you have, I see the results and am left to infer the design from those.
Google has good resources on technical writing, which I highly recommend taking the time to study for the next revision of the document: https://developers.google.com/tech-writing
9 participants
This is a resubmission of a Salvage rework proposal of "Shipbreaker Salvage", colloquially known as BreakSalv.
It is an overhaul of the original submission #575, which was prototyped and playtested internally by staff to determine if it could be a viable redesign for Salvage. The playtests were overall received positively, so this design doc was written to tackle issues raised with the original submission and playtests, promoting further on-station gameplay while still keeping the unique EVA work that Salvage offers.
Enjoy!