BLU->CONTD Ship Sales, from a Game Designer's perspective

Problem
Ship sales have been a longstanding pain point. Shipbuilders, and thus a lot of endgame content, is disincentivized by an unreasonable amount of effort to make 20-30 contracts to sell each individual component of a ship. It’s a pretty painful process.

Key Consideration
Until “bulk” contracts are a thing, if you make it too easy to send shipping contracts, users might inadvertently macro-send / batch-send 20-30 contracts to unrelated users, creating a spam problem.

Proposed Solution
There are 2 existing data-models to leverage in making a better experience here: contracts that work as-is, and shipyard projects that work as-is.

Blueprints are 100X easier to make than 20-30 contracts. Blueprints can easily be sent to shipyards. This means that 2 players already have a way to verify shared interest in a specific blueprint:

  • Ship buyer has the BLU applied to a Shipbuilding project.
  • Ship seller has the BLU saved.
  • When both are true, a batch-sale can be made, and 20-30 contracts can be sent without being a spam issue.

So the proposal is as follows:

  • Modify the Blueprint experience, to let players buy or sell “blueprint fulfillment” to other players.
  • This requires both players have the same Blueprint at least saved.
  • It also required the Buyer has the Blueprint started as a Shipyard project.
  • When all those conditions are true, “blueprint fulfillment” takes in a price, a contract duration, a target user, and will issue a batch of Contracts between the buyer/seller.

Proposed Buyer User Experience
Use Case: This is a user who is submitting a buy order to a shipbuilder.

  • Open BLU
  • Go to a ship blueprint you want to buy
  • At the bottom of the blueprint, observe a new hypothetical section called “Buy and Sell”
  • A dropdown defaults to “Buy”. More players will be buying ships than selling them.
  • Informational text reads: “You must have a blueprint saved and applied to a shipbuilding project in a shipyard to buy a ship’s materials from someone else.”
  • A dropdown shows all ships that meet that requirement, for you to select.
  • A text-entry box allows users to specify who they’re buying from. Player names only fill and validate if they have a matching blueprint themselves. (AKA, 2 players having the same blueprint is a safety mechanism to prevent spam).
  • A text box accepts entry for “Total Purchase Price”. Informational text relating to this box says: “Total purchase price will be evenly spread across all contracts, based on material quantities.”
  • A text box defines “Fulfillment Duration”, and it defaults to 7 days.
  • A “Send” button is below that text-entry box.

Proposed Seller User Experience

  • Open BLU
  • Go to a ship blueprint you want to buy
  • At the bottom of the blueprint, observe a new hypothetical section called “Buy and Sell”
  • A dropdown defaults to “Buy”. More players will be buying ships than selling them. Since we’re selling, toggle to “Sell”.
  • Informational text reads: “You must have a blueprint saved to sell a ship package. The buyer must have the same blueprint saved and applied to a shipbuilding project to complete the sale.”
  • A dropdown shows all ships that meet that requirement, for you to select.
  • A text-entry box allows users to specify who they’re selling to. Player names only fill and validate if they have a matching blueprint themselves.
  • A text box accepts entry for “Total Purchase Price”. Informational text relating to this box says: “Total purchase price will be evenly spread across all contracts, based on material quantities.”
  • A text box defines “Fulfillment Duration”, and it defaults to 7 days.
  • A “Send” button is below that text-entry box.

System Behavior
When executing a ship sale in this way, a loop will run on the server that creates the 20-30 necessary contracts, and batch-sends them. The purchase price of the ship is spread evenly across all the contracts, allowing for incremental purchasing. The payment & material fulfillment still happens as it currently does, so if Shipbuilders desire to collect full payment before fulfilling, that’s still possible.

More than anything, this is macro-type functionality for something players are already doing (albeit painfully).

Spam Reduction
Because the buyer must have a blueprint both saved and applied to a shipbuilding project, and the seller must have a matching blueprint, I’m estimating that the potential of a spam-issue with this approach would be minimal.

Thank you for coming to my TED Talk :smile:

1 Like

I like the idea. It certainly makes the ship buying experience easier and also a bit more realistic.

Depending on how much work is involved to implement I don’t know how highly the devs would prioritize doing this.

Here’s a thought that might simplify things and be easier to add to the game. Just add a [contributor] option to shipbuilding projects. When a buyer creates a project from his blueprint he just makes the seller (or possibly even multiple people) a contributor. Then the seller can add parts to the project directly and skip the multiple contracts step. You’ll just need one contract to handle payment.

2 Likes

I like this concept too! I imagine handling the payment assurance part, where the buyer pays and the seller supplies the parts, sounds like it might be some new parts of the data-model to build and test. But if it was less overall work, centralizing the UX around shipbuilding projects sounds ideal.

Interesting, but i don’t see it saving contracts.

When you buy a ship from GTU, its possible you will get contracts for various parts from multiple players most likely 3 - 4 of us. Although that will depend on the particular ship.

IF that was all made into a single BLU sale all the contracts would then have to be made just not to the final destination but instead to a middleman that now has to deal with all that.

A standard FTL ship is 13 contracts, unless it has custom options. Where are you getting 20 to 30 contracts from?

It takes about a minute for me to spawn, fill in, send and update our database for a contract.

There will also need to have some form build ident for the parts combo in the BLU to eliminate naming problems between players.

It also fails to take into account, parts the client may have that they wish to use in the build.

We sell many partial builds where the client has made some parts them selves.

How will it take paying NCC AIC and ICA into account for the same contract? that’s very easy currently. We accept it all at par, no need to mess with the FX.

I don’t see the problem as you do i suppose. and this solution won’t work with a group building and selling.

If your a solo seller, then you are likely NOT doing custom ships and therefore a preconfigured set of drafts would cover the sale all that would be needed is to put in a name and send it…

My suggestion is aimed at players who clearly aren’t GTU, where there’s a multitude of players building up fulfillment workflows.

You’re right to say 20-30 is an exaggeration. 16 is accurate for the ships I buy. 16 contracts to create, double-check, and send. I am a solo player, and I have multiple ships custom-built from scratch.

Having an off-platform player org like GTU is great. But for solo, small-corp, and partnership shipbuilders and buyers, a better integrated solution is necessary. “Being GTU” is not a solution.

No where in there did i say being GTU was the answer…

I was point out the major flaws i seen from my perspective

1 Like