These are the steps we need to take in order to complete a proof of concept for the game.

Main Topics

• [x] Characters can move left/right
• [x] Characters can jump
• [x] Characters can bonk
• [x] Characters can respawn
• [x] Characters are drawn using art assets

Characters can move left/right

• [x] Add the characters to the physics system & store their handles in components
• [x] Add a ground plane or other surface.
• [x] Add ability for ground plane to block characters.
• [x] Players positions are affected by input velocity.

Characters can Jump

• [x] Create a player state enum, for tracking grounded, jumping, etc
• [x] Inside of check input_system if the user presses a button & they are grounded,
• [x] If ok, give them some vertical velocity.
• [x] Update the enum to the jumping state.

Characters can bonk

• [x] Check for collisions between players
• [x] If a player is above (self.y > other.y) another & their velocity is downards, bonk em

Characters can respawn

• [x] Any player who is bonk'ed is respawned at a random position within the play area.
• [x] Reset any related physics things.

Characters are drawn using art assets

• [x] Import the art assets, generate palettes, as necessary
• [x] Convert them to the Gamercade sprite format using the editor
• [x] Set player images to these sprites & draw them

Related to #4 and #2

Currently, we are using the (very awesome) crate Rapier.rs for our physics and collision logic. It's an extremely full-featured create, intended for more general physics simulations.

I wonder if this is overkill for the simplistic and arcade-y nature of the game. For example, some conversions need to be made between "pixel/screen space" and "physics space" when drawing the characters. We also need to constantly juggle between the concept of real physics for numerical values like gravity (represented in meters / second), character sizes (also represented ni meters), and the character sizes which... are probably only a few centimers tall 😂

There's an argument for moving to a much more simpler physics system, something faster, simple, pixel driven, which can be much easier to reason about and not require serious mathematics knowledge to use. Also, generally character controllers are going to be kinematic bodies anyway, so we lose much of the features from Rapier anyway, because we are updating the locations of our players through code and not through the phyics engine.

This article aboute Celeste & Towerfalls Physics is a great example. Macroquad also has a similar macroquad-platformer crate which is also based on the Celeste & Towerfall article and may be applicable here. Jumpy, another Spicy Lobster game, has a quite minimal physics example here.

Does anyone have suggestions as to why we should keep things the way they are? Or does it seem like moving to a simpler physics solution seem more beneficial in the long run?

Due to using kinematic movement, the characters penetrate through the ground when colliding.

This shouldnt happen, we can probably set the location by modifying the collision response code and setting the player to the top of the AABB.

Currently, we only draw a single color background (the clear color :D)

We should have a static background image! This shouldn't be too hard to do with the following outline:

• [ ] Get a background art asset (should be the same size as the game's resolution). Should be limited to 64 colors due to palette limitations.
• [ ] Import said image into the editor as a new sprite sheet & sprite
• [ ] Remove the call to clear_screen and replace it with...
• [ ] Draw the background image! Before players of course

It would be great to have a tile-based map system, similar to other retro games from the time.

I could see this as simply defining an enum type for tiles, something like None, Floor to start with and then figure out how to do more interesting maps later, like decorative tiles

And then for rendering, we can just loop through the whole list and render them as sprites, before players.

Some of the first few steps we need to do are:

• [ ] Define the correct tile size, in pixels, which would allow us to determine the map size.
• [ ] Build the super-simple Tile Enum.
• [ ] Import the tiles into the editor & rom art assets.
• [ ] Update the render system to draw them!

Currently, the player slides endlessly. We need to improve the feel of the game by:

• [ ] Allow jump height to increase the longer the button is held
• [ ] Add some acceleration up-to-a-maximum speed
• [ ] When the player lets go of a movement button, they should decelerate to zero.

Animation sprites are included in the .gce file but they are not used in game. We should have animation states for:

• [x] Idle
• [x] Running
• [ ] Jumping Up
• [ ] Jumping Falling