Team Blam

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

Don't Crash Into Buildings!

Project Marking Percentage

Group work:      50%        (25 <= xx <= 50)
Individual work: 50% +      (50 <= xx <= 75) 
-------------------------
Total           100%

Since the team did not decide, the work division is set to 50/50

Team Website

blam.lighthouseapp.com

Repository

Repo path

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

Trunk Status

committed by YuJin (04-Oct-2010)

Member List

• Email All

First Name	Last Name	Seneca Id	wiki id	IRC nick	Blog URL	MSN	Phone
David	Perit	drperit	dperit	dperit		wowbagger5@hotmail.com	647 - 520 - 3039
Andrew	Condinho	ajcondinho	ajcondinho	Dueraim	Andrew's Blog		416 - 997 - 1589
Brian	Law	blaw1	blaw1				416 - 254 - 3457

Member Roles

Member	Role
David	Collision Detection
Andrew	Path Guaranteeing
Brian	Ship Movement

Proposal

Game Name: Don't Crash Into Buildings !

Game Description:
      In our game, you will be the captain of a ship. The main engine of this ship is stuck on full blast, so it cannot ever stop. The ship is travelling through an increasingly dense urban landscape, and it is your goal to avoid crashing into anything for as long as possible! To accomplish this goal you have a view of your ship from high above it, allowing you to see buildings as they race towards you. You also have a set of maneuvering thrusters, which can push your ship back, forwards, left, and right on a two-dimensional plane. This will hopefully allow you to avoid crashing into buildings!
      The top down view of your ship is provided by a camera moving at a constant speed. This camera provides a limited view of the area around your ship, and your ship cannot move out of this area, or it will crash into an unseen building. This results in you having a mostly static view of your ship as it flies forward through the city. Crashing into a building will kill you. Try to avoid this. The maneuvering thrusters on your ship are unlimited use, and can move you at a constant speed around the viewable area.
      Due to overzealous construction, all of the entrances and exits to the city's planning department were blocked with buildings while the department was meeting to create a layout and zoning plan for the city. As a result, the placement of buildings in the city is random! There is, however, guaranteed to be a navigable path for your ship through the city, due to the actions of the Emergency Runaway Spacecraft Advance Demolition Crew, who are busy carving a path of destruction offscreen, just so that the game isn't impossible. All of the buildings in the city are rectangular in shape, making the collision detection code much easier to write.

Enhanced Don't Crash Into Buildings ! this is a list of things we can do if we're done everything else, and looking for more

(Some or all of these features may be added to/replace features in the base game, depending on time constraints)

• Rather than move you at a constant speed, your thrusters can accelerate you (up to certain maximum speeds). This can provide additional challenge.

• Rather than being instantly killed by a collision, you could have shields on your ship which regenerate over time. This would be damaged by collisions in direct proportion to the speed with which you collided with the building, and you will die if it's reduced to 0

• Could transition between levels, or have moments of blank space giving a chance to rest, followed by a change in environment/city textures
• Have three dimensional movement (up + down, along with forward + back + left + right), combined with shorter buildings that can be flown over or buildings that have gaps in them
• Because it is important to be at the correct altitude to fly through the gaps/over them, we could have an altitude meter with different colours. The gaps in the buildings could be marked with those colours, and then you can match up those colours with the altitude meter to know that you're at the correct height to pass through the gaps
• Vertical movement should be between a set of discrete values, due to the difficulty in telling exact height from a top down perspective, even with an altitude meter

Initial version

The initial version of the game will be on the command line, turn based, with positional accuracy to the character level. This will allow us to write the full grid-aligned bounding box based collision detection, a simplified version of the ship movement code, and the maze generation and path guaranteeing code.

Basic algorithms: Collision detection: All of the buildings are aligned to a grid, so they have a maximum and minimum x position, and a maximum and minimum y position. To determine if we have collided with a building, we check (either for all nearby buildings or all buildings onscreen) out ship's collision co-ordinates to see if maxBuildingX < shipX < minBuildingX AND maxBuildingY < shipY < minBuildingY. If so, then we've collided with that building. We should be keeping track of the ship's position in the previous frame, so that after we collide with something we can reset the position to that of the previous frame.

Ship movement: Press arrows, ship position changes at a constant rate. In the console, we will simply change the ships position by one when an arrow key is pressed.

Maze generation: We will have a difficulty number, possibly from 0 to 100, that increases over time. For each building square, we create a random number from 0 to 100. If that number is less than the difficulty number, then we place a building in that square.

Path guaranteeing: If we have a building grid, like so, where x is a building and o is not a building:

XOOXX
XXOOX
XXOXX
XOXXX

Then we'll have an exit point defined in the topmost row, either at column 2 or 3. Our next row will look like one of these possibilities (I'll assume the exit point is 3). The ? marks are pseudo-randomly determined to be a building or not a building depending on our maze generation algorithm.

??O?? new endpoint is 3
?OO?? new endpoint is 2
OOO?? new endpoint is 1
??OO? new endpoint is 4
??OOO new endpoint is 5

The most likely endpoint here would be 3, with endpoints of 2 and 4 less likely, and 1 and 5 even less likely, although the chance of getting 2,4,1, or 5 would increase with the difficulty level. If it's not possible for the ship to move fast enough to navigate X squares over in a row, then we'll remove that as a possibility, so that the maximum difference between end points in adjacent rows would be x - 1

New maze generation code!

char buildings[40][5];
//initialize that
Path ourPaths[3];
//initialize that

for (int curRow = 0; curRow < 40; curRow++)
{
    foreach(Path curPath in ourPaths)
    {
        curPath.buildPath(buildings[curRow]);
    }
}


Path
{
    int startCol;
    int endCol;

    public:
    void buildPath(char currentRow[5])
    {
        currentRow[endCol] = notabuilding;
        startCol = endCol;
        endCol = endCol + or - a random number, probably influenced by difficulty level;
        //Fill in all columns between startCol and endCol with notabuildings
    }
}

We are going to have several objects: A path object, which takes a row of buildings and generates a path in them. [optional, can just be a list] A pathset object, which contains a set of paths A building object, representing one building A maze object, containing a two dimensional array of buildings A ship object, representing the player's ship.

Our main method will flow as follows, at least in the text version: The maze will use the set of path objects to generate a path through the maze Then, loop until exit, doing the following: Call the maze's draw function.

Call the maze's collision detection function, passing in our ship. (Maze's collision detection will check all of the buildings for collisions, using the ship's co-ordinates)(If a collision is detected, the Maze's collision detection will call the ship's collision function, which will move the ship back in such a way that it's no longer colliding (this could involve storing the previous move and undoing it, adding in any additional movement downwards because the screen has just scrolled down) and reduce your shields)

Call the ship's draw function

Wait for input from the player.

Give input to ship object, which will update position.

Call the maze's scroll function, which will scroll at the pre-set rate.

*How to write game proposal

To Do List

• Background City
• Ship Implementation
  • Hook Ship Up To Arrow Keys
• Camera Fix
• Building Texture Fix
• Additional Maze Features
• Add test grid to bottom of maze
• Ambient Lighting
• Scrolling Implementation
• Ship Lights
• Building + Ship Models
• Full Screen Mode
• Opening Configuration Box
• HUD Implementation
• Clean Up Framework Artifacts

Important Project Due Dates

Tasks	Due Date
1. Proposal outline and team members selected	September 21
2. Proposal completed and members roles selected	September 28
3. Research into game requirements begins	September 29
4. Approval meeting with instructor	Weeks of October 3 and October 10
5. Draft game submission and project review	November 16
6. Final game presentation	December 7

Meeting Schedule

Date and Time	Place
Sept 16, 09:50 AM	Seneca Library Room 1131
Sept 23, 09:50 AM	Seneca Library Room 1131
Sept 30, 09:50 AM	Seneca Library Room 1132
Oct 7, 09:50 AM	Seneca Library Room 1132

Meeting Log

Sept 16th Meeting

Meeting place : Room 1131, Seneca Library

Agenda

1. Look for the last member
2. Brainstorming on our game - share any ideas in mind
3. Decide member roles
4. How this group will work
5. Set regular meeting schedule
   1. at least once a week
   2. share each other's timetable

Result

1. Brian joined our group !
2. Agreed on David's idea - he will put up more details on wiki page
3. Will be decided later
4. Work under one trunk
5. Regular Meeting Schedule
   1. in-person meeting
   2. at Seneca Library - YuJin will book the room every week
   3. on every Thursday between 9:50am and 11:40am

---

Sept 23th Meeting

Meeting place : Room 1132, Seneca Library
Meeting time  : 9:50am ~ 11:40am

Agenda

1. Finalize our game proposal
2. Divide roles & responsibilities
3. Keep updated
   
   1. subscribe to team page and course pages
      
   2. subscribe by clicking 'watch' of each page menu
4. Creating our own private team page ???
   1. to disclose certain information of our group project ???

Result

1. Uploaded game proposal - there might be changes in the future
2. Will divide roles after having meeting with Chris
3. (was just notification)
4. (wasn't discussed)
5. New meeting schedule
   1. We will have meetings every Thursday AND Friday
   2. Will have to figure the exact meeting time soon (for Fridays)

---

Sept 30th Meeting

Meeting place : Room 1132, Seneca Library
Meeting time  : 9:50am ~ 11:40am

Agenda

1. Discuss details on our game proposal
2. Divide up roles

Result

1. Updated game proposal
2. Initial roles decided
   1. David - Collision detection
   2. YuJin - Maze Generator
   3. Brian - Ship Movement
   4. Andrew - Path guaranteeing

---

Oct 7th Meeting

Meeting place : Room 1132, Seneca Library
Meeting time  : 9:50am ~ 11:40am

Resources

Simple Grid Code

Useful Links

Pathfinding Guide