Difference between revisions of "Team Blam"
Ajcondinho (talk | contribs) |
Ajcondinho (talk | contribs) (→To Do List) |
||
Line 164: | Line 164: | ||
[http://zenit.senecac.on.ca/wiki/index.php/GAM666/DPS901_Project_requirements_20103#Phase_1 *How to write game proposal] | [http://zenit.senecac.on.ca/wiki/index.php/GAM666/DPS901_Project_requirements_20103#Phase_1 *How to write game proposal] | ||
== To Do List == | == To Do List == | ||
+ | *Background City* | ||
+ | *Ship Implementation* | ||
+ | <s>*Camera Fix*</s> | ||
+ | *Building Texture Fix* | ||
+ | *Additional Maze Features* | ||
+ | *Add test grid to bottom of maze* | ||
+ | |||
== Map of the World of the Game == | == Map of the World of the Game == | ||
== Moderator's - Instructors Comments == | == Moderator's - Instructors Comments == |
Revision as of 09:32, 4 November 2010
GAM666/DPS901 | Weekly Schedule | Student List | Project Requirements | Teams and their Projects | Student Resources
Contents
- 1 Don't Crash Into Buildings!
- 1.1 Project Marking Percentage
- 1.2 Team Website
- 1.3 Repository
- 1.4 Member List
- 1.5 Member Roles
- 1.6 Proposal
- 1.7 Initial version
- 1.8 To Do List
- 1.9 Map of the World of the Game
- 1.10 Moderator's - Instructors Comments
- 1.11 Important Project Due Dates
- 1.12 Meeting Schedule
- 1.13 Meeting Log
- 1.14 Resources
- 1.15 Useful Links
Don't Crash Into Buildings!
Project Marking Percentage
Group work: xx% (25 <= xx <= 50) Individual work: xx% + (50 <= xx <= 75) ------------------------- Total 100%
Team Website
Repository
Repo path
svn://zenit.senecac.on.ca/dps901_103rep3
Trunk Status
committed by YuJin (04-Oct-2010)
Member List
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.
To Do List
- Background City*
- Ship Implementation*
*Camera Fix*
- Building Texture Fix*
- Additional Maze Features*
- Add test grid to bottom of maze*
Map of the World of the Game
Moderator's - Instructors Comments
Important Project Due Dates
Tasks | Due Date |
---|---|
5. Draft game submission and project review | November 16 |
6. Final game presentation | December 7 |
Meeting Schedule
Date and Time | Place |
---|---|
Oct 7, 09:50 AM | Seneca Library Room 1132 |
Meeting Log
Sept 16th Meeting
Meeting place : Room 1131, Seneca Library
Agenda
- Look for the last member
- Brainstorming on our game - share any ideas in mind
- Decide member roles
- How this group will work
- Set regular meeting schedule
- at least once a week
- share each other's timetable
Result
- Brian joined our group !
- Agreed on David's idea - he will put up more details on wiki page
- Will be decided later
- Work under one trunk
- Regular Meeting Schedule
- in-person meeting
- at Seneca Library - YuJin will book the room every week
- 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
- Finalize our game proposal
- Divide roles & responsibilities
- Keep updated
- subscribe to team page and course pages
- subscribe by clicking 'watch' of each page menu
- subscribe to team page and course pages
- Creating our own private team page ???
- to disclose certain information of our group project ???
Result
- Uploaded game proposal - there might be changes in the future
- Will divide roles after having meeting with Chris
- (was just notification)
- (wasn't discussed)
- New meeting schedule
- We will have meetings every Thursday AND Friday
- 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
- Discuss details on our game proposal
- Divide up roles
Result
- Updated game proposal
- Initial roles decided
- David - Collision detection
- YuJin - Maze Generator
- Brian - Ship Movement
- Andrew - Path guaranteeing
Oct 7th Meeting
Meeting place : Room 1132, Seneca Library
Meeting time : 9:50am ~ 11:40am