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 Jonathan Blow, the creator of Braid.
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.
Casey (right) interviewing Jonathan 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.
Super Meat Boy
“Best way to get the best work out of people is to give people a way to give you the best work”
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.
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
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
Insomniac [creators of Ratchet and Clank]
“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.
Guild Wars, Diablo, StarCraft and more
“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?”
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
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
Read “cracking the coding interview”
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.
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