minijam-167-runner/notes.md

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. Add level system, and logic associated with progressing and regressing.
2. Polish! Make graphics better, add sound effects, add music!

Draw the "tutorial" on the map, and progress through the information to start the game.

Show a short "death" animation (sprites 400-420 or something), the

Objective: As the RUNR gather energy from the SRC Deploy the PRXY to destroy the SRC Walls When Deployed, avoid energy or damage your AVTR

Gather: As the RUNR, move between quadrants to gather energy and charge the PRXY

Deploy: As the RUNR, deploy the PRXY to destroy the protective walls with gathered energy.

Dodge: When deployed, the PRXY can't protect your AVTR. Dodge the energy to survive!

• Setup next-level logic
• Add some sound-effects
• Add some music?
• Touch-up the game page
• Work on graphics

Handling walls differently:

• Quads table has entries for all walls, and they never leave
• Walls have a health and a stack value
• Health is always 4, stack

This works very well. Weird display issue though, looks tied to a tick check, maybe the apply damage one?

Remaining:

• Game Play
  • Increase speeds?
• Sound-effects
  • Moving
• Music
  • Menus
  • Game
• Graphics
  • Background rectangles aligned to game window
  • Energy movement alignment and timing
  • Deployed + Shooting reverse projectile?
    • Could have bullet and wall hit
• Meta