Retire the "design principles" doc
This document has remained unmaintained for a long time, never was truly correct, was always reactive and descriptive rather than being prescriptive, and frankly the readme does a better job of that anyway. From early on, NodeCore was always about experimentation, and just keeping what fit in and worked. This means that "design principles" have always been less about some grand underlying long- term vision, and more about just pattern recognition. NodeCore has been around long enough that the patterns are fairly evident by now. Trying to keep around a doc that is always lagging behind these patterns is not helpful.
This commit is contained in:
parent
e017229a5d
commit
a21ed2241d
@ -1,72 +0,0 @@
|
||||
========================================================================
|
||||
CORE DESIGN PRINCIPLES
|
||||
------------------------------------------------------------------------
|
||||
|
||||
0. Challenge assumptions from other games.
|
||||
- Do not blindly accept "intuition" which is actually learned.
|
||||
- Offer a unique experience, push the engine boundaries.
|
||||
1. No in-game GUIs.
|
||||
- Zero formspecs in gameplay.
|
||||
- Minimize use of HUDs; remove any standard ones feasible.
|
||||
- Player's guide only, must remain relatively isolated.
|
||||
2. Interact in node-space.
|
||||
- Everything possible should be a node.
|
||||
- Minimize use of off-grid entities.
|
||||
- Avoid encapsulating things in inventories or complex machines.
|
||||
- Crafting and transforming in-world.
|
||||
3. Focus on gameplay mechanics.
|
||||
- Focus will not be on visuals, mood, theme, storytelling.
|
||||
- Minimize elements that vary only in form, not function.
|
||||
4. Emergence from primitive elements.
|
||||
- Each node should do one job (or one part of a job).
|
||||
- Only include the most primitive, fungible components.
|
||||
- Mechanics of each element should interact with others.
|
||||
5. Puzzle challenge. No pre-hoc shortcuts.
|
||||
- Limited inventory, complex processes, environmental
|
||||
and process hazards.
|
||||
- Alternative processes must offer a new challenge compared
|
||||
to existing ones; requirements cannot be a subset.
|
||||
- Conveniences must be higher on tech tree, require some work
|
||||
to gain access.
|
||||
6. Transparency of the player character.
|
||||
- Focus is on builds and resources.
|
||||
- Player-centric mechanics like hunger and health are
|
||||
de-emphasized.
|
||||
7. Depth and subtlety.
|
||||
- Focus on quality over quantity.
|
||||
- Distinct, unique materials and mechanics instead of e.g.
|
||||
ores that mostly just vary by color.
|
||||
- Processes easy to basically solve, but leave much room
|
||||
for optimization.
|
||||
- Modeling using [piecewise] continuous functions instead
|
||||
of simple boolean expressions.
|
||||
- Wide range of process behaviors and time scales.
|
||||
8. Integrated cohesive experience.
|
||||
- Each element designed to fit with other elements.
|
||||
- Elements designed to take advantage of other existing ones
|
||||
and build longer, deeper gameplay.
|
||||
9. All core materials sustainable/renewable, focus on processes.
|
||||
- Support skyblock and other mapgen-constrained gameplay.
|
||||
- Material synthesis as an alternative to exploration.
|
||||
- No material other than time should be absolutely lossy.
|
||||
10. Mach relativity: everything should be transplantable.
|
||||
- No dependence on world elements that cannot be moved by
|
||||
the player, such as special coordinates, or mapgen biome
|
||||
parameters.
|
||||
- Only universal fine-scaled features can vary gameplay,
|
||||
such as mapblock boundaries.
|
||||
- Players should be able to detect normally-invisible features
|
||||
like mapblock boundaries.
|
||||
11. Rolling releases, early access, development transparency.
|
||||
- Everything is kept in public git repos.
|
||||
- Notes marked with spoilers as needed. Code assumed always
|
||||
to contain spoilers.
|
||||
- Frequent releases to ContentDB for players, when stable.
|
||||
- Automatic CI/CD to separate Alpha edition in ContentDB from
|
||||
latest development stream.
|
||||
12. Flexible adaptive direction.
|
||||
- Any/all of these goals are subject to change based on
|
||||
experiences or other new information.
|
||||
|
||||
........................................................................
|
||||
========================================================================
|
@ -12,9 +12,6 @@ ISSUES-DOCS: Issues related to documentation
|
||||
- Add a credits file with more extensive/specific credits, including
|
||||
non-copyrightable contributions to core project...?
|
||||
|
||||
- Design doc needs another shakedown.
|
||||
- Expecially: what has "nodecorian" come to mean?
|
||||
|
||||
- Need to clean out issues in wishlist.
|
||||
- Put some issues unlikely to be resolved on ice.
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user