So there were no sessions that really related to our work in this hour so I thought I'd go to a session that had zombies....Dee Jay Randall (Capcom Game Studios)
Dead Rising 2 shipped shipped 2 million copies in first 20 days.
Co-op Design Objective
- Support franchise themes in co-op such as sandboxing, character levelling.
- Assumed that environment was densly populated and that coop players would not be competing or interacting that much.
- Opportunity was to minimize latency, to the point that it was indistinguishable from single player. In reality this doesn't always work, sometimes users do try to get into same vehicle at same time, or weapons.
Accomplishments
- used Distributed AI for zombies and items. Many thousands of these they had to manage. Entity sates (zombies, weapons etc) had to be distributed. Ownership reflected entity distance. Player interactions caused ownerhsip transfer.
- Earh peer advanced local simlulation of entities, communicates results to others, which minimized latency.
- Guests can join at any time (Join In Progress). guest brings the level, skills and inventory items and clothing with them.
- Character levelling, story restart maintains Chuck's level and skillls. In co-op, only host can save story progress. Gues can save Chuck's level and skill advancement.
- P2P - used for Zombies, player, props. each peer is the owner of a subset of game titles. Combined set of zombies for users might exceed maximum number of actual zombies you interact with. The interactive zombies are called peer zombies.
- P2P vs Client Server - Correctability - zombie position is easy to correct.
Mission state is however hard to correct. As a consequence, inconsisten prop positions won't snowball, and divergent mission state can break the story timeline.
- Data Structures - talked about file size saving for diferent objects and the logic that sends the information. Some items such as vehicles were treated better for presentation purposes, even though they don't have core uses. (eg wheels turning on truck).
- Authority transfer vs ownership - every peer can claim authority, then what they do in lower levels is the authority change triggers ownership results. It takes a bit more time and must be in sync on all peers.
DEAD RECKONING
- you know where an object will be in the future so it doesn't have a mind of it all - like a locally simulated object that is not going to behave balisticlly. Locally, they create a simulation that they know the peer is doing. If there is a difference, they need to tell peer to make difference so they can make adjustments. Goal is to correct prop position within 1 second.
JOIN IN PROGRESS
- requires large initial state transfer. Level state, Chuck state, mission state.
Tools
- most basic was an online logging system that streamed all system and gameplay events with periodic dumps of different game states such as chuck states.
This creates data, so we created a system that only displays logging for only that session.
- Auto Chuck takes a chuck, walking him around hitting weapons for testing, zombie killing and level switching. To get this to work online, connected two consoles in the co-op, then ran auto Chuck. This helped that they could find more bugs locally than testing online.
- Network Traffic
- incorporated network traffic perspectives into all tech design. This leveraged determinism in isolation.
Post-Mortem
- don't sync everything - sync what is important.
- online testing across three continents is important.
- client server was added fairly late in development, which was a mistake.
- missions in co-op created loads of work, many nuances.
- bugs that didn't happen in single player but happened as soon as you add a second player.
- Taking a feature online was done as a second pass. This was the biggest cost mistake. They had a core gameplayer team for single player features. AFter the fact they tried to make them work online, which doesn't work! Needed to go back and re-tweak, and had a lot of difficulty controlling time between core game play and when they could bring them online.
- always run bandwidth analysis before your are feature complete.
- low bandwisdth game play is low quality, even though it met fundamental requirements. It was sucky - would stutter, delays in object pick up, and content resolution caused item popping.
No comments:
Post a Comment