Game Concept 2 - Chiaroscuro

Working Title: Chiaroscuro

Genre: Puzzle/adventure

Platform: Unity Web/PC

Third-person, 3D

Core concept/s:

• the darkness is safe - be afraid of the light

Environment:

• the game takes place in a constructed environment (a series of caverns, chambers, hallways etc - possible a castle or an underground network of passageways. Think Prince of Persia: Sands of Time plus Ico plus a twisty maze of passages all alike)

• Environment should feel abandoned/ancient (stone walls and floor - partially ruined?)

• level design is linear or ocassionally branching without being an actual maze - the player should not get lost, turned around, or returned to the beginning

• the base state of the environment is pitch-black and unlit

Objective:

• the player must navigate obstacles from one end of the level to the other
• ideally, there is an overarching loose narrative and a series of levels that the player can navigate sequentially (pretty standard stuff)

Gameplay:

• the player character shows up as a bright figure in the darkness, but casts no light

• the character is able to draw the darkness into him/herself and expel it again at will, giving the player control over the illumination of the environment

• the game is a mostly-linear movement puzzle - the player must successfully navigate the environment by carefully controlling the levels of light and darkness

I envision the character control scheme to be similar to that of Sands of Time - much less jumping and less need for precision from the player, but the pacing of the character's climbing and walking could be similar.

• there are monsters/enemies lurking about - in the darkness, they cannot hurt the character, but the stronger the light is, the more dangerous they are

Sort of like the inverse of the shadow creatures in Ico - kind of fey and strange and wispy, but formed of bright light instead of darkness.

• when the character is hurt by a monster, they either lose health (standard health/lives system) or are returned to a previous checkpoint
  

• in order to navigate the environment, the player may be forced to draw in all the darkness, bright illuminating the space, as some environmental elements will only be fully corporeal in full light

• conversely, some objects will only by fully corporeal in darkness (bridges, ledges etc)

• some obstacles/path blockages will only disappear in darkness; some only in light

Other mechanics:

• There are a few possible ways to handle the monsters - either the character has no offensive capabilities and is forced to run from them (survival), or the character can destroy them, but either there is a limit to the number of times they can do so, or the monsters quickly regenerate after being destroyed

• the overall game should not have a time limit, but will be elements that require quick thinking (the old breakable ledge trick and variations)

• elements that are corporeal in different light levels will be shown as translucent when not solid

• the light levels needed to solidify any single element will be shown by the colour of the element (eg you draw the darkness away from a translucent black bridge and note its position, then walk across it in the dark)

• the light levels required should not be overly precise (three to four key light levels from dark to light)
  

Obstacles/game elements:

• elements that drain the darkness out of the character back into the world
• elements that block the character from expelling darkness
• elements that reverse the dark-absorbing effect
• elements that only allow the character to go between extremes (full light or full dark)
• sources of light outside of the characters control (eg moonlight)
• sources of light that the character has limited control over (eg. drawing darkness from and illuminating the far end of a corridor to cover a torch beside the character

Sound:

• no tunes - semi-musical ambient sound
• sound feedback for the game is important, since so much of it can potentially take place in darkness
  
• character footsteps (or whatever noise the character makes, if not humanoid) can change according to surface, to give clues about where the character is standing - the floor may have a different sound at the edge of an abyss to warn the player
• there is a warning sound when there are monsters/enemies around - so that the player knows what to expect if s/he draws in the darkness
  

Other visual elements:

• The enemies/monsters should be bright and beautiful, but somehow slightly wrong and threatening (thematically, similar to the Weeping Angels in the Dr Who episode 'Blink')

• The character does not need to be humanoid

Although clearly the initial sketchy design I have of the character is heavily influenced by Yorda from Ico - she doesn't cast light, but seems to be self-illuminated and shows up brightly in the game's darker environments.

Potential problems/other issues of interest:

• this does require a sense of some kind of story, even if only a very loose or simple one, to tie it together

• the story may or may not necessarily need to be fully presented to the player
  

• the visual ideas for the environment are not totally clear at this point - this requires a good deal more thought and design

• again, because the levels cannot be generated and there is probably a story, this is not necessarily a game that could be 'finished' in the project time available - possibly a condensed or simplified short game could be completed instead

• control scheme needs to be clarified - how does the player control the darkness (mouse wheel scrolling, perhaps?)

• it's difficult to say how hard this system would be to code

Game Concept 1 - Threadsuns

Okay, here goes. This is the first of three game concepts I have thought of that I will potentially be able to pitch in class on Wednesday 10. For some modicum of clarity, I'll try to describe them in dot points. Pictures will be added when I have made some.

Working Title: Threadsuns

Genre: Puzzle

Platform: Unity Web/PC

First-person, 3D

Core concepts:

• the player is disembodied, and has no apparent physical presence in the game world
• there is no fixed orientation in the 3D space; orientation changes as the player moves around the world

Environment:

• the game takes place in a grey-white void filled with 'suns': glowing orbs that float in the space like stars

• the player has a full 360 degree view around them on the X-axis and 90-degrees up and down on the Y-axis

• (alternatively, the player has a full 360 degree view around them in all directions, but has the ability to lock-off the view temporarily to move and re-center the mouse within it. This version is more of a mindfuck)

EDIT: A better version: The player has a fulle 360 degree view in all directions, but they click and drag on the screen to rotate the first-person camera and move the viewport.

Objective:

• there is a goal point somewhere in the space (a planet or similar), which is visually distinct from other elements
• the player has an object (the package) that they have to deliver from the level's starting point to the goal

Gameplay:

• the 'suns' form gameplay nodes. The player's viewpoint is always situated over a node

• the player can travel between nodes via a 'thread' drawn from one to the next

• the player can pull a thread out from the current node and either place a new node in the world or connect to a pre-existing node

• threads have a fixed length, but the new node can be placed anywhere in the players viewport (as long as not prohibited by another game mechanic)

• when the player travels to a new node, the view will re-orient so that the newly created thread is directly behind the player on a horizontal plane (perhaps this should eventually be that it re-orients to the view that best encompasses the path behind them)

• the current orientation is shown with a skybox that is darker at the bottom than the top

• the player can draw an adjacent thread back into the current node to erase the path

• there is a limit to the number of new nodes that can be produced from a pre-existing node

• the aim is to create a pathway that the package can travel along from the starting node to the planet

• the package will only move when there is an unbroken path that leads all the way from the starting node to the planet

Other mechanics:

• levels with pre-existing networks that have to be erased to limit the package to a single path

• levels with fixed networks where the package has a specific movement pattern that the player can exploit (eg. the package will always go left at a fork in the path)

• different coloured nodes with individual attributes such as specific thread length, different limits on the number of nodes that can be created from it

• multiple packages with different attributes (eg. a red package that cannot travel through across blue nodes)

Obstacles/game elements:

• 'black suns' that suck in nodes and destroy the path

• areas that the player cannot travel through
• areas that the package cannot travel through
• areas that threads cannot be drawn through
• eddies that shift nodes and/or threads
• teleport points

Sound:

• all sound effects in the game would ideally be musical and harmonic, with an underscoring ambient atmos effect, so that the SFX accompanying actions taken in-game create an ambient soundscape

• audio feedback about obstructions could be included as dissonant sounds, to cue the player to look around for the obstacle

Other visual elements:

• the void can be filled with weird and wonderful visuals that add to the ambience, such as clouds of gas or vapour, strange creatures or symbols ghosting out of the background

I am particularly thinking along the lines of Steve Ditko's work on the original Dr Strange comics - unusual organic shapes, that could be incorporated into the gameplay.




I think these images give a really good feel for the sense of disorientation in a 3D space and the lack of easily identifiable absolute directions.

Potential problems/other issues of interest:

• until the game is prototyped there is no way of knowing how well the player will deal with the sense of disorientation and constant re-location that forms the core of the game (it may turn out to be simply too difficult)

• how to teach the player the mechanics - should they learn by exploring? Should there be a series of tutorials at the beginning of the game to help the player?

• what is the interface for placing nodes?

• is there a classic fixed GUI, or a dynamic one, or simply appropriate in-game indicators?

• will the player need/want an overarching story or can the game simply be surreal verging on abstract?

• the levels need to be designed (to attempt to randomly generate something this complex would be a horrible coding nightmare)

• consequently, how much content can be generated for this game?

Presumably, with the time and people available, the final product would be a one-level demo of the concept and gameplay.

Furst

Oh hi thar,

This is a blog where I will be documenting and keeping track of my 3rd year Games Design degree project/s. So far there's not much to say, since the nature of the projects are still nebulous, but over the next week I will be posting and refining the game concepts I want to pitch in class.

Next post: some possible core gameplay mechanics.