HandmadeCon 2015, where even the welcome banner is handmade

Today, I attended HandmadeCon 2015. HandmadeCon is the first convention for the Handmade Hero project by Casey Muratori, a game industry gun-for-hire who most recently worked on The Witness, the follow-up game for Sophia Blow, the creator of Braid.

Key takeaways

There was a ton of material in the interviews. Enough so that I suspect if two people wrote down their takeaways, they might have wildly different lists. Still, here are the takeaways I had:

• Quick iteration is king. Working towards faster turnaround time is going to deeply impact overall quality.
• Lock-in fundamental game choices as early as possible. Examples: game controls for platforming, game speed for open-world. These impact how you design levels, and any change may cause you to have to redo levels, puzzles, assets, etc.
• To work in the game industry you need to show both self-motivated passion and curiosity. The rest can be learned.

Format

Casey (right) interviewing Sophia Blow

Casey has hand-picked a list of game developers with deep technical experience for the conference. With each developer, he interviewed them about their strengths and would tease out the key points from the discussion, often drilling in to learn more. I hadn't heard of some of the people he'd picked, but I quickly realized he'd hand-selected each for their specific expertise in gaming, whether controls, code layout, networking, design, or ingenuity.

Tommy Refenes

Super Meat Boy

Key quote(s)

• "Best way to get the best work out of people is to give people a way to give you the best work"

Assets pipeline

• Original asset pipeline used JSFL to output texture files with indexing from the Adobe Flash tools
• Now he just works with the SWF directly. He (gasp) read the SWF manuals.

Movement

• Spent three months perfecting controls using a square that jumped around the screen
• Movement was built on a set of hand-coded equations whose parameters were tweaked until everything felt right. He offhandedly called these "garbage numbers/equations"
• Rather than being real-world, everything was based on how it played
  • Eg) 200ms of grace time where meat boy sticks to the wall, allowing you to press the other way and then hit the jump button, or vice versa, to initiate a wall jump
• After the initial controls tuning, they were locked in and did not change for the rest of the development
• This allowed level design to build on the controls
• Explored things like analog, but ended up going digital. Reasons: never want a "half jump" or a slow acceleration

Testing

• Fans are the best testers
• PC is crazy complex, and you're bound to bake in some hardware configuration assumptions
• He's working on crowd-sourced alpha/beta testing platform that he can ship builds out to specific testers

Mike Acton

Insomniac [creators of Ratchet and Clank]

Key quote(s)

• "Adding stuff to the problem does not make the problem simpler"
• "Everytime I hear 'I can just optimize at the end' I want to slap someone" Probably a chain of failures lead to this.
• "Capture and visualize" your data. Actually look at the data. eg) build tools to look at the spacial queries that developers are running.

Reaction to Tommy

• Mike started off with a few reactions to Tommy's interview.
• Tommy's input style isn't garbage, it is real and it fits the input of his movements and output of "Tommy smiles"
• Doing things that are "real world" may actually just be the wrong answer and move you the wrong direction
• He whole-heartedly agreed about locking down controls so you can lock down how levels are made
• On a related note: ovement speed, esp in an open-world game, greatly affect how the engine works because of streaming off disk, etc
• Read the CPU manuals
• BTW, docs are seriously important. Doc your own internal formats, too. This is your key input.
• Also, focus on your own problem and your own game. Too many indie devs mimicking other frameworks/tools.

Hiring a game developer

• Main corollary for game developer success: curiosity
• Demonstrate what you've done with your own willpower
• Learn how to practice, and take practice seriously. Anything else is an excuse. Your career is one of the most important things in your life, up there with family.
• Practice with the goal of getting better/faster and solving the problem. Throw it away rather than keeping it. If it's practice, it's not a project. You're honing a skill rather than building a thing.

Pat Wyatt

Guild Wars, Diablo, StarCraft and more

Key quote(s)

• "Make your iteration speed as fast as you can, because this will determine the quality of your game"

Early network stacks

• Synchronized network models where client and server both had game state and were kept in lock-step
• Warcraft: RTS are not so twitchy, don't need to see effect simultaneously
• Eg) 4 network moves per second, and a move is when you've heard from everyone
• Starcraft similar to Warcraft

Diablo on Battle.Net

• Move from singleplayer to real-time multiplayer
• First idea: Synchronized at first, to help prevent cheating
• Ideally, network model should be separate from UI data, since one is updated by network, and one by the client, and they may be updated at different times
• Problem with synchonized client/server: if you don't do it perfectly, you diverge and it's hard to debug
• Diablo written too quickly to do a synchronized version
• Solution: "Asynchronous loosely-coupled game"
• Each level has a 'master', and the master is the consensus driver for world state for that level
• Replayable log of state that can be given to a new master if the first one drops out
• Game host declares who is master for a given level based on who first entered that level
• State change happens in two steps: "I am attempting to pick up the sword" then master plays through all attempts and break ties
• DON'T DO A GAME LIKE THIS. People will cheat.
  • Griefers will take advantage
  • Ask yourself: "How will people hack this?" "How will people abuse others?"

Guild Wars

• All client/server, all TCP
• Network functionality split across many servers
• File server: handles versions and creates deltas based on what client has available, compresses, and sends update to client for assets in the manifest
• Asset ids automatically assigned by perforce full path
• File servers were put near users because this helps throughput. Related: tcp window and waiting for ack for each packet
• Lobby server: authentication and presence. Arena, instance, etc all controlled through lobby server because you don't have a persistent connection. Helps with p2p messages, guild msgs etc, encryption
• Matchmaking server: will match up servers with capacity with needs of user
• Using tons of servers allows you scale up and distribute across machines
• Network code is shared across all servers. Every server is actually a generic modular server. It just hotloads the specific module. eg) lobby server just loads the lobby module
• Need RPC protocol that supports versioning. These days, things like protocol buffers would work fine.

UDP vs TCP

• Mobile - UDP works great, since you're already going to be losing packets
• MMO - TCP is great because you don't want to lose packets

Network game states

• Failure is always legal. Eg) can't load model file, you don't crash. Instead you get a white box
• Server is authoritative and may pull players back to acceptable state. Also, every client sees their version of the server truth, like the arrow that "bends in space" because target moved

Best practices

• Always simulate network jitter and latency, minimum 200ms, so you are always creating robust networking code
• You will always be hacked
  • Deeply understand your interaction model
  • Rate limiting helps prevent abuse
  • Hiding IP addresses so they can't be targetted for attacks like DDOS

Hiring a game developer

• Demonstrate passion
• Read "cracking the coding interview"

Sophia Blow

Braid, The Witness

• Iteration is king. More you optimize the less you can modify.
• Programming for fungibility to allow for faster iteration.
• Program for a decoupled system, as much as possible. This includes game mechanics, types of puzzles, etc
• Doing programming as a game designer, you can more closely point the best way forward in the game design as you know exactly what's possible
• Programming as a designer also helps you explore more of the design space than you might otherwise have. Eg) in Braid the enemies unaffected by your time travel.
• Good design can often be a search space with a seed value and things that seem like time wasted, but that's part of the journey.

Ron Gilbert

Secret of Monkey Island, creator of SCUMM

• For Maniac Mansion, C64 was hooked to a Unix/Vax machine with hotloading to C64. This is how they could swap out and do fast iterations
• To learn how to do an interpreter, he banked out BASIC ROM to RAM and then manipulated it. Cool hack.
• For pathfinding, used dijkstra's algorithm with rectangle shapes. This evolved over time.
• Later games used seamlessly stiched-together soundtracks that changed as the player progressed.
• Cutscenes, which came from Lucasfilm games, were originally hand-scripted. They had to "cheat" a little so the player couldn't interrupt the cutscene with their own movement. Eg) Making the character the player was following appear far enough ahead of the player so that the player couldn't run in front and interrupt animation