GAM666/DPS901 Victorious Secret

GAM666/DPS901 | Weekly Schedule | Student List | Project Requirements | Teams and their Projects | Student Resources

Victorious Secret

A team created solely on pure awesome? Say it ain't so!

Bang!

Project Marking Percentage

Group work:      50%
Individual work: 50% +
----------------------
Total           100%

Repository

Repo ID

svn://zenit.senecac.on.ca/dps901_113rep4

Trunk Status

committed by [NAME] / being committed by [NAME]

Team Members

Team Member	Role	Status
Ozzy Mirza	GUI (Menus, Heads Up Display)	-
Victor Tran	UI (Inputs, Input Configuration)	-
Minoo Ziaei	Graphics (Lights and Cameras)	-
Chi Lea Tran	Graphics (Models and Textures)	-
Alex Chung	Audio (Sound Effects, Background Music)	-
Bryce Harmidy	Physics (Collision, Projectile Motion)	-

• Physics will most likely require an extra to help out

eMail All

Proposal

Objective

The purpose of this project is to create a simple 3D game using the DirectX framework in 8 weeks.

Concept

Our idea consists of launching a block in the air and landing it in a target area. Launching the block will consist of a spring mechanism similar to what is observed in a pinball machine. The user will control the power by holding down a button and releasing it at the desired time. The launcher will be aimed diagonally to allow the projectile to move in a forward motion and be pulled down by gravity.

Sketch of Front view

Sketch of Top view (Arrows only indicate ability to rotate launcher)

Controls

We plan to use one button on the controller (2 on a gamepad) to control the power of the launcher. With time permitting, we may include the use of the analog stick to determine the direction of the projectile.

• Questions regarding the state of the controller when polled (vvtran)
  • How do I allow for use of the "hat" buttons (Up down left right buttons on a controller)?
  • How can I detect to see if Z-Axis or the right thumbstick exists instead of using a checkbox to do so?
  • I notice that the Controller is pretty much set up in the engine, however it seems to only be able to poll if something is getting pressed. Is there a way to poll for when the button is released? If so how can I do this? I would like for this to work because of the cannon's "charge up" when the player tries to fire something.
    • I realized that by using pressed(BUTTON_1) it returns a boolean, so I can figure out if it's down or up if it's true or false. Since I already have a counter that is counting how much power is going into the shot, I'm reusing that as a check to see if the button had been pressed.
  • From my understanding of the engine, what's implemented for the controllers should be enough as it is. Would I need to create a seperate Joystick class like it's done in the notes? If I want to do the controller button up/released, is this what is required to do so?
    • Not doing this, unless it's required for vibration... I'll deal with this later in the semester
  • Axis of the controller also don't seem to be implemented either. Or at least I can't seem to pinpoint where. I just see that axis are detected and setup, but I can't seem to find where to actually call up their status and see if they're being changed. ... although somehow the camera rotates when I use them...
    • Figured it out. I also had to include a "dead-zone," which means that the user has to push the analog a certain amount before it does anything. Really it's just restricting a range greater than 50 and -50. Having no dead zone makes it a tad too sensitive, so that even moving in various directions it would register.
      • Because we're using the right thumbstick for control, we need to figure out how to always include the right thumbstick instead of having to check off the box in the dialogue box. Probably the best behavior for this would be to check to see if a Z-axis exists in code, if it does, use it, if it doesn't, default to the left thumbstick's up and down.
      • For future reference:
        • GT_CT_POSX = Left Thumbstick, Left/Right
        • GT_CT_POSY = Left Thumbstick, Up/Down
        • GT_CT_DSPZ = Right Thumbstick, Left/Right
        • GT_CT_ROTZ = Right Thumbstick, Up/Down

GUI Elements

==== Menu ====

The In-Game Menu will allow the user to start a new game, quit, or resume game.

Heads Up Display

The game will have two main elements for the HUD. One is the current player score, and the other is the power meter.

Score

The score will be positioned on the top right corner of the screen. Each time the player lands a block on a target, the respective amount will be added and displayed on this counter. This will be used for the player to gauge how well they're doing.

Power Meter

The power meter will be positioned on the bottom left of the screen. When the player presses the launch button, the power bar will start to grow until the player lets go of the button or it reaches it's maximum. This will give the player an idea of how much power they're using, aiding them in hitting the targets.

===== Targeting Aid =====

Time permitting, there will be a dotted line extending outwards from the launcher that will aid the player when aiming. It will be a straight line that represents roughly where the block will go, but not where it will land.

Audio

Sound effects and background music will be used to create a more full experience.

Sound Effects

Sound effects will play when:

• the player is holding down the button
• the projectile is launched
• when the projectile lands
• a rewarding sound when the projectile lands in the target
• a disapproving sound when the projectile misses the target.

Background Music

This is to be determined. We will require music that we can rightfully use, for example, the unique and majestic musical stylings of saraJ00n: http://www.youtube.com/watch?v=QH2-TGU1wu4

Lighting

Our basic lighting set up will involve one large light source representing the sun. This light source will need to be able to light all of the core elements (launcher, target pads).

Time permitting, each target pad will emit a coloured light, and a red or a green light will emit where the block lands signifying a target hit or a target miss.

Camera

Camera will be set-up at the shooting location, pointing diagonally to the direction of the target.

• 30/Oct/2011

In addition to the instructor's suggestion we can consider the third option. So, the first two options will be included in the game, the third option will be as well, if time and the potential of the framework permits:

1.a - Static -> Will be set-up with a default slight distance behind the launch location.

1.b - Static -> Will be set-up with a default slight distance behind the target location.

2 - Dynamic -> Will be attached to each projectile when they are created.

We can either give control of the camera (which direction to look) to the player or we can just give the zoom-in and zoom-out control to the player and have the default direction of view toward the target.

Sketch of the Demo Camera

3 - Dynamic (Demo) -> This will be just a demo camera, which will cycles around a circle which has a diameter equal to the distance between launcher and the target. (not sure if we this is possible here, needs more thought and help)

Questions:

Where to set the specific speed based on the distance (Such that the cycle finishes at the same time the projectile hits the target)?

Should the transformation matrix be set in the update() function in Design.cpp?

Should we store this distance somewhere in Desing.cpp?

• Forgot to point this out the other day, but I found that in the engine currently, the input controls for the cameras reside within the Camera class. I don't think we need any of it unless we resort to a manual controlled camera. (vvtran)
  • It may be best to comment them out as they can conflict with what's in Design.cpp (I know the controller inputs definitely conflict here)

Instructor's Comments

Page sections don't require numbering on a wiki √

Undiscussed issues

• nothing on repo yet √
• is the in game menu separate from the configuration dialog
  • do you intend to use splash screens √
• controls √
  • you should have enough time to incorporate the analog stick √
• heads up display √
  • use a texture and scale it √
• lighting √
  • add emissive component to light - simple √
  • simple to attach a light to an object √
• other notes
  • many projectiles
  • steering them in flight - camera attached (most likely not -- vvtran)
  • fading lights on hit targets
  • what happens when sun is off

Suggestions

• for a camera moving in a circle try:
  • the launch point and the target are fixed - so from the mid point you can measure an angle to the current location of the projectile [0 -> 180]
  • you can position the camera with respect to the same mid-point at the same angle as it moves around the circle - this way it will leave and arrive at the same time that the projectile does
  • the calculations could be in the same place - Design::update() or in Camera::update() - probably better to keep them separate - add a query to Design to extract the angle into Camera::update() - it's up to you
  • so the first step is getting the angle from the projectile's position
    • there is a formula for the angle between two vectors - it comes from the formula for dot product: a dot b = |a||b|cos theta ; use the acosf function in cmath
  • second step is derive a special follower Camera class and add the logic there
    • build a prototype cube that simulates your camera to make sure that your math is right - then move the logic to the derived camera class
    • take a vector from mid-point to launch point and rotate it about the world Y axis through the same angle
    • this should give you the position of the camera
    • take a vector from that position to the projectile - that is your camera heading
    • take the vector perpendicular to the vector from the mid-point to the camera
    • the cross product of this vector and the heading is the top vector for your camera
  • the calculations need only be done if the camera is the current one
  • start with the transformation code in the Camera::update()
• make sure that each of you is comfortable with svn - put in a small change to the framework - merge back into trunk - update
  • you will be doing this often as time goes by
• code the core of the game first with existing elements of the framework
• design and code new objects - like terrain and projectile - use create box as a template
• separate textures and vertex structures as in the framework
• divide responsibilities on different aspects of interest and code so that failure to debug new code does not close down the project
• if you need math help ask me

Discussed

• change the repo id to a link √
• shouldn't need extra physics help for this - could be kept quite simple
• other notes
  • use many triangles for terrain to improve lighting effects √
  • any model input - writing the interface could take some work
• cameras
  • simple to attach a camera to an object √
  • consider adding camera to each projectiles