fac944f4f24973782e649c8c11747ed64accf4c5 — Ben (Win10) 1 year, 5 months ago 50023d5 feature/item-system
4 files changed, 142 insertions(+), 139 deletions(-)

D docs/nos.md
D docs/nujel.md
A docs/plan.md
D docs/thoughts.md
D docs/nos.md => docs/nos.md +0 -33
@@ 1,33 0,0 @@
# Just a list of things this game will NOT have:

- No Winning / Ending
Players can just play in their world for as long as they please, of course, there
are many  ways to loose :)

- No Mining / Spelunking
Players should not have to spend hours just holding down their left mouse button
in search for some rare Materials. Instead, rare items should be rare because they
require a lot of skill to acquire, not just pure chance.

- No Factories / Redstone
While building Factories/Redstone circuits is quite fun, there are a lot of other
Games out there that are a lot better at it than what I might produce.

- No Dialogue / In-Game writings (Environmental storytelling only)
This is mostly because I want to focus on procedural generation, which makes
classical storytelling quite a bit harder to pull off.

- No Worldfreeze when no player is around (only if no "living" thing is around due to technical limitations)
The world should just keep on turning, even if no player is around to witness it.
For the sake of performance a lot of the world needs to be frozen to disk though,
although I will try an experiment with ways to still have some things happen in
those frozen chunks.

- No Weapon Durability
This is just not a fun mechanic and takes away some of the fun of acquiring fancy
new equipment since you can't just start using that nice item for the fear of
wearing it down too soon. I saw this in a lot of Minecraft games where players
would just mine using Stone Pickaxes because they wanted to save the Ingots/Diamonds.

- No Fasttravel
Instead thought should be put into making traveling an enjoyable experience.
\ No newline at end of file

D docs/nujel.md => docs/nujel.md +0 -96
@@ 1,96 0,0 @@
# Nujel

## Overview
The Scheme inspired programming language powering many parts of this game. While
Scheme was a heavy influence, it is by no means compatible to any Scheme standard.
This is mostly because Nujel is not intended to be a general-purpose language,
instead it's only objective is to be the way to describe WolkenWelten gameplay
modes, and in all other areas where a more high-level/abstract language would
make things easier than C. Additionally there is no great plan, the language will
be changed all the time to make it better suited for its task. Though some things
are already quite clear and are very unlikely to change, I will focus on some of
these below.

### Nujel is interpreted
This has multiple reasons, the most important one that JITs are hard to program,
and make porting to new Architectures a lot harder, especially to platforms like
WASM. Additionally all perfomance critical code should be written in C, with
Nujel mostly acting as some sort of glue layer. Although it would be nice if
Nujel became one of the faster interpreters, right now it is slow, super SLOW.

### Nujel has no exceptions/errors
For example `[/ 4 0]` returns #inf instead of throwing an exception. Or trying
to resolve an unknown symbol just returns the symbol instead. Whatevery the case
the Interpreter is not allowed to at any point throw an exception, even if the
interpreter runs out of memory it just starts returning #nil instead. This is
mostly because I would like to experiment with randomly mutating behavioral code,
and it would be kind of a bummer if most of these would just end in the bunny
generating Floaing Point Exceptions.

### Nujel uses brackets
This is mostly because of the standard keyboard most of us use, where typing a
parenthesis requires holding down shift and 9/0, whereas you can type brackets
directly. Although parenthesis and brackets are totaly interchageable, brackets
are still preferred.

### Nujel can do infix evaluation
The LISP way of writing things is just not something that many people are
accustomed to, so in order to make it easier to start writing Nujel you can just
write something like `[display [1 + 2 * (3 + 4)]]` and get the expected results
back. Operator precedence is also the way you would expect it to be.

### Nujel has no I/O by default
This is because Nujel will run untrusted code, and having it be able to just do
I/O would be horrible from a security standpoint, especially considering that on
joining a server the client receives and Evaluates whatever code the server
sends (which should just describe the items and general gameplay stuff, but in
the end might be whatever the server operator decides it to be).

### Nujel has an extensive testsuite
Every single test gets bundled into every single Nujel interpreter, which might
even add tests specific to that context. This should help in decreasing the
amount of accidental breakage making it into commits. Every new Nujel feature
should start as a couple of testcases describing expected behaviour.

## Future Direction
Now in the future there are a couple of things that need to be changed in order
to progress further.

Nujel still needs continuations and a proper event loop that is able to handle
thousands of coroutines. The design will mostly be based on JS and the way it
does promises/async/await but with one difference, namely that await would be
the default and the programmer has to specify if something should happen in
parallel. This should make programming quite a bit easier since one can just
write normal blocking code but still have the benefits of lightweight coroutines.

In addition to that Nujel needs a way to limit the amount of operations that a
function can do before returning a continuation upwards. This is mostly because
we only have a limited amount of time before the next frame needs to be rendered
and we might need to keep the continuation around until next frame where we can
then hopefully finish it. Additionally since we run untrusted code we need to be
able to run infinite loops without the game crashing, this is probably best
implemented by limiting the amount of operations animals can do in their AI and
also having the actual amount of operations done decrement the animals hunger/energy
level which will hopefully result in evolutionary pressure keeping complexity down
(and that would also result in the quick removal of animals with an infinite loop
in their behavioural code). This can also be used to profile code (just run a
function for X operations and see in which functions it currently is), or to
debug/single-step through code (just run for 1 operation and the have it return
a continuation). This same system should also be able to limit the amount of
values a function may allocate, since memory is finite as well.

And most importantly, Nujel needs to be able to run it's GC while it is evaluating
something, this is a massive limitation right now but should be fixed with the
work needed for supporting continuations as well.

Not much effort should be spent on adding support to third-party tools apart from
an Emacs major mode, mostly because the best way to write Nujel should be within
Nujel so the most work should be put into making this experience the best there is.

## Tutorials
A couple of tutorials introducing the language is essential, but not a priority
right now since everything is still in flux. Once the language has stabilized
and continuations/limits are implemented a series of interactive in-game tutorials
will be written inteded for everyone 9-99, not just seasoned programmers.
\ No newline at end of file

A docs/plan.md => docs/plan.md +142 -0
@@ 0,0 1,142 @@
This document serves to guide the development effor in a way that prioritizes gameplay
and extending the underlying runtime only as necessary.

I am trying to list things in an order that they should probably be developed in, although
the exact order is not that important.

# Legend

## [GM] = Gamemode
A Gamemode is technically just a module, although it will be treated slightly
different by the UI since a player has to choose a particular Gamemode.

## [MOD] = Module
Modules by themselves should be as small as possible and import other modules
in order to provide complex functionality.

## [C] = C Functionality
Something that the engine needs to implement and expose to Nujel in some (hopefully) sensible way.

## [NUJ] = Nujel Functionality
Something that Nujel needs to provide by that point

# Milestones

## [NUJ] - Module system
Nothing fancy, might in the beginning actually suffice to just load and evaluate a certain
file in an empty environment.

# [GM] - Creative/Development Mode
This gamemode should probably be the first one added, since it also serves as a
sort of map builder which will probably come in handy for other subsequent

### [C] - Blocktype getter
Functionality is mostly there, just not exposed to Nujel.  Should be quite simple to provide.

## [MOD] - Blockbreaker
This mod should allow a player to immediatly remove a block from the world as a primary action.

## [MOD] - Blockbuilder
This mod should give a player the ability to freely choose from all blocktypes currently known
to the game and place them via a right-click.

## [MOD] - Blockchooser
This mod should provide a simple window when pressing the inventory key and show a nice grid
of all known blocks.

### [NUJ] - Bytevectors / SRFI-4
Nujel needs a way to store (and manipulate) bytevectors and transform them from/to strings/arrays.

### [NUJ] - LZ4 (de-)compression
Since WW already includes LZ4 we should do the same for nujel and allow usage on all SRFI-4 vectors

### [NUJ] - Binary reader macro
We need a way to efficiently encode binary data within S-Expressions, mostly to encode chunks but also for
other data like Textures, Models, Chunks, SFX and probably much more.  We need to also test if base64 would
actually be more efficient than hex, since we will probably never send/store these s-expressions uncompressed and
Hex might compress slightly better (as well as being simpler to en-/decode)

## [MOD] - Chunk import/export
A way to import/export a particular chunk and serialize in into an LZ4 compressed S-Expression.

### [C] - Blocktype setter
Functionality is mostly there, just not exposed to Nujel.

## [MOD] - Default Blocks
Should import a set of simple and general blocks which will probably be useful to pretty much every gamemode out there, block like
grass, dirt, stone and so on, basically whatever blockTypes are currently in the game, although the snowy ones can probably be removed.

## [MOD] - Chunky files
A format for storing blockdata, along with palette information mapping bytes to symbolic blockIDs. Plugins used may be stored but should not be loaded automatically, instead an exception should be thrown and the import cancelled.  This is so that we may migrate over to a newer/different version of a plugin with everything working so long that we have a blockType associated with a particular symbol.

### [C] - Worldgen
Make the entire worldgen process defined via Nujel, although the current algorhithm should be provided to Nujel so that we can provide
a very simple pass-through worldgen that just calls back into the old worldgen code.  Will be chungus based in the beginning, but in the
long run there needs to be some better structure.

### [C] - Weather-/Cloudcontrol
Weather and Clouds need to be controlled via Nujel since they don't make sense for all Gamemodes.

## [MOD] - Static chunks
A worldgen mod that just inserts a static chunk whenever it is called. Should allow for a sort of copy/pasting of blockdata.

### [C] - Grappling Hook
Grappling hook must be controlled from within Nujel

### [C] - Glider
Glider must be controlled from within Nujel

### [C] - Jetpack
Jetpack must be controlled from within Nujel

### [C] - Health
Health, mostly maximum Health, must be controlled from within Nujel. Damage would be nice but not necessary in the beginning.

### [C] - Knockback multiplier
We need a way to specify a knockback multiplier that is universally supported

### [C] - Respawn
Respawning (like a delay or something) and especially respawn location needs to be controlled via Nujel

### [C] - Entity collisions / Item Pickups
No itemsystem, but instead just a way of placing entities with a specific mesh, maybe even adding some sort of rotation animation and calling a callback (A) After a specific amount of time and (B) On collision/pickup by a player

## [MOD] - Air Gun
Should move all entities in front of it far away

## [MOD] - Baseball Bat
Should damage and knockback whatever it hits

## [MOD] - Rocket launcher
Pretty self explanatory

## [C] - Persistence
Persistence should be controlled via Nujel, mostly turning it off for Gamemodes where that doesn't make sense

### [C] - Player speed multiplier
Player speed should be modifiable via Nujel, so we can slow down or speed up players as needed.

## [C] - Gamemodes
Actually support for gamemodes, where a player actually switches to the gamemode required by the server. Does not need
to be loaded automatically from the server in the beginning, although it should be kept in mind while implementing.

# [GM] - Trümmerei
The first real Gamemode, an arena-shooter where just like in smash instead of damaging the other players you instead increase a knockback multiplier. Players should start with pretty much nothing and then have to run around the (static) map picking up various items/weapons as well as useful items like grappling hooks, gliders or seven-league boots

### [C] - Player models
We need to provide a couple of player models and let players decide which they want to use.

### [C] - Models / Textures / (Mesh)objects
Models need to be compiled into the client for now, it would be much more convenient if they could be provided by Nujel, meaning that they could be provided by Modules and soon the server.

### [C] - Multijump
Would be expose some sort of multi jump ability via Nujel, or at least enable its implementation in Nujel

## [MOD] - Mapchange
Should provide a convenient way to change a "map"

## [MOD] - Maprotate
Should provide a way to automatically rotate between a preselection of maps.

D docs/thoughts.md => docs/thoughts.md +0 -10
@@ 1,10 0,0 @@
- NPCs? Maybe something like Terraria where one controls a "town"
Since every block can be changed enabling players to build houses, plazas and whole towns it could
be nice to nudge players into building a town since without npcs living in those houses and offering services
building towns could/would be seen as a waste from a pure gameplay perspective

- Fancy Grass "Blocks" / Crops?
For once they do quite a lot to reduce the blocky appearance, although this
would mean more code in the renderpath. How could farming crops be rendered apart from
angled billboards? 3D Models would be quite a bit of work for every crop although giving much more freedom whilst
most probably destroying performance without massive optimization work. Needs some more thought for now.