Game Format Requirements

Offline Digital Game

• REQUIREMENT: The game must be entirely completable while the player's device is disconnected from the internet.
  • Our game was centered around being a single player experience with no network features.
  • We also intended to build the game for Windows, meaning once you download the game, there's no reliance on an internet browser to run our game.
• REQUIREMENT: The total data transfer involved in downloading the game must be less than 100 MiB Links to an external site..
  • We do not use any video files for cutscenes and wanted to prioritize gameplay and functionality.
  • We also opted for the aesthetics of our game to use simple textures and cel shading Links to an external site. instead of lots of high definition textures.
  • By optimizing our game around utilizing as few textures as possible, and having few levels, we avoided having to worry about size for the most part.
• REQUIREMENT: The game may target the platform of the team's choice (e.g. desktop, mobile, console, browser, etc.). However, if Windows is supported macOS must also be supported (at least in principle). If iOS is supported, Android must be supported too (at least in principle [added Feb 6, 2024]).
  • Our game is also easy to port onto other platforms and is nothing more than clicking a few buttons in Unity to build to macOS or Linux.

 

Vertical Slice Requirements

For your game to count as a vertical slice, we should be able to imagine how it would be content-scalable to the full game of your vision without extending the engine, integrating new libraries, or developing new game mechanics.

What our current Vertical Slice consists of:

• Aesthetic/Narrative Foundations
• Cel shading
• Eye iconography on cubes
• Big red buttons
• A visual narrative of progressing through white lab rooms
• Splash Experience
• Loading screen with controls prompt on launch (tentative)
• Menu has a cool parallax background
• Scene Flow
• Menu scene
• Moving from menu to gameplay
• Moving from gameplay to menu
• Moving between level to level
• Core Gameplay
• Player can interact with cubes (picking up and placing down)
• Player can interact with buttons (through cubes or stepping on them)
• Player can manipulate cubes' properties (able to trigger properties based on vision)
• Can complete levels and start new levels
• Deployment
• Our game has been deployed on both Mac and Windows.

Game Concept Expansion

Upon expanding our game, we plan to add the following:

• Narratives
• The player - A thief who got a tip about a lab and becomes trapped within it, forced to solve puzzles to both escape and hopefully find what they came for
• Mechanics/Ideas
• A remote to control physics of cubes (can make a cube lose its momentum, or alternatively, set a cubes velocity)
• A roguelike mode that allows the players to traverse throughout different lab rooms. This will have a day/night cycle where the player will have to reach a resting room by the time it becomes night.
• Visual/Audio
• Dynamic audio (Ex. Audio changes depending on height a cube falls from)
• UI being a bit more stylzied (maybe animated)

Scaling Localization/Accessibility

How we plan to scale our current localization and accessibility options:

• Localization
• We plan on keeping our language use at a minimum, making translation less of a headache. We also plan on allowing user-submitted languages by prompting them to fill out translations in-game.
• Accessibility
• We plan to keep and maintain our current controls and accessibility settings. If we update our controls and add a button, we will also update our one-handed controls. As for other accessibility options, we won’t be changing our design principles for the game too much, so being able to play the game without audio and being able to take breaks will continue to be possible in future versions of our game.

 

Localization Requirements

Your game must support players two use two different written languages. At least one language must use either a logographic script (e.g. Kanji Links to an external site.) or a right-to-left script (e.g. Arabic Links to an external site.).

• Supported Languages
• English
• Chinese

Language-bearing Assets

In this section, we enumerate the types of data associated with our game project that contain locale-specific design choices (e.g. text or images of text).

• Diegetic Assets
• None
• Non-diegetic Assets
• Title of the game
• Text seen during gameplay
• Info text above cubes
• Movement tutorial text
• Text seen during non gameplay scenes
• Main Menu
• Pause Menu
• Credits Scren
• Text in images
• Image displaying in-game controls

Accessibility Requirements

In the spirit of inclusive design Links to an external site. ("solve for one, extend to many"), your games must be completable by players with limited abilities. What it means for a game to be completable or for someone to have a certain ability is largely subjective, so your team should use playtesting to get outside opinions on whether your game satisfies these requirements. For example, your game might be completable by your TA while they simulate the target set of abilities or you might be able to present evidence (e.g. a video recording) that most others are able to feel like they can complete the game under the ability restrictions even the your TA cannot do it themselves.

Limited Vision (Seeing)

• REQUIREMENT: Your game must be completable even when simulating vision limitations: contrast and color sensitivity.
• No important details are lost from either different colors or grayscaled colors.
• Minor details are lost when applying high contrast images.

Limited Dexterity (Touching)

• REQUIREMENT: Your game must be completable by a player using just one hand on the controls at a time. You may require multi-button mouse, multi-finger touchscreen gestures, or multi-key keyboard gestures, but you are encouraged to keep the core controls of your game very very simple.
• The game is completely playable with just a mouse.
• The game may prove difficult to play if playing on a trackpad.

Limited Audition (Hearing)

• REQUIREMENT: Your game must be completable by a player who cannot hear any sounds from the game (e.g. playing the game with system audio muted). Sonic art is an appreciated aspect of design polish (and it can help reinforce feedback provided by the game's graphics). However, for this inclusive design requirement, auditory feedback cannot required for the player to complete the game.
• The game does not require any sounds to complete.
• Sounds might aid players in hearing when something is activated, but we have ensured that players can visually see any changes they made with their environment.

Limited Energy and Attention (Resting)

• REQUIREMENT: During a completion run of your game, gameplay should always reach a natural resting point within two minutes of active play without the player needing to take an extra action to pause the game. (The player may still face intense encounters, but they should somehow resolve or get to a situation where it is safe to let go of the controls quickly.)
• The game does not have any time sensitive segments, meaning players can take a break from their computer at any time.
• Progress is not lost upon players taking a break from the game without pausing.