2018-04-09
Project Description
- What kind of game are you planning to build?
- A 4-player cooperative action game set in a high-speed car chase through a wasteland, inspired by Mad Max. Players must defend their group vehicle from enemy cars by building and using turrets, building platforms to expand their vehicle’s size, and steering the vehicle to avoid obstacles.
- Players do not have set roles and can switch roles on the fly as needed:
- Operate turrets to fight enemies, who will shoot and damage your vehicle, destroying platforms and turrets.
- Steer the vehicle to avoid upcoming road obsacles. Crashing will damage your vehicle.
- Build new platform sections and turrets.
- Build and operate tractor beams to recover building materials.
- Controls are WASD or arrow keys and space bar, and Joystick and A button on XBOX controller.
- Art style: desert wasteland, “low-quality realistic”
- What are the goals of the game, how do players win, how do they lose?
- The overall goal is to defend the vehicle, adding new platforms and turrets as necessary, and prevent it from being destroyed long enough so that the vehicle reaches the “finish line” (a fixed length, around 3 minutes). If the vehicle is destroyed (that is, the core steering module is destroyed), the game ends, and the players can start again from the beginning.
- What are the interesting or unique aspects to your game?
- The structure of the play area (the vehicle) frequently changes, depending on which parts get destroyed, and where the players choose to build platforms and turrets. This adds extra layers and challenge and strategy to the game.
- Seeing the desert fly by and your vehicle tilt as it passes over hills will feel exciting.
- What are the list of features of your game? Prioritize them into at least three categories: "Must Have", "Would Be Really Nice", and "Cool But Only If Ahead Of Schedule".
- Must Have
- Steering system and obstacles on the road to avoid
- Build platforms to expand your vehicle
- Build turrets on platforms which you can fire at enemy vehicles
- Enemy vehicles that damage/destroy your ship
- Basic sound effects (by Kam)
- Would Be Really Nice
- Varied terrains
- Build and use tractor beams to grab resources
- Shift power between turrets/driving/tractor beams
- Build and use shields to defend your vessel
- Randomly generated enemy vessels
- Ship death animation: platforms fall out starting from the core
- Crafting system
- Different block materials that are stronger
- Boss fight
- Physics
- Cool But Only If Ahead Of Schedule
- Boarding enemy vehicles
- Fighting enemies, combat
- Add features to components
- Turrets overheating
- Wheels and their respective effects
- Day/night cycle
- Graphics
- FBX loading
- Normal maps
- Directional light
- Shadow mapping
Group Management
- What are the major roles in your group's management?
- Project Manager: Patrick
- Graphics lead, Philip
- Networking lead, Tim
- Gameplay/UX lead, Dana
- Sound design, Kam Look (UCSD student not enrolled in the class)
- How will decisions be made? By leader, consensus?
- Democracy
- If no consensus, the project manager will make the final call
- Each development group will make respective development decisions
- How will you communicate? Email, meetings in the lab, discussion board?
- Discord
- Frequent meetings in the lab, as much as possible!
- How will you know when you're off schedule, and how will you deal with schedule slips?
- Check if we’ve met our schedule milestones on time for that week. If not, then we meet as a group and decide what to do: cut features, etc.
- Who will produce the weekly group status reports?
- Project manager (Patrick) will compile group statuses
Project Development
- What are the development roles and who will handle them?
- We’ll be switching around roles, everyone might have a hand in everything. See “group management” for the team leads.
- What tools will you use?
- C++
- DirectX (will switch to OpenGL if it isn’t working out)
- Visual Studio
- Git+Github
- Blender
- Mixamo
- Sculptris
- How will you do testing?
- Stress tests (10000 vessel components, many turrets shooting, many enemy vessels, many components on a game object)
- Include frequent “This should never happen” checks that print warnings (mostly on the server)
- Git
- Before merging into master, merge master into your branch
- Test the game a bit, and also have someone else test the game a bit, before merging into master
- For gameplay, start by just playing the game ourselves, and get friends to playtest towards the end of the quarter (week 7-ish)
- How will you do documentation (both internal group documentation as well as external player documentation)?
- Player documentation: In-game popups at the beginning of the game: “Joystick to move”, “A to interact”. Possibly have a short “tutorial phase” which requires the group to build some platforms, build some turrets, and kill some enemies, and then the real game will start.
- Show A button icon when close to an interactable object.
- We plan to make in-game text and icons be enough to understand how to play, so that additional documentation and explanation are not needed
- Internal group documentation
- Code reviews via Github - At least one additional set of eyes
- Comments explaining what each function does, its parameters, what it returns. (only header files)
- Comment why each class exists and what it does
- Comment things that aren't immediately obvious
- Don’t comment too much
- CONSTANT_NAME, FunctionName, ClassName, variableName
- Brackets on same line, 4 spaces tabs
- No lines much longer than 80 characters
- Merge master into your branch and test before merging into master (explained earlier)
Project Schedule
- Define a set of milestones with a specific definition of what each milestone is, what it means to complete each milestone, and when you expect to complete them. Define the milestones at two scales, a high level set of key milestones like integration and design freeze, and a low level set of weekly milestones.
- Week 2 - Independent client and server
- Basic client
- Rendering
- Move the camera around with keyboard
- Run the game simulation
- Sends input to a mirror server, verifies returned inputs match
- Basic server
- Clients and server can connect and exchange messages
- Major Milestone: Client-server integration - Week 3
- Client
- Input manager (map inputs to actions)
- Send actions to the server
- Join menu screen with IP
- Server
- Game simulation moved from client to server
- Send back scene hierarchy (including object positions/orientations)
- Start game by pressing enter
- Week 4 - Construction
- 4 players walking on pre-built modular ship
- Pre-placed modules that players can use
- Moving desert sand environment (the vehicle stays still)
- Week 5 - Player interaction (overlaps a lot with week 4; we may switch the order)
- Player module placement
- FIrst-person turret you can shoot
- Steering module
- Players can create new platforms
- Major Milestone: Minimum viable product - Week 6
- Player:
- Movement
- Interaction (Blocks, modules)
- Graphics:
- Lobby/Join UI
- Show players
- Terrain
- Modules
- Vehicle/Grid/Blocks
- Obstacles
- Blocks:
- Block placement
- Block damage (return how much damage the block took before breaking for obstacles)
- Modules:
- Place Modules
- Entering Modules
- Shooting turrets
- Driving vehicle
- Enemies:
- Drive
- Shoot
- Have ships
- Die
- Win and lose conditions
- Week 7
- Randomly generated enemies
- Sound effect code hooks, and Kam starts sound design
- Week 8 (overlaps with week 7)
- Tractor beams
- Varied terrains
- Major Milestone: Version 2.0 and feature freeze - Week 9
- Players perform maintenance on modules, periodically putting out fires (details depend on how the game plays)
- Sound effects finalized
- Week 10
- Testing, debugging, making sure the demo will go smoothly