Exploring SimCity: A Conscious Process of Discovery

[Music] hello everybody thank you for coming my name is Dan Moskowitz I'm the lead gameplay engineer on the new SimCity and I was also the lead engineer on the editors first floor I've been working at Maxis for over seven years I was originally drawn there by wheelwrights 2005 GDC video where they showed the prototype is spore and I just thought anyone that any team that's willing to make something that crazy that's a place I want to work so Maxis is this wonderful place it's filled with a lot of brilliant people and I've learned a lot during my time there and one of the things that I've learned most of all and that's what I'm here to share with you today is a particular philosophy about game development it's a philosophy based on building simple systems and then discovering the fun that's inside so let's get started here

Oh hold on a sec let me just let me just get online so just take a second oh you know what so let's just let me just wait a couple minutes and then and then I'll try again okay all right so what can you do about laughs right as you all know our game had a really rocky launch filled with server and connection issues and well most of my contribution to the game happens after the login screen and after the front-end as a member of the team I apologize to anyone here that experienced frustration I know it was really frustrated for a lot of people and as fellow gaming developers I hope you can understand that the first few weeks after launch were like an emotional roller coaster for the team you know we created this game which people really loved and were attached to and then we're frustrated by the

inability to log in in place oh and for those of you and the audience was rotten tomatos anyone that wants to talk about offline or online only requirements I would happily direct you to our PR guy over there so I'm not here to talk about that but what I am here to talk about is his sandbox games so this is the kind of game that SimCity the category of game of SimCity falls into and I looked around for existing definitions of the sandbox game and a lot of them referred to like an open world specifically or made reference to a game character so here's a definition that I came up with it's a I would define it as a goal free exploration game where the fun is derived from discovering how the game mechanics work and I like this definition because you can literally apply it to sand boxes you know like plastic shovels and buckets and sand and gravity it's it's no wonder we have one of these in every single playground across the world when you're a little kid you're just learning the mechanics of the world it's this perfect place to

try scooping and digging and smashing building and when you're discovering these mechanics and you're building these pathways inside your brain and and you're building up a mental model of how the world works and it's really fun and I believe that sandbox computer games give you that same experience of wonder and discovery but with completely new and novel mechanics that aren't possible in the real world so here's four examples of sandbox games SimCity 2000 minecraft bad piggies which my three-year-old kid is crazy about the sandbox mode in there and World of Goo and each of these is built on top of some novel mechanic like map based simulation or Springs or physics construction sets and some of them do have goals built in but all of them are built around the idea that the fun is about the lettering letting the player experiment by trial and error you slowly build up a mental model of the underlying systems that make up the game and the fun for a lot of players is get to get to a point where their mental

model of the game is strong enough so that they can run a little simulation of the game in their own head and then predict the outcomes of their actions the other important property of many sandbox games is that they're composed from simple parts so these small pieces are part of building blocks of the game and each one is encoded with some relatively simple behavior or some relationship to the other pieces but when the player can freely assemble them together and play with them in a game world that contains this novel mechanic that's where the magic happens and where you discover these incredibly rich and sometimes surprising behaviours so to me this is what's exciting about game development and as a programmer the process of creating the rules of a new universe and populating it with some simple pieces and then discovering what they all do when they're mixed together that's fine and that's where I find enjoyment in my work so if you're building a sandbox game you need a novel mechanic to start playing around with and as far as this talk goes I can't really help you come up with that that's

that's up to you and that's the defining characteristic of your game but the key is to start with something simple for example a World of Goo started as a one-week student prototype with nothing but the word springs to inspire it and there's plenty of examples of interesting mechanics that spawn from game jams physics shadows the fourth dimension the important thing is that there's just enough richness to the mechanic that it creates a big enough possibility space where you can start exploring and once you've got something that you can play around with then you're in a position where you can Berryman to start start discovering the gameplay inside are like squeezing the most juice out of it and Maxis has a history of creating these kind of games so today I'm gonna talk about some of the things that I've learned about making sandbox games over the past few years with plenty of examples from the new SimCity and my hope is that I present this information in a way that's useful to you so that you can come away with some practical advice that relates to your current game development challenges but first I'd like to talk about our novel mechanic and that's the one we used to create SimCity and it's a

bit more complicated it's a simulation engine called glass box glass box was developed by longtime metrics Maxis veteran Andrew Wilmot and it allows developers to quickly create completely data-driven simulations with thousands of objects interacting it also has a nice architecture for game play engineers to plug in code to control the movement of agents or to drive graphics based on the simulation or to add folks for scripters to send events to the UI into the code it's also fast in that it's capable of handling thousands of objects or units and tens of thousands of agents and now this talk isn't specifically about glass box but it's about how we used glass box as our novel mechanic to create Sim City but in order to give you some context for some of the things I want to talk about I'm gonna give you a quick quick crash course in glass box and some of the terminology around it and if you're interested in more information there's a much more in-depth deck about glass box that's on

andrew's website from our GDC talked last year okay so glass box it's a resource based simulation engine resources are the basic currency of the game so they're essentially variables they're defined as integer values with a fixed capacity and they can be stored inside various simulation objects like units or agents or Maps which I'll talk about in a second they can be tangible things like people or coal or parked cars but they can also be intangible things like money or pollution or electricity so units are the basic building block of a simulation so in Sim City they tended to be just building but there could be anything depending on what you're building and for example some of the disasters in SimCity like the tornado was actually a unit that moved around and ran a simulation they use rules to change their simulation state that's what Barr scripters are

actually authoring a bunch of rules and their state is defined by the resources that they contain so for example here's some examples of three units we've got a house that has some people in some cars and then the water tower that's got you know 75% water and then an oil power plant that's filled with oil and has some workers in it so maps represent resources in the environment so things like forests or pollution they're just essentially a grid of integer values so for SimCity that was our grid size but it's totally variable here's just an example of what a map might look like so the water table from in-game we were using the map value there to tint the terrain so you can see where water is in the game world this is just a quick video of using one of our debug tools to paint ground pollution into the ground

so it's just you can see the ground pollution going up and then the texture underneath there is reflecting the state texture on the terrains reflecting the state there yeah we can also use maps to distribute various effects like the location of forests or puffs of air pollution here's a picture of a forest of trees that's being distributed by the underlying forest map so rules are the verbs of the simulation they allow for scriptable simulation behavior and if I had to compare the rule scripting language to something else I say it's most like an assembly language where you're simply moving information from one register to the next it's a declarative language so there's no looping but there's certain ways you can chain and branch rules together so that the scripters can create simple logic and each rule is an atomic operation meaning that when a rule is tested all this it's in the rule must be able to succeed for the rule to be run I'll show you an example of that today I'm just going to focus on unit rules but all sorts of

different entities and GlassBox can run rules so here's a simple rule this is a example rule from our smelting Factory in games is one of the things that the players can put down and it converts or and changes it into alloy and if we look at this example rule it's tested at a rate of every two sim ticks and it applies one time and it takes ten local or in which means to subtract it from the local or resource and and then it produces 15 Ally so if the unit has less than 10 or the rule won't run or if the unit doesn't have enough room and alloy resource bin to produce 15 alloy it also won't run so the most basic kind of rule it just as a simple resource conversion at a constant rate if we wanted to get slightly fancier we could add a line that writes out a hundred pollution to the air pollution map and also trigger a success event which can send the message to the game triggering a pollution effect and you can see it coming out of the smokestack there from a different angle here's like a debug representation

of that map and it's writing out air pollutions with the nearby cells on the air pollution map getting even more fancy you can add a fail event which can send an alert to the game and the UI system which in turn can turn on some messaging about the state of the object in the UI so that's a brief overview of the simulation units and the rules and I want to talk a little talk about the simulation agents as well so agents or transactions are the main way that information is transferred around the simulator they can be created by units and liking it's they carry resources because there can be tens of thousands of them they don't run any simulation rules and when they're created they're given a particular plan to follow so they're always headed toward a certain sink or destination for example a rich person walking to find shopping might be headed toward a very specific sink like a well three shopping sidewalks and here's just an example you know this is a person he's an agent he's carrying some resources is a wealth one guy he's

not sick he's got a little money in his head he's headed to work and then here's an example where we've got three factories they each have that work sink on them and then you can see the tiny little circles up in the corner are some people walking to those to those specific sinks another example is an agent carrying water and since this is an unrelated city it's not carrying any germs but if you can loot your city it might be carrying some germs and it's headed toward a water consumer sink and most buildings in the game consume water so they all pretty much have one of these sinks on them and the behavior of a specific type of agent is controlled by a transport handler which is custom game play plug-in code the obvious handlers that we knew we'd have to create for SimCity where the vehicle and the pedestrian handlers which turned out to be quite complicated and ended up having an engineer dedicated to each one for the entire length of the project the

vehicle handler controlled behaviors such as the global routing changing lanes passing dealing with traffic lights stopping for pedestrians emergency vehicle behavior and so on and the pedestrian handler controlled behaviors like stopping at crosswalks or walking into buildings avoidance of other pedestrians in a crowd and also some emotional behaviors to give the players some storytelling like grouping together or stopping to talk to each other even though it didn't actually mean anything in the simulation but throughout the course of the project we ended up discovering some other uses for agents and implementing some different unexpected types of transport handlers this pipe handler was a simplified version of the vehicle handle it used the same routing system but had some additional tweaks and we ended up using that for power and water and for sewage but as well as some more interesting hidden things which I'll show you a little bit later we had a radial handler which was literally that this agent spread out in a radius wave front and it

transacted with any sinks that the wave passed and then also we had a signal transport which is which was essentially a timer that the scripters could use where they would send out an agent and it would stay out there for a fixed amount of time and then come back and transact with that same unit so they could kind of delay a message using that here's an example of a unit rule creating an agent in this case this coal power plant is testing a rule every 16 sin ticks it's using ten coal and putting it's taking 10 coal out of itself and then putting 10 power into an agent and writing out some air pollution and then sending that power off to power consumer sync also playing a little sound so that's the end of the glass box overview and should give you some context for the rest of the talk so now what I'd like to do is share some lessons learned from making sandbox games at Maxis and I'll go through them one by one with some more examples and while these examples are specific to SimCity they're general enough lessons

that I hope you could take them back with you and improve your development process or avoid some of the same pitfalls that we fell into while making SimCity and of course some of the best lessons are learned from failure so hopefully by sharing these stories we can all fail a little bit less together so the first learning I'd like to talk about is to determine the granularity of your game so what do I mean by granularity well let's say you've figured out how your game mechanic is going to work and you've got some kind of prototype going on and now you're in a position where you can start playing around with the pieces so for example in world of you you know roughly how many interactions does it take as the player need to complete a compelling level you know is it 20 or 200 or 2000 and in Minecraft you know how big are the blocks relative to the player or how many resources do you need to collect to craft something or how many blocks might it take to create some shelter in the game or how large does the grid need to

be or the world need to be for the vehicle creation in bad piggies um so these are the kind of questions that we were asking ourselves in the very early stages of sim city's development and I think it's a critical first step to ask these kind of questions because so many different decisions hinge on their answers so one of the first questions we had to address was the size of the play area we ended up going with 2 kilometer by 2 kilometer space which is equivalent to the medium-sized city and SimCity 4 and we chose this for a few different reasons and one we wanted to be able to have a richly detailed simulation where every person and vehicle could be represented as an agent and every building could run its own simulation rules and this isn't a typical open-world kind of architecture where we can just unload the people in the vehicles once they're a few blocks away from the camera each one of them was holding some specific resources that were important to the state of the simulation so you know while we didn't necessarily have to render them we had to keep them active we had to keep them going toward their destination so that

said you know bigger is always better and a lot of people wanted bigger cities obviously but the other pressure is that Maxis games especially SimCity are fairly mass-market so our min spec machine is more in the range of you know your dad's computer rather than the top-of-the-line graphics card and CPU so there was some trade-offs to be had because of this the other thing we needed to figure out was the level of detail that we need to simulate our buildings in SimCity buildings fall into two different categories there's the ones that the player places themselves and then there's the ones that the sims spawn on the Left we've got our CI buildings or residential or commercial and industrial and to create these the player marks out zones and then the simulation spawns them automatically and on the right are the buildings that the player places down themselves and we call them we call them toys internally on the team and these are the buildings that provide city services like fire stations or universities or bus terminals and we

knew that we wanted to be able to compose the buildings up of smaller parts but we weren't sure at what detail and at one point we thought that skyscrapers were actually going to be you know stacks of units that each one was actually controlling simulating 20 floors of the building but we quickly backed away from that is it was just getting too complicated so however we did want the the toys to be made up of different parts where the fantasy for the player was that they're getting this collection of toy pieces that they can kind of dump out on the table and then assemble you know they're they're amazing fire station or they're amazing power plants that was one of the motivations there and and for this specific thing the design motivation was already there because in previous sim cities you had a budget slider for your city services so slide it up and you could pay more money for the effectiveness of your medical system for example and we wanted to take that slider and break it down into a fun way so that you could construct buildings out of parts for each part costs you a little extra money so a more of a

granular way to deal with that issue in your city and we had no idea how many parts would be fun or how detailed they needed to be so we started prototyping and these are some early prototype pictures of water pumping facility in a coal power plant in the middle there's the the pallet for the parts of the coal power plant that we were building we had three kinds of generators two kinds of smokestacks a power transmitter a coal supply lot a cold drop-off port and two kinds of conveyor belts and it let you build this awesome simulation of a power plant with all these moving parts but the problem that we found pretty soon was that it would fail in all these complicated ways your power production could be stifled because you didn't have enough smokestacks or the thing would overheat and catch on fire and it just wasn't that much fun or it would have needed way more UI than we had time for to make it fun so we soon realized that we were going down this complexity rabbit hole and we eventually discovered some key learnings about these things we

found that in order to strike a good balance between functionality and customization each building that you plopped down had to function 100% on its own and the modules you add must only supplement this functionality so we realized this after we realized this it became a lot easier to develop and design the different toy buildings but we had to go through this process of discovery first so here's a video of placing a large Hospital down and adding some parts to it and this is with the recent game that's loud so this hospital you know by default can handle a hundred patients and then you can put patient rooms down that just simply add to that capacity and a bunch of other parts as well you can put an ambulance Bay down and what the because it literally just gives you one additional ambulance that corresponds to that can respond to injuries a few other

things I want to point out and in this picture the this hospital that the player made it is made up of eight parts but there's a very simple hierarchy here and you can see that with the yellow lines in the base module which is the first thing that you plot is the is doing the bulk of the simulation but in the simulator it's connected to all the other modules and that allows them to run rules which can share resources or operate on each other another picture of that here's a wind farm so you can see this relationship between the base building and the windmills the windmills actually produced the power and then the base building has the rules that transmit the power the other thing that we came up with pretty early on which the art team really needed before they could go all-out creating content was determining this cubic meter granularity for the buildings we also came up with a simple snap point system that allowed for the artists and the designers to set

up male and female snap points so they could determine you know and give the player valid places for these things to attach so here's some examples of the various ways we've figured out the granularity for SimCity the process of figuring this stuff out is gonna be different for each game but in my experience you want to sort out these kinds of details and questions as early as you can because determining your granularity informs all sorts of other decisions about content the scope of player interactions and the complexity of the simulation so the next lesson is all about discovering fun patterns in your game and then exploiting them and reusing them over and over as we were experimenting with glass box and playing around with the simulation we started discovering certain patterns and things that were relatively straightforward to implement and went along with the grain of the simulator and a lot of these had to do with the use of agents so we knew we were going to use agents to represent people and vehicles but we soon

discovered some other uses for them and I'll show off some examples this was an early attempt using radial agents for power transmission and the windmills would create a radial agent carrying power and then it would deliver that agent to any of the buildings that had the power consumption sync and it wasn't very realistic and it's not what we ended up doing for power but we ended up using this radial handler in other ways for example when you plop a park or a town hall in this video we actually send out this radial wave of happiness and it's not just an effect that's actually an agent that's transacting with all those buildings giving them a little bit more happiness and happiness is what eventually causes buildings to go up in density so here's another example of transport handler this is the pipe handler that I was talking about earlier so it's a simplified vehicle Handler and

it doesn't have any notion of lanes or the agents blocking each other it's just using the raw routing this is the video of a small city powering up [Music] you know that all the dynamic lights on the building are driven directly by the power resource inside the building [Music] also in this example there's there's only one source of agents which is the power plant but there's hundreds of sinks but we discovered that we can flip that around and reverse that and create a sewage system so every time a building consumed some water that produces sewage so here's a video of where we're plopping a sewage output pipe and here there's hundreds of sources of agents and only one sink and that actually sent

out a little radio radio wave of sadness we've got that now what's happening here is when the sewage agents get to this output pipe they're actually writing Brown pollution into the ground right there so it's a way of concentrating that ground pollution rather than if you didn't have it all the houses was right out of the ground for yourself and they were playing some effects when that transaction happened actually see visualize the poo so we also discovered rather than aside from just power water and sewage there were some other ways that we were using these pipe agents we found that we could use them as a call-and-response system so I'm gonna show some videos that have some debug stuff on and this is usually invisible to the player but in this video a building's Catching Fire in the back there and it's going to send out yeah there we go so that is an invisible fire alarm agent and that's transacting with

the fire station and then that that bouncy-ball is a timer that's delaying the sending of the fire truck there we go fire truck is gonna go out and we're gonna see another house catch on fire into the bottom and send out another alarm so you'd see that each each fire station garage actually has its own sink for this alarm so that it can send out its fire truck and we ended up using this kind of pattern in this call and response pattern for almost all the Civic buildings ambulances respond responding to injuries or police responding to crime there so on this is another example of how we used it for the RCI buildings this is an RCI building that's opening for business in the morning and it's sending out a call for workers so the workers come in there and then it sends that now that it's open for businesses sends out a call for shoppers and the shoppers there we go now some people are gonna go shopping and when they do go shopping they get

converted from their car or their person into the signal timer so they're the shoppers are actually represented as these bouncing balls and want to come back down we're gonna send them out with happiness so here's that same pattern but in a medium-sized city and I kind of wish we had shipped with some of this debug stuff in because I just love watching the complexity that's going on here when all these different buildings call for workers and call for shoppers and you can actually see what's going on in the simulation so anytime you see the blue bouncy balls those are shoppers that are currently shopping at the building and one final example that pulls this all together this is a meteor strike disaster so if you watch closely you can see this initial radial agent that's triggering houses to panic so they turning out their lights and they're sending people out onto the streets and then the meteor strike will

happen here boom and that sends out a wave of heat that's then causing a bunch of houses to catch fire and each of the houses is actually spreading heat as well with these little red radial agents so that's how fire spreads in the game it's just a disaster there's a fire truck okay so so yeah yeah so as you're exploring your core mechanic just always be on the lookout for patterns like these that just work or that just feel right and then latch onto them and reuse them as much as possible and you might find that you only need a handful of these to actually make your make a great game so the next learning is that it's really important how you're gonna figure out how to scale your sandbox game

building a sandbox game is especially tricky when it comes to performance because you have to constantly be thinking about the absolute worst-case it's easy to fall into that early game performance trap thinking that you don't have performance problems when you know everyone's workflow involves starting a new game from scratch and we had to take some careful measures that performance would hold off on large cities so for example it was almost never okay to just loop over all the agents or all the units we had this bucket them and different sinks and operate on them that way and for the routing we had to you know round-robin through all the different sink types and then only propagating the navigation information for one of those per frame and when it came to tracking performance it was really important that we set up proper metrics on a variety of cities over the course of the project we actually ended up with a pretty cool automated system for building cities and tracking frame rate and memory metrics the gameplay team added some hooks to all the player tools like zoning and Road draw and

flopping buildings so that when they're invoked they spit out a command of the console and then you could build up a city and then copy and paste all those console commands into a test script allowing us to procedurally recreate the city and this was better than simply loading up a save game because if the simulation changed we one of those changes to be reflected from the very start and then we created a variety of cities an empty one for baseline comparison a small city and a target city and then one for graphics performance that had background cities and we use that one at different zoom levels and also with the simulation pause and unpause so that we could isolate different CPU or GPU differences in isolation so and after that our infrastructure team built up automated tests that would create these cities and measure framerate and memory and collect this data as graphs and metrics on a webpage and this was really invaluable because when you're working on a simulation one

tiny tuning change can ripple through the entire game spiking up the number of vehicles or pedestrians or at one point doubling the number of sewage agents that you know from the simple tune change so it was really vital to be able to keep tabs on this stuff on a daily basis to be able to look at these graphs and go back and forth and see how you know something crazy changed on Thursday so even when we solve for the target target case there's still this pretty big collection of worst-case scenarios you know it's possible for the player to intentionally build the worst case traffic jam where they don't put any public transit and it may not function well as a city but it still needs to perform on your CPU and on the other hand you could build row after row of high-density residential and commercial skyscrapers causing thousands of pedestrians to roam the streets because they choose to walk instead of drive so I remember once loading up one of the cities from our internal population leaderboard and being shocked to discover that there were 68,000 pedestrian agents live so we had to do

something about that but changing the simulation wasn't really the right place to do that because we had to keep the integrity of the simulation going but what we ended up doing was you know if there was a certain over certain threshold of vehicles or you know that were stuck in traffic or pedestrians that were walking around we started picking and choosing ones to teleport to their destination so you know it was a good good trade-off between performance and keeping the simulation without sacrificing the simulation integrity okay so the next lesson learned is about exploring your game and your mechanics in a breadth-first way so you know what do I even mean by that well I like to think about our gameplay effort as falling into four major categories there's the code driving the car mechanic so that was glass box in our case coupled with the simulation rules which are the data and then we've got input and output in

the form of player tools and then feedback and these arrows represent relative effort spent in the four areas so I made the core mechanic ones longer since you generally start there so in my experience it works best to slowly build up in layers you want to do a breadth-first search through the possibility space of your game so for example you know you might add some data to the game simulating criminals appearing inside of buildings and then you find that you need more feedback now how does the player even know that it criminals inside of building and now you've got a problem that the player knows about and they once they want to solve so you give them some tools to do that and you know you just kind of go through this little bits at a time and you know don't go out too far on the limb and maybe at some point along the way you realize you actually need to add a feature to the core mechanic but by this point you'll have justified that need for that feature because of actual gameplay experience and I think that's a key learning is that you always want to justify your development effort based on

real user feedback and based on gameplay experience so what are some of the dangers of ignoring this lesson usually involves wasting time and effort on things that aren't important so on SimCity we did this a few different times once was with our player tools coming off of Spore and the building editors we had this idea that we wanted the building construction to feel extremely creative and physical and tactile so we ended up going pretty far down a hole with physics based manipulations with Springs connecting the pieces being able to stack them up and so on so here's a video I saved from a couple years back when I was working on this stuff it was pretty cool and it was fun to work on but it it ended up being completely irrelevant for a number of reasons for one thing it didn't make sense given our eventual snap point granularity for a building to be at some non right angle and also while we didn't know it at the

time players wouldn't actually be spending a very high percentage of their time editing their buildings that turned out to be a relatively quick operation like buying an upgrade with less a degree of tivity than we originally thought another black hole we went down was related to the simulation rules and we did this a few different times but here's a good example as we were getting the basic RCI simulation up and running we thought it would be a great idea if we could tune the exact hours that each building was open regardless or for each wealth class so if you had an office building where the janitor you could have the janitorial staff show up at 6 a.m. and then the middle managers show up at 9 a.m. and the executives could pop in for an afternoon meeting and we tried this and it created a lot of rules and tuning variables that turned out to be quite a nightmare to deal with and pretty soon we realized that this was a terrible idea it spiked the rule count

and the complexity the tuning forks balked at having to generate so much extra data per building but most importantly as a player you didn't even notice this happening at all so and by the way what we ended up doing is having a 6:00 a.m. to 6:00 p.m. work shift for all the building it's except for two exceptions there are buildings that ran 24 hours a day and also special ones that were open late at night like night clubs and things like that so that's really all that we needed to create that feeling for the player so the lesson here is to resist focusing too much effort on one part of the game in isolation you know resist the temptation to delve too deeply into one facet of exploration until you're sure you're on solid footing with everything else so the next lesson learned is about balancing the effort that goes into code versus data I found that in my experience working as a

programmer there's this delicate balance between the amount of effort that you put into engineering a system versus the amount of effort that the client of that system whether they're an artist or a designer puts in so in a perfect world there's this ideal amount of back-and-forth going on the engineer implements an initial first pass and then the content creator goes off and plays with it for a while and they say you know I got to this point now I need his future and and you just have this nice iteration with nice tight iteration loop and part of me feels like this ideal balance comes from simply having respect for each other's work you know when these collaborations work well you're in the zone as a team and but if there's not enough communication or people's goals aren't aligned it can go sour so I've seen how it can go bad if the balance is off and I've watched engineers completely over implement in isolation creating features up front that they think might be needed but all it ends up doing is bloating the code and introducing complexities and

complicating the process for the content creator and on the other hand I've seen content creators go off into a silo and attempt to just make do with what they've got but this can have negative side effects as well that are just as bad but they'll end up stretching and bending the system in ways that it was never designed to handle causing performance problems or data bloat that it could have just been solved with the addition of some simple feature if they'd just been in better communication with the engineer here's an example from SimCity where I think we actually struck a good balance for some context in the game pedestrian pedestrians and vehicles are agents they're carrying information and one of the challenges that we had is that when an agent actually arrives at a building it commits the transaction so it's dumping the resources into the building and then it's gone so there's this disconnect between the players fantasy of what's happening versus what's really happening in the simulation and one of the ways we got around this was to create a little animated and yet of people moving around

the building doing some behavior giving the impression of activity when the building was in a certain simulator state so here's a quick video showing off some sims constructing a building and the only real simulation that's happening here is that there's a timer that's constructing the building and every time you see the building lift up that's actually just a simple resource changing you know increasing all the movement of the people are just set up by an artist so building this vignette system was one of the first projects giving given to one of our new play engineers and since we weren't sure what the scope of this feature was going to be or how often we need to use it I suggested that we just started small and tackling the immediate problem at hand with the least amount of work so the simulation was in a pretty basic State back then but we knew the buildings were gonna need to construct and it was looking pretty dull at the time so I thought that would be a good starting point to work on this and it turned out

that the minimum amount of work is pretty much what you'd expect it's a list of points for actors to walk around and some simple tools to set that up but once that was done we took a look at now you know what are all the vignettes that could now be created just using simply this code the artist was off to the races filling out content throughout the game where they could and while that was going on we could now look at what vignettes we still couldn't make with the current code an example something was the garbage pickup where the agents movement had to be relative to the garbage truck and relative to the trash cans they could walk back and forth a couple times and this would you know this required the ability to add asbestos the ability to specify a point relative to some object so you know that's what he worked on next and this cycle continued and this example isn't that complicated but my point is that you want to tackle these kind of problems in a way that you're consciously facilitating is back and forth between code and data as I've found that it produces the best results

and here's just a nice video of a couple vignettes for at the end of the game here we had a baseball stadium and a soccer field and they're running a bit more complicated more complicated data they all also scale up and down the number of people depending on how many people are actually how many sins are actually at these parks so in order to discover interesting patterns inside your mechanic you've got to be able to see what's going on so there's next lessons about exposing as much data as you can be a debug draw or whatever is available and playing and developing your game with this information overload enabled and then

picking out the pieces that are important that way so if for SimCity we relied heavily on various debug drama modes to expose what was going on this is just an example of a water tower running a rule that's subtracting water from the surrounding water table this is the debug mode for the vehicle transport handler so it's showing off the destination of all the vehicles as little hovering disks above them and then where those open sinks are on the buildings and the colors of the sinks and the destinations all match up it's also showing some of the simulation state at the intersection so the traffic lights and the splines that vehicles are generating to make their turns then this is a picture of the zoning system internals you can see that the streets are broken up into these eight meter parcels to match with our snap point granularity and the green outlines around the buildings represent the claim space so as our as our team of scripters

began to ramp up creating more simulation and new behaviors that became harder and harder to understand what was actually going on inside the simulation especially in larger cities and this was pretty scary because it made us question some of the earlier choices about granularity maybe when you're making the simulation too complicated so at one point very early on I wrote some code to simply print out the amount of garbage next to each building data-driven way to do this so the descriptor could fix a bug with the garbage system we already had plenty of tools to inspect the simulation state but the simplicity of being able to see a single system represented in isolation that was that was a big win and that was something we hadn't really done before so we immediately saw the value of this and and latched on to it and it eventually turned into this data layer system that's in the game today this is a way for players to expose specific about a particular slice of the simulation this is actually what the garbage layer looks like today it's a

way for the player to just turn on a mode and just see what's happening only with garbage in their city they can see the amount of garbage and they can see the garbage trucks and they're called out where those are there's a whole bunch of different data layers that you can add you can turn along so here's a really early video this is the first time we tried representing data as as bar graphs so the height of each bar here represents the number of people in the building and the yellow buildings are industrial and the blue are commercial and this is like at 6:00 p.m. when everyone's going home and you can see some pedestrians walking home and filling up the green bars which represented the houses of course there's stuff on fire too I also just love looking at the early early stuff fond memories and here's an

example of that population layer today running out of big city so you can really get a sense for the movement of information and agents that are flowing around your city another good example is with our vehicle and festerin transport handlers we headed to bug mode where you could see this color circle about the agent telling you which type of sink it was headed towards and when this was enabled it immediately exposed all kinds of meaning behind the agent behavior and when you play with this on you kind of discover interesting things that were going on or even bugs and we we tried to find opportunities to expose this data to the player in surprising ways and one of the ways we did that was with this mad libs style sentence that we would come up with based on what we knew about an agent so you know we knew as yet had a unique ID we knew he was headed to a certain destination and we knew what

resources he was carrying so you know this guy is going to toy work wealth 1 which essentially means a city job as opposed to our CI job so we could come up with these mad libs so walking to his poorly paying city job so this is how we just you know a little fun joke for the player where you could click on anyone and get this little sentence about them and that would actually tell you something about what's happening inside the simulation so as we built up the game and the feedback in layers it took us a pretty long time to discover what information was actually important to the player the core loop of the game had to come together enough until we were able to realize what to expose and how to expose it so the takeaway from this lesson is that having lots of visualization tools at our disposal during development helped us to debug and helped us to digest the simulation what was going on so you know put as much of that stuff in as you can and the next learning is is I think one of the most important learnings for a sandbag

name is to don't seek out complexity it will find you and I realized it's pretty general statement and it could be a lot of it could be applied to a lot of games and even just to software engineering in general but I can't overstate how completely Eagle complexity is in the particular case of a sandbox game as you're working on the game especially once your team is bigger there's this tendency to want to just take what you've got and add you know just one more layer of complexity to it and this happens when someone's working on a feature in isolation without the context of the rest of the game but the thing you have to realize is that once you take your simple pieces and you let the player compose them freely that in itself is a complexity explosion so you know complexity is going to rear its head during your games development whether you like it or not so don't give it a head start by over designing the individual pieces I find it's good practice to constantly ask yourself you know what could I remove from the game or if we didn't do feature acts you know what else might we be able to improve

and I like this quote that I saw fly by on Twitter a couple months ago ambition limits polish for many games and especially those at larger companies there's this one resource that's completely fixed and that's the amount of time that you have until you have to ship so is the new feature that you want to add like so important that you'd be willing to sacrifice polishing what you've already got the fire simulation is actually a good example in Sim City where we made this mistake early on in the project we chose to fully implement this part of the game so that we could get an idea of the effort that it took from scripting and from engineering and art and so on so that then we could schedule out the rest of the game and we really went down a rabbit hole with this this was about a month of work for 12 people like you know a couple years back I managed to capture and save this little video and here's all the crazy things that we were doing in this video you know we had little agents instead of

and yet people that would actually when the fire truck arrives it would actually create a unit there and little people would walk back and forth that were actually transit thing with the house reducing the fire the number of people that showed that that actually came in the truck were based on the number of people that were working at the fire station at the time there was this dispatch tool and patrol markers for the fire trucks that you could plop down and it was just we just went way overboard on this and and in hindsight it violated two of the other learnings I've already mentioned which is breadth-first exploration and also the granularity but you know hindsight is 20/20 and at the time we just didn't realize the ridiculous scope of the game that we're trying to make so there was a lot of pressure to demonstrate how cool this single system in isolation would be but the problem is it can't really look

at a single system in isolation you have to look at it within the context of the rest of the game so when we took a microscope to the fire system it just made us feel like there wasn't enough there and forced us to make it more complicated so just be careful of that trap so one thing I like to think about is like you know those moments where someone comes up to you and asks you for a future request and sometimes it's trivial and easy-to-implement you go ahead and do it and otherwise it's clearly outside of the scope of the current system so you can say no but for those times where it's sometimes somewhere in between if you're trying to decide whether it's worth the bang for the buck I would urge you to consider taking complexity and future effort into account you know you might add the future and be the hero and then a month later you realize you actually spent quite a bit of time more than you thought that's gone into that feature with you know bugs or iteration or just some tool change that like confuse

people some human elemental problem and if you hadn't actually implemented that feature it's as if you magically get back all that time and effort spent which is which have would have gone to other things so you know I'm not suggesting that you just go around saying no all the time but I think as an engineer it's important to keep in mind that saying no is one of your tools and sometimes it's a really powerful tool and if you think it's in the team's best interest to not go down a particular path you should speak up and make a case for that so toward the end of the project it became apparent that our scope was so big that we were standing on the edge of this giant chasm of possibility space and for better or worse no one person on the team could even explore the whole thing or not not the time we had left and of course we had a whole team of QA testers exploring the game as well but there was just so much that you could do and so many ways to combine all the pieces so that was a bit scary and it felt like the team and QA were able to explore up to a certain point before

ship but then in a matter of days after shipping Locker servers working our combined players came along and just you know blew that exploration out of the water finding little oddities and problems at the edges of the simulation many which we're addressing right now with patches so I hope to take away from this particular learning is that you all go back to work next week and rip the future out of your games so here's the list of all the learnings you know SimCity is such a complex and layered game that early on in development it felt like we were pushing this boulder up the hill for a while the depth of the simulation wasn't there and the feedback wasn't good enough and we couldn't even demo the game without literally standing next to someone and telling people what was happening inside their city and as time went on the simulation got stronger and the UI improved and we reached this magic moment where we felt like the boulder finally got to the top of the hill and then started rolling down the other side and we'd have we'd had people play the game and instead of being

utterly confused they were telling us obvious things that we needed to fix like this tuning isn't right or I need more feedback about which buildings are on fire and that kind of thing so we got to this point where instead of us pushing the game up it started telling us what to do and I think the good goal of any sandbox game developer is to try to reach that magic moment that point in your project as soon as you possibly can as early as you can and I hope that some of these learnings will help you get there sooner so thank you very much I also just wanted to thank the team at Maxis everyone worked really hard to produce the game and they're still working hard on updates and fixes because we really care about the game we really care about our players one thing I just wanted to show you quickly before we do questions is a video that was put together by one of our engineers this was the engineer Richard Schumacher he

was working on the data layer system and he made this video to show off the data layers system but I think it shows off a lot of cool things in the game so I can actually get it running time [Music] awesome there we go [Music] [Applause] [Music]

people leaving school giving education to all the different houses nearby there's a garbage layer with garbage trucks picking up garbage mr. that population layer people are going shopping and going work these are buildings being constructed and going up in density with happiness [Music] all right

okay so we have booked time for a couple of questions yeah about how much randomness comes in when you're doing the sandbox games especially with SimCity because like one of those things we showed there was the customers going to a shop to purchasing something going home again kind of like as soon as they got that request to go to a store they would leave their house and so because there was five pounds next to each other and they all left at the same time and all left the house at the same time that didn't look like there was any randomness in that transaction at all which which seemed somewhat breaking in it probably people wouldn't spend exactly the same amount of time in a store is there a reason for that like would that have taken too much

I think it came down to like a complexity issue or you know would people even notice that this was happening if we varied that amount so the tuners actually had the ability to set the time that people were in a shop or in a culture of building so they could set that this is you know differently for each building what we ended up realizing is that we had templates for all the you know there's like twenty seven types of RCI buildings and they ended up - most of the stuff inside those templates for the different wealth and density and then the three different types of buildings were there were there any patterns that are merged in when you're developing the different systems that surprised you that either you thought needed to be changed as they were wrong or sort of revealed something about the simple workings of a simulation of a city one

thing that was kind of cool is that the way that our routing works when people go out and look for a job they're actually they're actually gonna take the first job that's available and one thing that was cool about that is you'd actually get businesses on the corners that that were most successful which is because you know the way that you had your your residential and your commercial and the Industrial laid out the patterns that would emerge from that would actually cause certain buildings to work better in certain places so I think that you know that's one of the things you don't really realize is the first few times that you play but after a while you actually start developing strategies to to game that behavior which was really cool I should also mention that there are some cards floating around that will actually give you a free copy of the game that Charlie brought Thank You charlie and people are

distributing them back there so when you leave grab a card and you can go on to origin and just type in a code and get some city so oh they look like this yeah so sure do you know if glass box is deterministic and then the simulation sense so there's there's only a couple of places where there's randomness in glass box a lot in actual rules in the simulation a lot of the non determinism comes from the behavior of the agents which are just controlled by gameplay code so they could have so each each agent transport handler could be implemented with the deterministic behavior or not and and most of the most of the vehicle and pedestrian ones were not deterministic so you could get slightly different behaviors each time so during development which of the

systems was trickiest to debug sorry during development which of all the gameplay systems was the trick is to debug the trick is to debug I'd have to say our the the guy implementing our vehicle system this guy named Alex Harkness is an amazing program and programmer and just did a really great job with it but man that was a very hard system to get right one of the one of the bugs that we would find is that you get gridlock and you could get gridlock for like a million different reasons if something would go wrong or some flag wouldn't be set on the traffic light or something so that that bug just kept coming up and every time it happens it's like it's death to your city so I'd say that was probably one of the most complicated systems on the game the other one was the zoning system that spawned the buildings because it had to do a lot of pre caching of data in order to efficiently

decide where to put you know these like 27 different classes of buildings that were trying to spawn all the time so yeah okay one more question counter that with the example where you know like we had a slide where you know the designers gonna do it anyway and it's gonna overburden the system so how do you counter the soil I've got to say no with images I'm gonna do anyway um I mean I feel like it's different team by team on our team we tended to just you know talk about it in a pretty civil way so I mean there were certain things that people wanted to do that like if we had done we just never would have shipped or they wouldn't be able to support big cities so that was part of I think that the engineers were pretty strict about performance because it was a pretty

obvious case that you could make like okay can you do that can you have a whole city of tiny tiny buildings all doing that same thing and you know so you can always come up with this worst-case situation so rather than just designer putting their foot down it was more of a collaboration yeah okay one more sure development do you guys really feel like the boulder had started rolling down the hill and how did you keep the vision how did you keep the eye on that where you got there for your players people do that I mean we were so we were always trying to get back I think that when that ball crossed the threshold was probably in October of last year so pretty close to the end of the game you know where we just had enough of everything in so that you could have a coherent gameplay experience across all the different systems in the game so that's the thing about and hearing

stories about previous same cities developments went the same way while you're just picking up all these pieces one one thing at a time and then you get to this point where you reach this threshold and the game just feels like it came together so it takes a lot of work but I've also heard similar stories for people doing sandbox games where you know until all the little pieces start to lock down you can't tune the outer pieces because one change early on can really have these ripple effects through the game yeah okay so thanks everybody [Applause]