# Age of Mending
A game about worldbuilding, homeliness, exploration and more.

[![ContentDB](https://content.luanti.org/packages/Sumianvoice/pmb_core/shields/title/)](https://content.luanti.org/packages/Sumianvoice/pmb_core/)


# Notice
This game is partly experimental. Expect **sporadic**, game-breaking, potentially world corrupting updates to happen **indiscriminately**. Make backups. The entire design and structure of the game may change without notice depending on the direction I choose to take it.

You have been warned!

Until it reaches a final release state, you can readily assume any individual part of the game is a **placeholder** and many things will be unpolished and jank.


# What kind of game is it?
It is a game which aims to encourage and facilitate **world building**. That is, the player should feel like they want to make a world for themselves that is meaningful and engaging, such as **building towns or machines or environments**. It is a sandbox, mechanics-over-content world building game, meaning it would prefer to have a feature that allows the player to gain status effects that interact with eachother, than to have 20 different swords and 10 more mob types that are all just reskins.

The style or setting is early gunpowder era with low fantasy elements (think LoTR level magic at most). The focus is on the player **building**, exploring and defending their own **home and world**. **World building** and creating a place for yourself is what it should be best at. It is not about mining for materials or grinding for better gear, it is about constructing an immersive and meaningful place in a world.

There is a minimal amount of reward or progression. The playing of the game **_is_** the reward. The activities in the game **_are_** *the reason to play it*.


### Compatible with mte 5.8+. Other versions unknown.
Definitely doesn't work on 4.x. Always using the newest version, assume no backwards compatibility. The game may be adapted when leaving alpha to work with other versions, but for now it is too much overhead to test multiple versions every time a change is made.


# Contributing
## Bug Reports and Issues
For bug reports, use the format below and copy it into a new issue. Bug report titles should describe the problem, and suggestions should provide the affirmative future tense. Examples are (bug) "Opening storage with armor equipped causes crash" and (suggestion) "Animals will be afraid of powerful creatures".
For bug reports:

```md
## Version

VERSION_OR_GIT_TAG_OR_COMMIT_HERE

## Crash error if applicable

\```
[ERROR GOES HERE]
> remove the \ in both sets of [\```] to enable the code block
\```

## Expected behavior
- 

## Current behavior and steps to reproduce it
- 

[your description and extra details here if you want]
```


## Contributing Code
Code contributions outside the core development team are currently **not endorsed**.

If you want a feature, please make an issue instead of making a PR. This is a game designed and built mostly by a single person, **and with a very specific goal and direction in mind**. If you want to be a part of the team, please contact Sumi directly. It is very much a creative endeavour with an existing artistic direction. It *is* open source but it isn't open *development*.

The rest of this readme is mostly just info specifically for team members / contributors.


# Licenses for Contributions
By contributing code to a submodule and offering this modified version of the project in a pull request, it is taken that you offer those changes under both the project license AND the submodule's license if present. This is reflected in the statement you provide by including the license grant of permissions within the submodule itself. If a submodule has in its contents a LICENSE file or any grant of permissions, it is taken that you understand and agree to offer any changes to that submodule under that same license and grant of permissions as is contained within that submodule.

For example, if the project license is MIT, and you provide changes to a submodule which contains the 0BSD license, it is taken that you understand and agree to offer those changes under the same 0BSD license. Similarly if there is a submodule that contains an MIT license, but which lists different attribution sources / copyright notices, it is taken that you offer the changes under the submodule's MIT license and copyright notices, not just the project's.

For clarity, when making a pull request which modifies existing code (adding new modules is exempt), the body should contain a statement acknowledging the above, like so. Any such pull request not containing the below statement will be not be merged, and changes will not be viewed in order to prevent any similar future changes from being considered derivative of the PR contents.
```
For each change made to a submodule, I offer those changes under the license of the submodule the change affects, and seperately offer those changes under the project's license.
```

## Why all this trouble?
Some people believe that you can nullify a grant of permissions by "feeling" like you added changes under a different license. That is, that someone could add changes to a 0BSD licensed submodule while in their mind imagining they are offering the changes under the project's MIT license, and then sue for not attributing them under MIT for those changes to the 0BSD licensed code. This, if true (doubtful but still worth avoiding) would mean submodule licenses are lying almost all the time and are null and void, and the project is always breaking copyright by not observing the conditions of the imagined license when granting permissions under those more permissive licenses. This is to ignore the explicit grant of permissions tied to all licenses (and essentially making "takesies backsies" a legal precedent), and it's almost certainly not how it works, but it is better to document all license details and make completely impossible the idea of being sued or blackmailed, rather than be optimistic and trust in a law that is essentially just a soup made of popular opinion and feelings. If the project somehow explodes in popularity, it should be impossible for anyone, including the authors of the project itself, to exert power over the project by threat of legal action, especially through abuse of copyright law, no matter how absurd and unreasonable that possibility may seem. To this end, the above over-the-top solution is needed.


# Copyleft
If a commit contains copyleft licensed material, or any licensed material that would require use to re-license this entire project under someone else's copyright, that commit will be reverted. If in a PR it will be rejected. Developers of the project should be able to fork at any point without legal problems and use the code for any purpose.

No licenses with restrictions on use; no CC-BY-SA-NC for example. MIT, 0BSD or CC0 is preferred.
Avoid BY-SA. It is legally difficult, and no-one really knows for sure if it's copyleft or not, so just don't use it.

Free and open source. Free as in freedom, not free as in "free but you do as we tell you".


# Design Information and Guide
As a general design philosophy:
> **all player activity in the game** should contain reward which is **inherent** to the activity itself, and not injected by the designer

or:

> the reason the player wants to do X is because they want to do X, not because they want Y

> **never** intentionally add **promise of reward** for doing some activity, instead make that activity enjoyable **without reward** given

This could also be phrased as hypotheticals. There are a few levels, 1 being best:

> 1. could I do this activity for some time, then delete the world and still feel like the whole thing was enjoyable?
> 2. if I did this activity for a while, and then left it in the world and moved on to somewhere else without taking anything with me, would it still feel like it was an enjoyable time spent? (e.g. build a house and then leave)
> 3. would I open the game to do specifically this activity rather than it being just a necessary step to another thing which itself is the real goal? (e.g. mining, but you don't open the game for mining, you open it to mine only to *get better tools*)

If it fails (3) then it's not good enough. Passing (1) is best. If at any stage of playtesting we think (3) and the answer is no, we should remove or redesign whatever activity it is.

For example, solving a puzzle is fun in its own right and fits this principle, but solving a puzzle because it gives you a better item does not fit this principle.
Do not reward the player extrinsically; it should be that the playing of the game **_is_** the reward. The activities in the game **are** *the reason to play it*.



## Main Design Principles
1. Sandbox
	- every part of the game should be at least mostly optional, have multiple ways to achieve the same thing, no arbitrary goals set by the devs
	- avoid items and resources that are clearly necessary but hard to get (no cases of Terraria's rod of discord!)
2. Fun
	- design and mechanics should encourage behaviors in the player that are fun
	- don’t add things that encourage the player to do boring tasks or that encourage the game to be exploited in a boring way
	- exploiting the game in fun, fair ways = good
3. Emergent
	- features should interact due to being independent and generalized instead of specific (content vs mechanics)
	- adding something that has interactions with two other things means we get very rich gameplay possibilities just from adding one thing, because those two things each interact with two other things and so on
4. Fair
	- there should be an obvious cause --> effect, rather than random inconveniences
	- don't punish the player, but have obvious and foreseeable consequences
5. Abstracted
	- simulation should be avoided unless *absolutely necessary* for the mechanic to work (i.e. wiring is simulated, but we don’t need to simulate air pressure so we know if the player is hot and needs to drink more water - that would be oversimulated)
	- needing to drink water at all is also oversimulated
	- ask "does this make gameplay more interesting" and not from a developer standpoint but from a player's perspective



## More Design Principles
1. features should be generalised and interact with other features
	- instead of adding an arrow shooter node, add nodes which can shoot anything that’s a projectile
	- to prevent you from shooting all projectiles, allow the projectile definition to choose whether it can be shot from a node
2. specific mechanics that only have one use can be made a branching feature
	- if we have a mob in the game meant to just be a threat and nothing more, we could make it drop something useful like leather
3. the player should not be encouraged by the game to play in a boring or monotonous way
	- no grinding
4. the player should not be forced to play in a varied way
	- e.g. making a crafting recipe for a powerful item that arbitrarily makes the player need to go to every biome in the game
	- making the world varied is good, but there should not be progression tree spaghetti, nor any real progression tree at all
5. mechanics that require the player to complete more tasks should be interrogated
	- this should not be arbitrary, it should interact with other parts of the game and for a reason and be inherently enjoyable
	- example, don't add crafting recipes just to slow the player down on the way to crafting something cool, instead, make the items be interactive within the game
6. the player should not be punished by the game for wanting to do something
	- obstacles are fine, but just "making things harder" for no reason adds nothing
	- never try to prevent behavior by punishment; people can't play it "the wrong way" unless it's boring (see Main Design Principles)


# Contributors
### Sumi / [Sumianvoice](https://codeberg.org/SumianVoice)
- project direction
- game design
- systems/APIs
- world generation
- structures
- art design and direction
- textures, models, animation
- worldbuilding / lore design
- sound design, sound production, music

Made almost every gameplay feature, system, node, item, tool, biome, sound, and texture. Designed the world, the gameplay and the aesthetic. Made most of the present APIs except for a few licensed externally and a few from other earlier contributors.

### [opfromthestart](https://codeberg.org/opfromthestart)
- systems/APIs
- early groundwork

Made the first version of the mob API, implemented A\* for pathfinding, coded the first mob, introduced tools, early creative mode, and got the project actually moving when it first started.

### [cora](https://codeberg.org/cora)
Added the first weather system.

### iliekprogrammar
Got mapgen working for the first time.
