diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/gameplay.md | 54 |
1 files changed, 50 insertions, 4 deletions
diff --git a/docs/gameplay.md b/docs/gameplay.md index 97f8f37..7e4fcc0 100644 --- a/docs/gameplay.md +++ b/docs/gameplay.md @@ -1,4 +1,5 @@ # concept (Niels) + I personally didn't have a massive idea for a game. I was thinking of a multiplayer shooter-type game with inspirations of tanks, asteroids, and Mario. ## USP @@ -21,6 +22,13 @@ the gameplay isn't really outlined but my idea works like this. where you have d ## General gameplay +You play as a mage who has long lost his trusty wand. Having been separated +from your *twig* for some time, you've become proficient in the rapid use of +simple spells. You use these spells to defeat foes and minibosses that ward the +dangerous path you take to recover your *spell stick*. After battling your way +through all sorts of dangerous levels, you find your *incantation baton*, which +you then use to fight the final boss. + - Platformer (similar platformer mechanics to Cuphead) - Focus on gameplay instead of story - Medium length levels @@ -39,15 +47,15 @@ the gameplay isn't really outlined but my idea works like this. where you have d  -- Small guy with a hood and Fall guys eyes +- Small guy with a hood and "Fall guys" eyes - Actions - Jump (primary action button) - - Dash/attack (secondary action button) (upgradable -> [shop][shop]) + - Dash/attack (secondary action button) (upgradable -> [shop][loek-shop]) - Movement (D-pad) - Shooting (D-pad) (automatic rapid fire when holding direction) - Temporarily invulnerable when taking damage (with flashing animation like in Super Mario Bros.) -- 5 HP (by default) (upgradable -> [shop][shop]) +- 5 HP (by default) (upgradable -> [shop][loek-shop]) ## Level design @@ -72,7 +80,7 @@ the gameplay isn't really outlined but my idea works like this. where you have d - Vertical levels can either flow from top to bottom, or bottom to top - Small sections of backtracking are allowed in the top to bottom vertical flow -[shop]: #checkpoint-room-shop +[loek-shop]: #checkpoint-room-shop ### Checkpoint room (shop)  @@ -107,6 +115,12 @@ the gameplay isn't really outlined but my idea works like this. where you have d - 1: primary action - 2: secondary action +In the above level, possible actions the player can perform are drawn using +dashed lines, with actions being indicated using the action button markers. The +levels are medium-difficulty platforming levels, with enemies that block the +way. The player can choose to take extra time to defeat all the enemies before +jumping to a platform, or to jump while shooting. + ## Enemy types The enemies aren't named in-game, so these names are either working names or @@ -143,3 +157,35 @@ internal names. All enemies deal 1 HP damage per hit. - Medium-high score bonus - Was on NOS Jeugdjournaal once +## Later additions (converging) + +- New Super Mario Bros. Wii-style co-op multiplayer (with ability to throw your + friends) (Niels) + - Shared HP between both players + - Pick up other player by pressing secondary action button while standing + still + - Throw picked up player by pressing secondary action button again (also + works while moving) + - Easter eggs that are only reachable by throwing and dashing in sequence + (Loek) +- The player character is a mage, instead of some random armed guy (Joshua) +- General storyline based on the idea that the player is a mage (Joshua) whose + wand is lost (Loek) + +## Technical implications + +- Graphics + - There needs to be at least a separate foreground layer and background layer + to make sure enemies and interactive elements appear in the right order on + screen + - Not too many enemies can be on screen at once + - Large levels need to be buffered and/or paged + - Physically large minibosses require a lot of foreground sprites + - **Screen wiping** transitions require hacky workarounds and/or lots of + sprites to display properly (fix by using palette dimming transition) +- Processing power + - Hitbox checking might need to be optimized using screen chunks due to the + (possibly) large amount of on-screen enemies at once + - Sound and GPU instructions will need to be streamed 'continuously', so the + game loop can't take up 100% CPU time + |