Cargo Design Doc Proposal

[TiniestShark]

Cargo is currently in an interesting position in terms of how it relates to the station. Despite their role as the primary supplier of resources: many of its mechanics encourage it to operate on its own terms which typically creates quite a bit of friction between it and the departments its supposed to assist. It also gigantic points of failure in both the ATS and Cargo Shuttle that are frequently exploited by antags and used to shut the department down entirely. Other departments rarely have much say in how Cargo operates due to Department Economy not having many mechanics to support it, and their orders still need approval by Cargo in order to be processed. Bounties don't encourage cooperation as much as they rely on a promise that filling one out for Cargo might get you materials later if they feel it. Deliveries are poorly encouraged and typically very uninteresting to engage with.

Cargo's my favorite department because the loop absolutely can work, but it working is usually in despite how it's designed. My favorite rounds are always the ones where all of Cargo is being proactive in attempting to anticipate what other departments need, or maneuvering around dangers through alternate paths to deliver crucial resources in tight situations, or simply having to improvise after the ATS or Shuttle were sabotaged and danger immediately followed.

This is my attempt to rework Cargo into a more cooperative form to ideally promote and emphasize what really works about the department and create a more engaging back and forth with the rest of the station.

[TiniestShark]

I've also got two spreadsheets already made detailing Cargo's entire catalogue and their list of bounties. Even if my proposal is rejected, hopefully those can still be useful in some way.

[lilian-paddleston]

This doc doesn’t touch well on the ATS or the Cargo shuttle, two areas of the Cargo gameplay loop that have caused distinct concerns with cross-station accessibility and antagonism what with space gameplay. I think it would be worthwhile to cover these as part of your document.

Some parts of this document could also use touching up. What is a shipment? How are they of fixed size? How do you intend to rotate offerings? What does emergency supplies look like to you?

Go through the doc and ask yourself, “why this solution to this problem, instead of another one?” It’s a good tool to evaluate if you have justified your design, and to look frankly at your ideas.

That being said, I do like some of this document though. Good bones I think.

[Djungelskog2]

some minor issues ive thought of

1. With supplies being more limited, I think it should be mostly limited to luxury items opposed to anything beyond simple, unless the rotating shop rotates fairly often and is extremely expansive like, 1/3 of the original catalogue at any given time massive. mainly so people dont have to gamble their time or wait for specific time stamps to get what they want while still making it so that if they dont orger something in time they gotta wait another 15 minutes. I think departments not having funds for something in the store for a limited time would also be super punishing. I also think resource management boiling down to station wide chair dismantling every round would be very fun. It all just really depends on how much is in rotation and how often it rotates.
2. the variations of deliveries seem quite shallow, deliveries of multiple crates seem extremely trivial to solve, you either put them all in one crate to avoid the undescribed penalty or just use the tool provided. there isnt really a detriment to either or substantial gameplay difference that would make it any different from being a single crate. heavy/hazardous deliveries are a cool concept, especially if they have visual clarity, but its specifically the heavy ones that I take issue with because of how scarce mechs are and how easy to outright steal they are. I would suggest forklifts or mech revisions but those are whole separate, massive things.

Also, with how deliveries are reworked does this make them more akin to most 13 servers' cargo ship?

[Djungelskog2]

other than those two things though i love it

[iaada]

I have two main concerns with the doc. The first is that it relies on a lot of existing knowledge for how cargo plays, and the second is how it's straddling between a design document and a design proposal. That second part is probably just semantics but to explain myself, it's equal parts "what Cargo should be" and "how to turn it into what it should be."

Because you're defining both parts in one place, you need to spend a lot of words painting the picture. Separated, a design document can be unburdened with how to achieve its goals and focused on the ideal concept. On the other hand, A proposal can shortcut a lot of its justifications by citing design pillars and focusing on how it's an improvement over current implementations.

All said though I like the proposal part. I think limiting the market gives Cargo an urgency they lack and injects variety by surfacing unknown options. Removing the massive points of failure that constantly hamstring the department is sorely needed. Though not strongly touched on, I agree on the design that cargo should be the source of materials needed throughout the station.

[iaada]

I'd prefer a less generic name for the proposal so that we're more clear on what's being proposed.

[iaada]

This rework is intended as a foundational reinterpretation of Cargo’s gameloop

It's this line that makes me wonder why you wrote this as a proposal instead of Department Design. I feel that the design elements throughout should be in a different doc than the implementation specifics. A proposal should be about fulfilling the design document, not as an authority of the design.

[iaada]

I feel it's too specific a design to talk about jobs in a foundational document, at least not as something which certainly exists. Jobs could be removed or new jobs could be added, which would require a change to the document (and foundational documents need to be rock solid). I for one have an argument for rezoning Hydroponics as part of Cargo I've been itching to sell.

Jobs should probably be in their own document, but this all speaks to a convention for organizing the docs repo which doesn't exist.

[iaada]

Suggested change

	> IE: The Ripley is their primary form of moving heavy cargo. The Ripley is a large, unarmored mech with a thin canopy, and two large claws for holding large objects. While there is technically a Mk 2 Ripley, this would be a new version specifically made by Science. If Cargo wished to upgrade Ripley on their own, it would be the addition of scrounged materials like welded plates to increase its armor, purchased tools crudely swapped between arms and likely some degree of paint to keep its color scheme.
	\```admonish example
	The Ripley is their primary form of moving heavy cargo. The Ripley is a large, unarmored mech with a thin canopy, and two large claws for holding large objects. While there is technically a Mk 2 Ripley, this would be a new version specifically made by Science. If Cargo wished to upgrade Ripley on their own, it would be the addition of scrounged materials like welded plates to increase its armor, purchased tools crudely swapped between arms and likely some degree of paint to keep its color scheme.
	\```

(Without the slashes)

The repo has a fancier way to do a quote block you might like. You can see it and others on https://docs.spacestation14.com/en/meta/docs-example-page.html

[iaada]

This is a big ask to actually get done, but I absolutely agree it needs to happen. With the core concept of cargo being, "we have the things you want," it greatly undermines their place when people barely need them.

[iaada]

This section feels a little long. It's about just one implementation specific and spends a lot of time justifying the change. I see the merit and think it's an interesting change, but it feels more like a design pillar.

[iaada]

This section reads completely as proposal to remove the cargo shuttle and ATS, without actually saying so. It's an explanation of exactly how items are brought to the station and how to implement it. I think it would be a good change.

As a design document, it's so busy explaining the technical aspects that it has very little explanation of the player. How are players meant to interact with this design? How does this design make improvements over past pitfalls?

[iaada]

There's a lot said over what feels like a very simple statement; Deliveries should have varied challenges and varied solutions. I think you're going too in-depth on what we want players to do, and in a sense dictating a meta on how we want players to act. All we really need to say is that we want to make deliveries fun, and want to give players choices in how they make their deliveries.

[iaada]

Money feels like an unaddressed area of the design. It's the central resource of the department, but the doc assumes prior knowledge of spesos and how it all works. Money at least deserves its own section on how players use, obtain, and exchange it instead of sharing a section with bounties.

I feel it's important to be be explicit about what "Factory" style gameplay is here (or somewhere) and why we don't want it. By building a picture of bad player behavior and the designs that cause it, we have better tools to understand how to improve than we would with just a prescription solution.

[iaada]

This is just restating the current state of the game. In a Department Design I wouldn't even expect to see mail mentioned. As you say, "[mail is] a miniaturized version of Cargo’s ideal roundflow." We wouldn't need to mention mail because the document would be about describing Cargo's ideal roundflow, not implementations of it.