Project Design
Black Hole Sun
Group Members:
https://github.blairmacintyre.me/site-archive/cs4455f13/author/dbyassmith/
In charge of the overworld
https://github.blairmacintyre.me/site-archive/cs4455f13/author/jtyson3/
In charge of the underworld
https://github.blairmacintyre.me/site-archive/cs4455f13/author/defenfo/
Art assets & design, but still involved in the coding where applicable.
Overview:
The main character is trapped in a collapsing galaxy and must travel from planet to planet collecting dark matter in order to save the universe. The game-play should be fast and frantic, as the gamer only has a limited amount of time to complete the game before time runs out. The player is expected to do poorly on the first play-through, but the game is designed such that it won’t be annoying to start over. It’s sort of the kind of game that you have to speedrun. The better you do, the more planets you save. Play the game multiple times to save as many as possible. It should make you feel like a hero! The black hole’s absorption rate increases steadily, but if you collect enough dark matter it slows the black hole down a little bit. To win the game, the main character must make it through every planet before time runs out.
Fun:
– Learning how to get through stages in the most efficient manner gives player a sense of accomplishment.
– Player movements are fast, and involve lots of pirouettes and flips. The movement should be bombastic. Pulling off certain combinations (hitting a monster just right, timing jumps and hovers, etc) will help speed you up for a while. Being able to quickly go through levels like this should be fun.
– Watch as the universe/overworld changes according to which/how-many planets you’ve rescued.
– Different levels should each have their own individual aesthetic and style of puzzle, making the player want to explore as many as possible.
Level Design:
The game consists of both an ‘under-world’ and ‘over-world’. The ‘over-world’ is essentially just a level select. The game timer continues to run as you travel from planet to planet.
Each planet is a level. Underworld game-play takes place in a mostly 2-dimensional platformer environment. Should be designed such that the player has strict control over moving, jumping, and attacking accurately and quickly. Will contain puzzles, monsters, and secrets.
^ Basic structure of an underworld level. Left/right movement is possible. visually it’ll look 3-dimensional.
^Example of one of the underworld level designs.
Completing a level gives you the option to continue to the next planet or return to the level select.
Character:
– The character runs through the environment dodging obstacles and attacking enemies. The character’s attack is a shockwave attack
The character also has a rocket boost ability. By double jumping a rocket boost is activated that pushes you forward while the jump button is held down. This is the maximum speed you can reach in the game, but is difficult to control and lasts a short time. Landing on the ground transitions back into running mode. Crashing forces the player to start again at normal walking speed.
Enemies/Obstacles
The enemies in the game will be very simple. Some will act like moving hazards and are only a factor if the character touches them. Others will have basic predatory behaviors and will attack the character if they are within a certain distance. Enemies do not kill the main character but significantly slow down their movement.
There will also be a number of environment hazards on the level that slow down the characters movement (ie: swamp pits, spikes, etc).
Additional things to add if time permits:
– Alternate endings. Special final boss if you save every planet. (for example, a screaming terror could come out of the black hole if you manage to save every planet)
– Instead of having the dark matter automatically save planets, maybe implement a way that you can use them to save the planets directly while in the overworld.
– More planets. More variations of feel between different planets.
– More variation in monster behavior
– Alternate outfits
– Cinematic cutscenes when transitioning between worlds.
Feature Set Targets
Minimum Low-bar:
For our minimum feature we will have at least three levels that have functional mechanics, reasonably descriptive graphics, and very little variation in game mechanics between levels. Very basic AI for enemies/environmental hazards. Hazards should be just visually descriptive enough that the player can predict what they’re going to have to do to avoid them. Player animation is rudimentary but descriptive. So, the animation for walking/running/jumping/etc can consist of spastic leg movements and don’t necessarily need to be realistic so long as they get the general idea across..
Target: Our target feature set features a handful of planets with at least four unique levels with their own unique gameplay gimmicks (aerial maneuvers, platforming, 10m dash with hurdles, etc). More complex enemy movements and interactions with player. It should approach the description described in the design plan, though some details can be cut depending on difficulty of implementation. At least enough variation in environment and enemy types to be interesting for 60-90 seconds.
High-bar of Desire: At least four fully realized levels. Level designs should be perfect, with anything that might be too frustrating or slow the player down too much tweaked to allow for possible ideal runs through the game. Player and monster animation looks smooth and nice. (ie, the walk/run/jump/stumble animations will look like actual running/walking/jumping/tripping/etc)
Timeline
Nov 1: Working demo of a platforming level. Can just use cubes for the graphics for now. This is the basis of the game so if we can’t do this we’ll have a problem.
-Build a track that can be run down
-Be able to pick up and keep count of items
-Define all possible character movements. Should be (reasonably) appealing to move around, though we will continue making game feel tweaks as we go. This includes a state machine that will keep track of walking, jumping, running, boosting, etc.
-Once we have this prototype, we can use it to construct other levels, so make sure that monster and environment types can be adapted to different things with different effects.
The environments will be kept very simple. We need to include just enough stuff so that test-players can see what kinds of things are going to be in the game. So, have a variety of monster types and environmental hazards that we expect will appear in each level and have the character be able interact with them in a variety of ways. Best to have as many different kinds as we can, so we can see which hazards and interactions work, and which ones don’t. This is essentially the stage where we come up with ideas, so Experiment and have some really wild things happen. We can tone it down/smooth it out later. Hopefully the test-players will be vocal about what they like and what they don’t like.
Nov 8: The first level should be close to fully realized. Have at least two other levels in the works. Levels should have the same rudimentary, so you can start off by making them copies of each other, just with different models/lighting/etc, and work on distinctions between them as you go.
Add capability to be able to go to the next level after playing through the first. Make sure the clock counts down and is universal between levels.
Work on making character movement and interaction with environment feel appealing. Use feedback from the first demo.
Have an overworld/level select screen that lets you choose a level. It doesn’t have to be too fancy.
This is the stage of production where we’ll hopefully have met the minimum expectation goal. All the structure of the game should be in place by now. The character movement should be complete enough that the play-testers will be able to comment on the controls in depth. For the same reason, there should be enough things to interact with such that the test players will be able to comment on how the character interacts with things.
Nov 16: Two ‘full’ levels. Keep experimenting with what kind of hazards and other gameplay elements make each stage unique. Each level can have it’s own “gimmick”, so one might involve more jumping and aerial motion, one might require dodging flying hazards, etc. This is the stage of production where you’ll begin really focusing on that.
Continue to tweak gameplay as needed.
Game should be approaching what it’ll look like in the final version. We’ll need to count on the test-players to tell us when things aren’t working, are unclear, or aren’t fun to play, or if there’s something that’s really fun that we need to have more of.
Nov 22:
Continue making changes to existing levels as needed. Make one or two more levels if time permits.
Hopefully have the game finished according at least to the Target goal. Ideally we’ll only have to spend the rest of our time from here on out making small changes.
Nov 25: This is the end. Have the game done by now.
Comments are closed.