4 files changed, 142 insertions(+), 139 deletions(-)

D docs/nos.md
D docs/nujel.md
A docs/plan.md
D docs/thoughts.md

@@ 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

@@ 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

@@ 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
+gamemodes.
+
+### [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.
+

@@ 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.