The core mechanic and central pillar of OpenEVA gameplay is the concept of Equipment. The main interaction the player has with the game will be using their Resources to acquire and maintain Equipment. The Equipment system will be the main outlet of player choice, creativity and ingenuity. Every tangible in game object will be represented as Equipment. All gameplay will revolve around the players inventory of Equipment and all Events, Contracts and economy will involve Equipment in some way. The Equipment system will be the most complex and important system in OpenEVA, however it will be relatively simple at its heart. My goal is to create an infrastructure in which content designers can easily create detailed and complex systems and interactions, enabling emergent gameplay and narratives.
Conceptually, Equipment in the game is represented as a hierarchical structure of Components and their constituent Parts and Resources. Equipment can be any vehicle, machine, tool, crew member, EVA suit, building, robot, space station, satellite, gym membership, magic ring of power, pet, or any other object or item that content creators can imagine. Events and Contracts may be gated or triggered by the state of the player’s Equipment inventory. Certain pieces of Equipment may start an Event chains, Contracts will require specific Equipment, crew or the player character themselves may be represented as Equipment. Equipment may store, consume or produce Resources or enable the fabrication and maintenance of Parts, Components and Equipment. The player will spend time and Resources maintaining, improving, constructing and customizing their Equipment.
The modular function, utility and physical structure of Equipment will be represented through Components. Equipment will exist as a collection of Components which each have their own function or utility. Like Equipment themselves, Components will gate and trigger Events, consume Resources, enable the production and fabrication of Equipment, Components, Parts and Resources, and will require maintenance, improvement and customization.
The player’s spaceship may include Resource generation and storage Components, fabrication, hull, shielding and physical structure Components, propulsion and reaction control systems, computer systems and AI software, storage and cargo Components, life support, living space, and more. Conceptually Components can be any functional or physically distinct element of a piece of Equipment.
Components are constructed from collections of interchangeable Parts. Parts themselves may be collections of Parts of their own. Parts have no functional utility on their own, however they still may gate and trigger Contracts, Events and other content and must be maintained, improved and customized. Parts are the elements of Equipment which become worn; Conditions of Equipment, Components and Parts are a product of the conditions of their constituent Parts. The game will simply track and change the conditions of the lowest level parts and status will flow to the top of the hierarchy. Parts may become damaged during Events, Contracts or through general use. Once a threshold of damage has been reach the part will be considered failed and it’s parent Parts and Components may fail as a result. Parts may be fabricated, repaired, purchased, sold, and replaced by the player individually or as part of a larger part structure.
An example of a simple keyboard switch Part may be comprised of a plastic case Part, plastic plunger and slider Parts, an aluminium or steel spring and copper, gold or steel electrical contact Parts.
Certain parts may be marked as vital to the operation of a Component or Equipment. If an important part fails it will disable the Component or Equipment it is attached to. Likewise Parts and Components may be dependent on other Parts, Components, Equipment or Resources. This will allow for designers to create complex dependency and failure chains and facilitate emergent behaviour.
Equipment and Components in the player’s inventory enable them to fabricate, customize and maintain virtually any Part, Component or Equipment available. However I would like to model proprietary, atomic and intangible Parts and Equipment, hacking and unauthorized modification, software, services, NPCs and player character via Equipment as well. Access to the Part hierarchy of Parts and Equipment may be gated by access to specialized Equipment, Components, Events or specific conditions. Locked Parts and Equipment will not reveal their part hierarchy, and the player will need to replace the Part or Equipment entirely when it becomes damaged. If the player attains the ability to unlock the part, the part hierarchy is revealed, and the player will be free to repair, modify or customize the item. Also, Equipment, Parts and Components have a compatibility matrix. Certain Parts can only be installed in specific Equipment and visa-versa.
Parts require Resources to repair and Maintain, and Components may require Resources to operate. Repairs, fabrication and construction will take in-game time to complete. Equipment and Resources require cargo space and storage facilities. The player will buy and sell Equipment for Resources, and attain or lose equipment through Events and Contracts. Parts have varying durability or efficiency based on the material and quality of construction. The player will use Components and Equipment to store, consume and produce Resources. Equipment will be central to OpenEVA’s economy and the main way the player will manage Resources.
I imagine the interface to be arranged with the player’s inventory as a list of their Equipment and a short summary of each piece’s operational status, condition, total Resource levels and production/consumption. Selecting a piece of Equipment will expand a list of it’s Components with summaries of their status, condition and Resources. Selecting Components and Parts will further expand the Part hierarchies. At any level of the hierarchy the player can choose to toggle, operate, repair, replace, remove or add Parts and Components by selecting them and choosing from a set of contextual actions.
Designers will be able to define Equipment, Component and Part templates. The definitions will determine the Equipment or Part’s structure, utilities, Resources, Events, Contracts, compatibility and more. Using clever definitions of Equipment, Resources and Events the designer should be able to model any number of systems, interactions and economies in game.
This is still a rather high level design of the Equipment system. At the low level Equipment, Components and Parts are functionally identical. Components are simply Parts with some utility and Equipment simply are stand alone Components. There is no reason not to allow the player to construct our keyboard switch Part as a fully realized piece of Equipment. In fact I want to encourage this kind of emergent creativity and ingenuity. Likewise there is no reason that functional Components should be constrained to the top level hierarchy. Part functionality and status need simply flow upward so at each level the player has a concise summary of the condition, status and economy of the Parts below. Finally, parts and equipment should be able to be represented as Resources; Hundreds of loose keyboard switches, or an army of robots will be easier to manage and more efficient if they can be represented as a simple integer value. I intend to write up a low level technical design spec for Equipment and every system in OpenEVA. I will likely update this post as the conceptual design of the Equipment system matures. Stay tuned for more.