Currently ResourceManager fails by throwing an exception when a texture/sound is not found. Consider changing this to display a warning message in the console to allow the game to not crash.

• The team coordinator is responsible for the production and submission of the report. Via email, I believe.

• During the course of the project, four reports must to be submitted before the respective presentation.

Allow static decorative sprites to be specified in the level file

We want the Tech 17 player to be able to rotate freely (left and right arrows apply a torque to the body), and the jetpack's main thruster will cause him to move in the direction he is facing.

Implement the level exit.

• x, y
• sprite

Components needed to complete:

• Location
• Sprite
• ???

• Main menu
• Level menu
• Pause menu
• End game menu

The farther TECH-17 is from a fan, the less force it should apply to him.

Core:

• Background texture (looks better when zoomed out, maybe lighter coloring)
• Wall texture
• Fan sprite (higher res, looks more like we are seeing fan from side, gray/white coloring)
• New static decoration sprite - Hologram of Tech-0.2 (An old rusted version of Tech-17 in a 'photo frame')
• New static decoration sprite - A window that shows earth outside
• Exit door (should look different than the entrance door)
• Consolidate sprites onto a couple big texture sheets (as opposed to individual files)

Stretch:

• TECH17 space suit
• Obstacles

• Allow fan strength and fan distance of effect to be specified separately.
• Fans should be blocked by walls.

• Should be able to adjust how long each piece of a dialogue appears on an individual basis.

Might want to use a struct for this.

Not all walls should kill you. There should be regular walls, which you can bounce off of, and "lethal" walls (maybe lasers) that end the game immediately if you touch them.

• Implement lethal walls
• Implement non-lethal walls

• Add submodule initialization instructions
• Add short description of what the game is
• Add c++ compiler, Cmake, and Make to requirements

• Menus
• Music
• Win
• Loss
• Jet Pack
• Fans (spatial)
• Black Holes (spatial)
• Electrical Boxes (spatial)
• TECH-17 Collisions
• Low Fuel/Oxygen Warning (?)

From PlayerView.h

Raise an issue or comment this issue when you find a issue in report.

• Each should report the same material as the corresponding presentation, but more extended.
• Each report should include an up to date design document (PDF), including a changelog.
• In addition, the github revision id or tag name of the latest (compilable on the lab machines) prototype should be submitted together with the report (PDF).
• A report should also clearly list the contributions of each team member.
• The first report should include the proposal and initial design document.

• Milestones/schedule

• Software architecture

• List the team member contribution in the report

• Level design graph

Happens sometimes when switching levels

Put down your ideas under this issue.

• Float
• Serene
• The Floater
• The Center
• Fantactic
• Go With The Flow
• Little Rocket Man
• Missile Boy
• Wafting
• Zero G
• Jetset
• TECH-17
• TJG
• Hover

• Change the README file to say the game's name is Serene.

A radial force consists of:

• Origin Location
• Radius
• Force strength at origin

We want the force to linearly fade to zero as we approach the edge of the radius for a realistic feeling.

To check if an object is affected by the radial force, use raycasting. This is because the force can be blocked by something solid, like a wall. However, any other physical object (like something floating around in the level) won't block the force.

We can create a circle the size of the force's radius to see which dynamic objects are inside the area we need to check, then raycast to all those objects to check how far away they are and thus how much force to apply.

Tasks:

• Implement radial force component
• Implement system for checking if physics objects are affected by the force

Title. Should be updated in real-time.

Components should not depend on/modify other components. Interrelated components will be managed via Systems.

• Create relevant system classes and move component update/render logic
• Get rid of ConnectComponents method as this functionality will no longer be used.
• Remove parent entity pointer from Components.

Since we want to use percentage to simplify the location representation of every "actor" and we use our physics engine's origin, which is right in the center. We probably want to create a small conversion procedure.

The conversion procedure does simple things. For example:

x_level_file = reader.read(leve_1, fan_1, x); // read a float number (as percentage) from json, it could be a fan's x location
x_level_sys = kLengthPlayground * x_level_file - (kLengthPlayground / 2) // transform convert it into an valid value for the physics system

However, just something we need to keep an eye on. Open to discussion.

TODO: reformat the current level file:

• add camera information
• remove endpoints

Rapidly tapping the enter key at the main title screen causes the animation/transition to the level select screen to loop.

This will be similar to the exit door entity, except will cause a different event to fire (Lethal)

• Necessary function in EntityFactory
• Add the shock box to the level reading code
• Create a new spark particle system
• Create shock box texture

Recreate the level from the first presentation for the demo on Tuesday.

Currently, the player can control TECH-17 even if the game window is not in focus on their machine.

Simple Fix:

• If the game window is not in focus, the game's controls should not register.

Better Fix:

• Pause the game when focus is lost.

• Add your content into the slides - Erik

• Add your content into the slides - Tao

• Add your content into the slides - Cullen

• Add your content into the slides - Yangyang

Implement the entrance to the level.

• x, y (origin)
• width
• height
• sprite

NOTE: width and height could be determined by sprite, but this is not ideal if we want display scaling

Components needed to complete:

• Location
• Sprite
• ???

• Executive summary

• Related games

• World

• Characters

Fans should push the player character and have the following adjustable characteristics:

• origin (x,y)
• angle (direction)
• power
• length
• width

Needed components:

• Linear Force
• Animated Sprite
• Location

• Limited Fuel
• HUD that indicates maximum and current fuel level (updates in real time)
• FiniteResource component

The HUD should go in either the top or bottom of the screen, possibly in a corner. We may want to make it partially transparent to give a better view of the level.

Fuel control should probably be implemented in ControlCenter, with the GUI calling accessor methods from elsewhere to get fuel information.

Currently, though limbs' rotation is damped and spring, they should be prevented from rotating to extreme angles. This will be done with a rotary limit joint.

I think we should reevaluate the current value of 0.7, and possibly reduce the amount of damping (make it closer to a value of 1).

• Fuel Indicator
• Timer (oxygen meter)
• Dialog system

The status bar should render on top of the game view.

If the escape key is pressed from any menu, it should go to previous menu. If it is pressed at the title screen, the game should close.

Each time a level starts, new event listeners are added to the event manager. These event listeners are never reset, so after several levels there will be many duplicate event listeners for each event.

When you run out of fuel, the game shouldn't immediately end. We need a heuristic to see if the player will eventually reach the exit given their current speed and trajectory.

Could also just use a short timer to see if the player reaches the exit within, for example, 5 seconds after running out of fuel.

So far in the level.json, we specify walls with a radius, but fans using a width. Maybe we can later on consolidate on one or the other. A radius for walls makes sense because that’s how they are implemented internally so if we make them both the same way let’s use a radius.

• Title Picture

• Art Direction

• Tags & Dialog

• Refine Level design graph

Main Menu

• Select Level
• Exit Game

Level Select Menu

• Display levels (in a grid). Clicking on a level (or selecting it and pressing enter) loads you into that level.
• Main Menu

Pause / End Game Menu

• Paused / You Win / You Lose message
• Retry (If paused or you lose) / Next level (if you win)
• Level Select
• Exit Game

Navigation between menus and game

• State system

Test current TJG on lab environment.

• Player composition

• UI Flowchart

• Mechanics analysis

• Plot graph

NOTE: Levels (and perhaps more importantly, the level camera) should have a 160:81 aspect ratio so there is no distortion when turning TECH-17.

Serene will have 12 levels which tell our story. Gameplay mechanics will be gradually introduced throughout the course of the game. The following is a rough outline of mechanics introduction. Story can be decided later on.

• Level 1 (introduce entrance, exit, fuel and oxygen systems)
• Level 2 (introduce fans)
• Level 3
• Level 4 (introduce lethal walls)
• Level 5
• Level 6 (introduce shock boxes)
• Level 7
• Level 8 (introduce black hole / pressure source)
• Level 9
• Level 10
• Level 11
• Level 12 (finish story)

Currently if you beat level 12, it goes to level 13. Maybe after beating level 12 we can display a special "game complete" screen.

There should be a way for the player to tell how strong fans are.

Best solution: Use a particle spawner. This can also be re-purposed for jet pack smoke.

• Rename LevelView member playerview_render_system to levelview_render_system
  I believe this was forgotten when we changed the view name from PlayerView to LevelView.

• Capitalize first letter on various statusbar/dialogue system methods within LevelView