Updates. Add notes file

notes.md

@@ -0,0 +1,204 @@
+# Mini-Jam 167 Submission Idea/Concept
+
+## Theme
+Cyber
+
+## Limitation
+Unknown choice from the following list:
+- Two at a time
+- Nothing is stationary
+- Interconnected world
+- Zero gravity
+- Revolving around the player
+- All at once
+- Inconsistent timing
+- No death
+- One button, two functions
+- Speed is key
+- Not as it seems
+
+
+## Concept
+A "runner" game. The player's perspective is of an endless hallway before them.
+Thematically, it's wire-frame with neon blues, and a grid behind it. The player
+is a wire-frame humanoid that is stuck to one of the four walls. As the game
+progresses, the player must align with objects in the play-field to get them.
+These objects can represent points, power-ups, and so on. The objective of the
+game is to run for as long/far as possible.
+
+### Meta: Development
+Current plan is to use the TIC-80 and Fennel.
+
+### Meta: Perspective
+The perspective of the game and player never needs to change. The world can be
+statically drawn, and the player can be dynamically positioned along any of the
+walls. Objects can be sprites that grow as they get closer. In this sense, there
+is only the object that needs to be drawn, and adjusted, as play progresses.
+
+### Design: Handling the Limitation
+
+#### Two At A Time
+The player can have two runners at a time. The Up/Down/Left/Right buttons can
+control one, while the Z/X/A/S (A/B/X/Y) buttons can control the other. Losing
+one runner doesn't lose you the game, and power-ups can restore and even protect
+the runners.
+
+#### Nothing Is Stationary
+This seems already accounted for. This is a runner game, and thus nothing is
+stationary already.
+
+#### Interconnected World
+A recursive runner. Getting to certain blockers requires diving into a deeper
+cyber-realm layer, doing a short run, which unlocks the blocker, and then
+returns you to the original layer.
+
+#### Zero Gravity
+This seems somewhat accounted for. The game world is a "cyber-realm", as as such
+has no gravity. Perhaps this could be emphasized or implement into game play
+better.
+
+#### Revolving Around The Player
+This seems already accounted for. Perhaps, instead of the player moving around
+the walls, the world rotates around the player. Otherwise, the entire game-play
+loop revolves around the player.
+
+#### All At Once
+Instead of the player moving between the various walls, there is a player
+representation on every wall. All four move at the same time. Pressing the
+corresponding directional button makes them phase or jump or otherwise avoid an
+obstacle.
+
+Alternatively, they phase by default, and pressing the corresponding directional
+button makes them "real," allowing them to collect points and objects.
+
+#### Inconsistent Timing
+Something with glitching? "A glitch in the Matrix" type thought.
+
+#### No Death
+Instead of dying, the player loses progress. Could be represented by the color
+of the world, or the speed of running.
+
+#### One Button, Two Functions
+Something with movement also being tied to specific power-ups: moving left also
+activates the left power-up, right the right one, etc.. Uses the same actual
+button.
+
+Alternatively, you have default powers, and the power-ups change them. 
+
+#### Speed Is Key
+Gotta go fast! It's a runner. The more points collected, the faster you go,
+until you reach fast enough to get to the next level or win.
+
+Alternatively: speed is _the_ key! At blockers, the player must enter in a
+quick-time key combo to unlock it, or fall back.
+
+#### Not As It Seems
+
+### Design: Including Limitations By Default
+Some of the limitations above work well together. `No Death` fits into the game
+already: instead of "dying", the player just slows down. Which then factors into
+`Speed Is Key` and `Nothing Is Stationary`. `Two At a Time` and `All At Once`
+can be game modes: you either control two runners, and use their corresponding
+face or directional button to move them; or you have 4 runners, and use the
+directional buttons to choose which ones activate or deactivate.
+
+The idea of `Interconnected Worlds` meaning mini-runners fits into any of the
+game play ideas.
+
+In fact, taking from the limitations above: the game play has
+the player trying to move fast enough to break free (`Speed Is Key`, `Nothing Is
+Stationary`). They must gather enough points to activate all four of their
+processors (`All At Once`), which they can toggle on or off to avoid hazards. At
+certain points, the individual processors may be required to complete a
+"mini-game" run, of a set length and challenge (`Interconnected Worlds` and
+possible `Inconsistent Timing`), which then fully powers up that processor. This
+could mean the player is running two different courses simultaneously (`Two At A
+Time`). The player never dies, they just slow down when they fail (`No Death`).
+
+I like the four "processor" idea. Each side of the inner square is a processor,
+and each processor charges up. Like the charge pads in F-Zero. When a pad is
+available, you need to activate the processor, and when it is not available,
+power gets drained instead. While charging, the secondary runner of the processor
+goes. Completing the secondary runner fully activates the processor. Failing the
+secondary runner reduces that processor's charge. When all four processors are
+fully activated, you win. The inner runner is just on or off. The outer runner
+is then something different, like avoiding obstacles.
+
+Oh, I have a much better presentation: each of the walls represents a processor.
+On the border of each wall is the charge level. You can activate or deactivate
+the processor, and when active it spawns a figure/sprite/representation above
+it, which then must avoid hazards and gather points. The figure can be activated
+or deactivated at any time: during certain times it will charge, but otherwise
+it will drain the processor power. 
+
+I believe the second design allows for the same `Inconsistent Timing` by having
+the "charging" times be different from the "gathering" times, and in fact having
+them completely disconnected in the logic.
+
+Another point: activating 2 or more processors simultaneously creates a link
+between them, allowing for special collection/clearing. For example, activating
+the north and south processors created an energy beam between them, allowing to
+cut special vertical slice objects and collect them. Same for east and west with
+horizontal slices. Then each of the corners could also connect. Could be that
+connecting corners takes precedence over connecting opposites, and so only `Two
+At A Time` can be active to get the special slice objects.
+
+All of this is a lot. Especially for a 72-hour game. Instead, keep it simple and
+then evolve it from there.
+
+### Development Strategy
+
+The only thing that needs to move are the objects to be collected. Start by
+drawing a simple map and drawing a simple player sprite. Then, build the logic
+for objects to spawn and grow bigger over a period of time. Maybe every 2
+seconds, double the object size. It starts as a small dot, moves to a proper
+sized sprite, maybe 4x4. Then onto a bigger sprite, either scaling the 4x4, or
+an 8x8. That might be sufficient, but one more step may also be possible. It may
+be possible to step up in different intervals as well. Start with a point, move
+to 3x3, then 5x5, then 7x7, then 9x9, then 11x11, and finish at 13x13. Creating
+the sprites won't be hard, and I can start with just a simple cross.
+
+When the sprite grows to full size, if the player sprite is in the same location
+as the sprite, increment a score. Again, no hard stuff is required, no collision
+checks. Just, on the tick, is both the player sprite and the object in the same
+spot, and if so, points.
+
+The idea is to have this be a square, but it could also be a flat surface. Given
+the resolution of the TIC-80, it may benefit to spread things out. Then again, I
+could easily pad the sides with information. I do like the idea of it not having
+any text though. Everything is represented through elements of the game board,
+so to speak.
+
+### Reveal: Limitation
+
+The limitation is "one button, two functions."
+
+## Development
+
+Considering the following:
+- The direction buttons move the "avatar"
+- The face buttons deploy the "proxy", or retrieve the "proxy"
+- The "avatar" gathers charge, and the "proxy" deploys charge.
+- The "spawner" (the rotating sprite in the middle) has a shield per quadrant. A
+  full "proxy" charge removes the shield.
+- While deployed, the "proxy" stops all projectiles down the quadrant it is in,
+  and destroys the shield over time.
+    - Note that the "proxy" does not need to destroy the shield in one go. It
+    can be destroyed over multiple deployments.
+- While deployed, the "avatar" must switch from collecting energy to avoiding
+  energy. It also cannot go into the same quadrant as the "proxy".
+- While deployed, pressing the face button of the quadrant of the deployed
+  "proxy" will retrieve it.
+
+The objective of the game is to go as far as possible. Destroying all the walls
+breaks the player into the next level, speeding up projectiles and increasing
+shield strength. Getting hit with energy slows the character down, possibly
+knocking them into a previous level.
+
+TO-DO:
+1. Fix spawning of new projectiles such that they do not spawn in quads where
+   the proxy is deployed.
+2. Update point-checking to reward projectile dodging when proxy is deployed.
+3. Add spawner walls, and logic associated with destroying them.
+4. Add level system, and logic associated with progressing and regressing.
+5. Polish! Make graphics better, add sound effects, add music!