Some really good refactoring happening in here

4 files changed, 116 insertions, 0 deletions

diff --git a/docs/bugs.txt b/docs/bugs.txt
new file mode 100644
index 0000000..e65b3ca
--- /dev/null
+++ b/docs/bugs.txt
@@ -0,0 +1,3 @@
+Clipping into a solid gives double height:
+
+Jumping into a solid from the side has weird interactions. First, I can hold the direction where the vector goes into the solid and jump, and I'll get a "double jump", probably because the jump resets immediately on top collision. ~/Desktop/dyl-bugs/jump-into-solid.mov.
diff --git a/docs/design.txt b/docs/design.txt
new file mode 100644
index 0000000..d0926ad
--- /dev/null
+++ b/docs/design.txt
@@ -0,0 +1,87 @@
+===
+Don't You Leave (really draft)
+===
+
+This is a game inspired by A Dark Room. The game is (probably) a crafting, RTS-inspired, roguelike. A run is ~50 minutes.
+
+Your main goal is to keep a fire, whose fuel is cash, warm for your wife. As the fire grows in size, other civilians start to base around the flame. These do nothing but stay next to your fire and run away if they get too cold, but you can click on them to "assign" them a job.
+
+Your fire increasingly needs more fuel as it grows in size. To gain more money you need to kill more and more players / pillage civilizations. You're forced to continue coming back to the fire by the fact that you need to refill the storage of fuel to store for the fire.
+
+Other civilizations' civilians are parts of armies. But in your civilization, all civilians are "pacifists". They die if they die; they don't fight back. It is fully on you to take entire armies - those attacking and which you attack. As you kill more and more others, your wife becomes increasingly more and more dissatisfied.
+
+There are two ways to lose:
+- You die
+- Your wife dies. You kill yourself. Loss text: "You couldn't protect her. Try again?"
+
+Other "players" are constantly coming to your civilization to kill your wife.
+
+The main notification system of the game is the edges of the screen and your wife's heartbeat. It gets slower.
+- Text in a marquee style "chilly" -> "cold" -> "icy" -> "hypothermic", as ice increasingly becomes opaque, takes over the edges of the screen.
+- Depending on the distance to the nearest enemy, "uncomfortable" -> "scared" -> "fear" -> "terror" with purple edges.
+
+The game ends when all other civiliazations. At that point, all your civilians will battle against you. Once you kill all of them, your wife becomes the final boss, and it's the hardest. When you kill her, you get infinite money but "You couldn't protect her. Try again?" but instead of a sad ending it's happy because you made so much money!
+
+===Crafting===
+
+There are resources which you need to collect to make weapons. Cash is the base resource, which is the fuel which goes to your fire that is piped into factories around the fire and stuff.
+
+- Wood (for sticks)
+- Magic emerald (for staff)
+- Iron (for swords,
+- Oil (for your car)
+
+===Exploration===
+
+You need to monitor your hunger and thirst when traveling. There are wells, abandoned farms, (tbd) oracles to visit and include into your inventory.
+
+Depending on the radius to your little settlement is how advanced the civilization is; mostly just due to the fact they've had time to develop (THIS WILL REQUIRE A GOOD BIT OF ARTIFICIAL INTELLIGENCE TO CRAFT I BELIEVE).
+
+You start with just a small pack to bring back things to craft with. But you can craft larger things to bring back larger / more items as you explore. This is justified by items' weight.
+
+===Combat===
+
+You start from just your fists. (TODO) You can pick up a rock and punch down a tree.
+
+There are a few main "classes" to spec into.
+Magic
+Military
+Science
+
+Strategy manifests in maintaining the order of upgrades you choose to stay ahead of the threat. For instance, a distant civilization that is really really advanced in science might take less precidence over a medium advanced military civilization close by attacking soon.
+
+The Oracles are key to your combat experiences. There are a few oracles. It marks on your map the positions of civilizations and when they plan on attacking (or just "rumors"). But it doesn't reveal what kind of civilization (magic, military, science, etc.) it is. Thus, you need to go scout the attackers to see what you need to plan / gather for.
+
+The actual combat will be driven by using your grappling hook to swing around and dodge enemies by grappling onto
+ledges or trees?
+
+===Game===
+
+
+The game starts out in a cave. You have to fight through the levels of the cave to get to the floor below the overworld.
+You have to get basic tools from fighting skeletons, etc. The cave should have 1 - 3 other players. If you don't kill them,
+they have the chance of getting to your wife and killing her. This gives the player the incentive to explore the entire
+cave system to kill each.
+
+Once you find the path to the overworld you can place a fire down to start attracting other players. You want to protect
+the entrance to the cave for obvious reasons.
+
+=== Terrain ===
+
+The game is front-facing, like paper mario. This is essential to giving the combat mechanics "height" that I think would
+be hard to represent in a top-down game like stardew valley.
+But there are "forks" in the road, so to speak. I imagine that these forks would be dithered or otherwise not visible.
+And the forks go up or down.
+
+This gives the world a little bit of "depth".
+
+             _______
+            /  |
+           /   |
+---------S     | (height difference is two screens' worth
+           \   |
+            \_______
+
+Something I still need to decide on is how the camera will work. Is every chunk of the game a
+room like mega man? Or is it like Terraria where the camera centers on the player and chunks
+feel seemless? The former is probably easier generation-wise etc.
diff --git a/docs/input.txt b/docs/input.txt
new file mode 100644
index 0000000..d5bc1a7
--- /dev/null
+++ b/docs/input.txt
@@ -0,0 +1,18 @@
+Entities will have an ActionQueue component. The ActionQueue is a set of actions and durations within which those
+actions may be applied. This will solve the issue of buffering inputs as well as having multiple systems control which
+actions an entity might take (for a future AI system, perhaps?).
+
+Let's introduce the jumping mechanics of this game as an example of the system interaction with entities.
+
+When the player presses a key mapped to a Jumping action, a Jump action is queued and expires in 80 milliseconds.
+The JumpSystem consumes the action if the entity is able to "physically" jump:
+- it is in contact with a solid underneath and has zero velocity on the y axis (?) and there is no current Jump component
+- or, there is a Jump component but the "availableJump" counter is greater than zero (it is decremented on consumption
+  of the Jump action), to account for the future of a double jump being possible.
+
+If the JumpSystem does not consume() the action within the allotted 80 milliseconds, the action expires and is removed
+from the queue.
+
+The queue is an action-singleton queue. Meaning, enqueueing an action has the effect of replacing any action of the same
+type whose expiration is earlier than the enqueued action.
+
diff --git a/docs/todo.txt b/docs/todo.txt
new file mode 100644
index 0000000..023868e
--- /dev/null
+++ b/docs/todo.txt
@@ -0,0 +1,8 @@
+Terrain:
+- [ ] Basic platforming
+- [ ] First dungeon
+- [ ] First overworld attempt
+
+Combat:
+- [ ] Basic enemy
+- [ ] Separate solid collision bounding box and damageable collision bounding box. Perhaps even different systems?