SFEOS Game Design (Part 4 - Drilling Down into the MVP)
If you are not already aware, SFEOS will be an open source turn based game being built to eventually run within the EOS blockchain. The game itself will not be owned or operated by a game studio. Instead a DAC (Distributed Autonomous Community) of players will vote to use the self funding budget to continue it's development beyond what we are providing to get things rolling. EOS is a platform for developing distributed apps (Dapps) and promises to create tools to help traditional web developers build blockchain apps. Games such as SFEOS will be stress free ways for people to build mental models around things they might not fully grasp right away. This game will allow for a very low barrier of entry for people to enter into the Crypto world, and also allow players to learn the concepts of smart contracts, distributed apps, and distributed autonomous communities. You can read more about my thoughts on EOS here, and follow their announcements at @eosio. Being an open source game allows us to collaborate with some amazing communities on Steemit. One such community of crypto artists is @slothicorn. Together with the great artists over there, we are committed to the gift economy that we feel will become more prevalent in the future, as more and more people understand the potential available to us in this new paradigm. Now to the article...
Part 1 - From Blue-Sky to Spreadsheet Specific
Part 2 - The Grand Idea
Part 3 - Breaking Down the Core Game Loop into Nouns and Verbs
Part 4 - Drilling Down into the MVP - You are here...
Systems and Loops for the MVP
The focus and context of this post is all about designing the MVP of the early game. It consists of me thinking deeper about what the systems and loops of the MVP will look like. I'm looking for input here, so feel free to comment about anything I've missed, or if you feel I'm getting too far into the weeds for the initial MVP let me know.
Starting with The Ship
From a player's perspective, their interaction with the game revolves around the ship and their connection to the ship's AIs. Without a ship there are no real actions a player can do.
Player Feedback Loop
The ship AI (or game UI) reports information to the player: Where they are and the adjacent nodes of space. It lists how many actions are left and how much real-time time remains to make use of those actions. It lists the holds and their contents as well as any refining or production going on. It will also list the crew and any crew logs the captain might need to know about. In the future version it will also list all the interactions they have with other players, such as communications, trades and team action results.
Actions
Each real-time 24 hour period, a player has a limited number of actions. Let's just assume the limit is 100 actions for now. We will learn more when we can start testing things out. So based on their remaining action count they can choose to do pretty much whatever they want to do from the list of available actions.
Scanning
Scanning might be one of the most important things a player can do in the game (and I realize I have not mentioned it until now). It wouldn't actually be necessary for the MVP, but I'm concerned that it will be such a large part of the game, we should be testing it right out of the gate. Without it, the player is literally flying blind. The player is only aware of what is directly adjacent to them or the data they have from previous travel through those nodes (sectors) without scanning. Even if they did travel through the sectors previously, the information about the sector will be out of date and space in the game, is not a static place.
Depending on the level of the ship's scanner, the player can scan down a path of connected nodes. If they know about the nodes they are scanning they can direct the path the scanning will take. If they do not know about the nodes, the scanner will follow a semi-directed path or totally random path, depending on how the player programs the sweep. Having the scanning take a path is partially inspired by @rubenalexander's idea about sending probes out from the ship and upon their return they might show cool findings. We can discuss the awesome ideas of what probes might do after the MVP.
The scan, if successful, will reveal other nodes, what is in the nodes (ports, resources, etc) and update the ship's maps with the latest data. In later versions, these scans will include the warp signatures of other ships along with any active beacons from others players, and players will be able to share map information with each other.
| Scan | Inputs: target node to start the scan from; type of scan (direction or random) |
Traveling To / Through Sectors (i.e. Nodes)
A "Jump" is when a player warps from one sector to another. It simply moves the ship's current location. When in a sector, a player can interact with any Interactable things present (ports, planets, resources, etc.). These will simply be available actions to choose from. Players can choose to travel through many sectors at one time. It will still cost actions to get through each sector, but from a player's perspective they will simply warp directly to the target sector. When warping is used in this way, scanning does not automatically take place. Instead a "blip" or "blips" might show up letting the player know something was there, but not what that something was. When warping multiple sectors at once, the players are limited to the number of sectors remaining in their "Remaining Action Count" and once they arrive at the location they will not be able to do any other actions if they have used them all, until the action count is reset at the end of the current 24 hour real-time period.
| Jump or Warp | Input: target adjacent sector or a known sector far away |
Mining Resources, Refining and Production
Some nodes will reveal resource stores. These might include gas clouds, asteroids with minerals, suns, moons, planets, etc. Most resources will be limited. Some resources will not be limited and we will have to build in appropriate outflows to handle resource inflation. Players will mine resources by using mining drones. I can envision a tech tree of mining drones but I'm not sure how complex we want to make this. I'm not yet sure what will be considered fun for the players.
Some resources will probably need to be refined in order to be used in production. Production will use recipes to turn the ingredient resources into new resources. Production might also create waste that will eventually need to be dealt with.
| Mine | Input: resource target |
Ports: Bulk Refining and Production, Ship Upgrades and Resource Trading
Ports will be an important part of the game. They are hubs of activity. Instead of refining and producing on the ship in a limited capacity, ports can be used to do higher volume for less action costs. Once the correct resources are owned, they can be used to create ship upgrades. These upgrades are done at the ports. Trading will also happen at the ports. In this early version trading will not be live with other players. It will be done through a preset simple AI just to get a feel of how things will work.
| Refine Resources | Input: Resources to Refine |
| Production (Crafting) | Input: Recipe Ingredients |
| Action: Upgrade Ship | Input: Upgrade Type; Recipe Ingredients |
| Buy / Sell | Input: Resources to Buy or Sell |
In closing I'd like to personally thank @alexandravart, @rubenalexander and @elohprojects for their work in helping to bring this game to life. Many others have shown a lot of interest and together it can become a reality. Thank you...