“Marvel’s Spider-Man”: A Technical Postmortem

Notes on a talk by Elan Ruskin of Insomniac

  • Slides (PDF)
  • Engine began life in Fuse
  • Much more open world than they’ve used before (5 km across)
  • 154MB of source code (.h and .cpp)
  • Frame breakdown
    • 33 ms/frame
    • GPU renders 1.3333 frames behind the CPU
      • Post-processing happens at the start of a frame
    • Main thread
      • 3 ms streaming asset setup/teardown, initialize/destroy actor
      • 10ms update gameplay logic
      • 6ms physics and audio
      • last 8 ms submit work for render thread
    • High priority and low priority worker threads—urgent things like skeletal animation can interrupt them
    • GPU 1 1/3 frames behind
      • CPU gets 1/3 of the way through the frame when it tells the GPU where everything is
      • Gotta keep that geometry around until the GPU is done with the geometry
      • GPU is ending its frame when the CPU is starting the next one
  • Things not threadsafe in the engine
    • Creating actors (a.k.a. entities)
    • Creating/removing compoentns
    • Creating/removing entities
    • Allocating entities
    • Components of a given class have to come together (all animation components, all AI, all movers, etc.)—may depend on each other
      • Took some things away from the component system (moved back to a big for loop)
  • Level of detail
    • Turned down tick rate for stuff far away
    • Keep on top of this—if no one’s ever going to see it, don’t waste tris
  • Simple is good
  • City building
    • For details on city-building, see “Procedural Generation of Manhattan” talk
    • Started with Houdini 
    • Needed to allow artists to hand-edit it, then feed that data back into Houdini
      • Houdini emits “prefabs” as JSON, which can be modified
      • Simple text data interchange is super useful for tech artists and custom gameplay system—easy to move between tools
    • Hand-editing procedural content is okay, but it’s cyclic and complicated
  • Fit the tech to the context!
    • Created custom gameplay systems specific to this game
  • Streaming
    • See talk “Streaming Sunset Overdirve’s Open World”
    • 9 tiles loaded at a time (128 m across each)
    • Top player speed is 72 mph, and you might have up to 5 tiles loading at a time, but the 3 in front of you on a diagonal are most important
      • Thus, tiles have to be ready in 1.33 seconds
      • What happens if you have a slow hard drive?
      • Came up with budget of 20 MB per tile
      • Want a bigger budget? Figure out what assets you can procrastinate on
        • Delay the biggest two Mips, and the middle ones
        • If you’re moving fast, you can’t tell at all
        • New budget: 20 MB up front, plus 20 MB for when you slow down
        • Defer detailed ground objects until you both slow down and get close to the ground
    • Originally hoped for no load spinners ever (via airlocking and other other dirty tricks like cutscenes designed to be juuust long enough to load all the assets you need
      • Takes too long to do this because it’s so damn fancy
      • Gave up after only doing a couple of these
  • Initially relied heavily on duplicating assets
    • Disk: want consistent read size, no seeks
    • Had to duplicate assets in various places on disc to do this
    • Gave up on this for big asset types to save more space
  • Considered trying better compressor than LZ4, but decided against it
    • Did improve compression by changing the way they index tris in the models
  • Rendering New York
    • See Digital Foundry’s “Marvel’s Spider-Man: A complete analysis” video
    • What’s not loaded? Have a single low-res version that’s always rendered that gets the better versions mapped over it
      • Autogenerated from full-res geometry
      • Single shared 4k texture per zone
    • Stream a high-res version as you get close
    • Water towers, AC units, etc. really affect outline of building, so those always get loaded on top of the buildings (not box-shaped like buildings)
      • Created a cheaper version of these that only uses 40 bytes for use far away—no animations, nothing fancy
      • 13 MB for the whole city
  • Revisit speed-space tradeoffs!
  • Photo mode
    • Undervalued by programmers
    • Original plan: 3D camera, basic controls, some stickers
    • Added frames, selfie mode later
    • When people were doing this on the team, it sparked a lot of new ideas
    • Huge promotional thing for getting social media traction
    • Because it was in at day 1, it hit at the peak of their own marketing
  • “If there’s no fun then what is even the point?”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s