After 28 years, cofounder Frank Pearce is leaving Blizzard

The team at Blizzard Entertainment published a blog post today in which company cofounder Frank Pearce lays out his intent to leave the company and “pass the torch to the next generation.”

This is significant because Pearce was the last Blizzard cofounder who hadn’t left; fellow cofounders Mike Morhaime and Allen Adham have both departed at this point, though Adham resigned in 2004 and returned in 2016, while Morhaime left just last year.

Alongside Pearce’s farewell message is a note from Blizzard president (and former World of Warcraft executive producer) J. Allen Brack thanking Pearce for his work and explaining that Pearce had stepped into an “advisory role to help with the transition” when Morhaime departed last fall.


Don’t Miss: Crafting the oppressive soundscape of Wolfenstein II: The New Colossus

This Audio Design Deep Dive is a fresh, game audio-focused spin on Gamasutra’s popular Game Design Deep Dive series, which aims to shed light on specific features or mechanics within a video game in order to show how seemingly simple, fundamental design decisions aren’t really that simple at all.

If you enjoy this sort of focused look at the nuts and bolts of game development, check out earlier installments on design of the Clockwork Mansion level in Dishonored 2, creating a new language for Planet Coaster, and maintaining tension in Nex Machina.

Also, dig into our ever-growing Deep Dive archive for developer-minded features on everything from Amnesia’s sanity meter to the Invasion of Privacy missions in Watch Dogs 2.

Who: Martin Stig Andersen, sound designer and composer

I’m Martin Stig Andersen and I worked as a composer on Wolfenstein II: The New Colossus.

Previously, I worked as a composer and sound designer on LIMBO and INSIDE. Then I got in touch with MachineGames’ creative director Jens Matthies, who was interested in bringing me on to help collaborate on the score for Wolfenstein II

(Editor’s Note: Make sure to check out our Audio Design Deep Dive from last year about using a real human skull to create the sounds of INSIDE.)

LIMBO, INSIDE and Wolfenstein II are actually the only games I’ve worked on so far; my background is in composition, especially electroacoustic composition (which is all about extracting music from everyday sounds) and electronic music. But to be honest, I very much prefer working with visual media.

For me, it is very interesting to see what happens when you combine the two medias: visuals with sound. I’ve enjoyed getting to work on games and experimental films, because I’m fascinated by how you can totally change the meaning of a scene through sound.

What: Using the unique Baschet instruments to score Wolfenstein II

While working on the soundtrack for The New Colossus I had the opportunity to visit the Baschet workshop, outside of Paris, and spend some time making bespoke recordings with the Baschet instruments that are housed there.

It’s hard to describe the experience of working with these sonic structures if you haven’t seen them in person: the instruments resemble sculptures of metal sheets, folded into geometric shapes and attached to rods of crystal and metal. For this project, most of the Baschet instruments I used were played by wetting my hands and running them along crystal sticks, much like you might dampen a finger and run it along the rim of a glass to make sound.

On this project I had help from sound designer and Foley artist Nicolas Becker, in France; he’s worked on a lot of films (including Arrival, Gravity, and Cosmopolis) with a lot of notable directors, including Roman Polanski, David Cronenberg, and Danny Boyle. I got him on from the beginning of my involvement on the project, so most of the music that I did is based on recordings that he provided. 

We basically had these Skype sessions where I explained what I was looking for: something that has orchestral textures, but with no orchestral instruments in it. During our collaboration he went to the Baschet workshop to do some work as a composer on another film, and he wrote me that I had to come down and record with him for the Wolfenstein project. 

It was kind of funny, after the recording session I had a note from the guy who runs the workshop (Frederic Fradet) saying that it was interesting how quiet it was while we were working. That’s not exactly how I remember it, but I think it’s because most of the time when we played the instruments we were focused on amplifying really interesting stuff, so we had headphones on; the thing is that when you do even small sounds on the Baschets that way, they can sound really big. I mostly focused on the instruments with deeper registers, because I wanted to evoke something that sounded like massive trombones.

Nicolas Becker making sounds with one of the Baschet sound sculptures

For post processing I used an AKG BX15 Spring Reverb a lot in the score; I actually bought it specifically for the Wolfenstein project. When you play metallic sounds through it, they get very trembling and rattly, so in that way it made some of the samples from the Baschets sound like the brass section in a symphony orchestra. 

You might feel while listening that it’s almost reverberating all around you, like an airplane. The Baschets are really alive and vibrant, so there’s a lot of stuff going on there sound-wise. And that can excite a tube in the overdrive rig, or in the Spring Reverb, in unforeseeable ways. 

So it was a lot of fun and productive to experiment with making sounds with the Baschet instruments, then distorting those sounds in different ways to compose the soundscape for Venus of The New Colossus. The track “Venus”, for example, was created entirely from the recordings of the Baschet instruments. 

By contrast, the story of composing the “Lontano” track, also for Venus, is kind of interesting; the game’s audio director (Nicholas Raynor) really liked the “Venus” track, so he was suggesting that I make yet another “sci-fi” variation of it. More synth-y, using more conventional instrumentation. 

But I didn’t want to do a pure synth track, so I promised that I would find a way to do a different take on that idea. I worked on that for a week. Then on Friday, I purposely deleted everything and went home.

But then the week after I was just checking out some sci-fi soundtracks from the ’60s, when the game takes place, and I noticed that around 90 percent were still very orchestral. So I thought that was something I would explore instead; I already had a lot of brass sound from the Baschets, so I mashed that up a bit of some old orchestral pieces I did and then had an assistant (Katrine Amsler) help me process some of the Baschet sounds through a Micromoog analog synthesizer and a Russian Sovtek vacuum tube amplifier.

Because in the concepts for The New Colossus‘ Venus level, you can see these lightning storms in the atmosphere, and so I wanted to use analog gear to give the music an appropriately “crackling” distortion. Although I incorporated some mashed-up strings, the “Lontano” track is still 90 percent Baschets.

  • 0:00 – Bass phrase from the “Venus” composition
  • 0:25 – The stem is processed with a Micromoog and a Russian Sovtek tube amplifier
  • 0:55 – The sound is softened and unfolded by means of analogue spring reverb
  • 1:27 – The processed sound as incorporated into the “Lontano” composition

When I submitted the final version of that track, the audio director said he had never received something that was so far from what he was expecting — but he also said that he totally loved it. Sometimes, I think it pays to just trust your gut and submit something totally different. 


When I go to a location like the Baschet workshop, I try to bring with me some basic ideas of what I want to explore. But most of all, I’m just trying to keep an open mind; because if you have too many concepts in your head, you may miss the best opportunities. 

That said, there were a few things I was thinking about: I wanted to make something otherworldly, but I don’t like to do synth-y electronic scores. That’s been done so many times. So I was looking for something more organic, and the Baschet instruments definitely provide that. Something that is more like a physical, weighty sound. 

Also the Baschets had an orchestral reference that I wanted to explore in relation to the Venus level. Something that could carry an almost Wagnerian quality. I had already been working with the Seufzermotiv or musical sigh which is a falling half note, used a lot in romanticism. But instead of using classical instruments I had created the motif by airplane fly-bys and other real world sounds, and by way of analogue procession made them sound more instrumental.

With the Baschets occasionally I went the other way around. By distorting them they attained the aforementioned airplane like quality, and in that way the Baschets came to complement very well my previous work on the score, which was based primarily on sound effects recordings.

  • 0:00 – Original recording
  • 0:17 – Transposed 1 octave down with some light analogue harmonic distortion added
  • 0:41 – The previous sound as incorporated into the “Venus” composition
  • 1:03 – The previous transposed version with obvious analogue distortion
  • 1:26 – The previous sound as incorporated into the “Venus” composition

While I kept the Baschet recordings exclusive for Venus and the events taking place there, in the rest of my part of the score I primarily worked with environmental sounds that can be associated with the game’s environments. For example, in the music for the nuked Manhattan level, I worked with mangled metal to get this clunky, rubble metallic sound. For the Area 52 level, I worked a lot with electric sparks and bell sounds to create a soundscape appropriate for the sci-fi environment.

At one moment in that level the player encounters a giant bell-shaped structure, and that was one of the opportunities I had to deliver both the music that’s playing and these giant vocoded spark sound effects which play around the bell, as well as the electric groans that play when the player walks close to Tesla coils.

I collaborated on the score with Mick Gordon, who scored the previous game. As he had the resistance side of the score covered my task was more to score the Nazis, characters like Frau Engel along with her Ausmerzer and levels like nuked Manhattan or the Nazi facility on Venus.

When I started I asked the studio for references of what sort of sound they were going for, but they said they wanted me to come up with a style; the only directive they gave was to make something that sounded like “the oppressive marches of machines.” 

So I wanted to make something very aggressive, and evil, but that would also reflect what lies beneath that evil: longing for what they believe to be beautiful, this sort of sickly romantic view of the Nazi’s perfect world. 

  • 0:00 – Original recording with subtle harmonic distortion
  • 0:33 – The previous sound as incorporated into “The Audition” on Venus

Also, I wanted to convey a sense of pomposity and megalomania; you know, the Nazis have occupied the Earth, so now they’ve ventured to Venus as well. It’s a very megalomaniacal and sickly romantic viewpoint. I think it’s part of the evilness, that whole bleak philosophy that underlies the enemy viewpoint. It’s horrible.


For my approach to soundscape composition, the Baschet instruments are brilliant because they can give you so many different variations of a single note. I’m really happy to have had the opportunity to visit and work in the Baschet workshop, and I think the results give the Venus setting a more oppressive and otherworldly sound, without sounding too electronic.

  • 0:00 – Original recording with light analogue harmonic distortion and space added
  • 0:27 – The previous sound as incorporated into the “Venus” composition

Based on my experience, I think it’s a good idea when working on a project like this to keep an open mind, and then gradually zoom in on something. Because it’s not fun to go someplace like the Baschet workshop, come home with a lot of different sounds, but you only have one of each sound. You’ll have to make a lot of decisions on the spot.

So it’s really about staying open to everything, then tuning in on what works and making sure you have enough material of a certain kind that you can actually build something. It’s a bit like improvisational composition; it’s hard, because you have to be extremely focused the whole time, but it’s also a lot of fun.

I wish I had more advice to give, but I only visited the Baschet workshop once, monkeyed around, and don’t know the full potential of those instruments. It could be that you could get to a point where you could visit with some sort of pre-written compositions in mind that would wring something amazing out of the Baschets, but I prefer to go out and try new stuff.

(To understand the examples of this playlist please open each track individually. In the track descriptions you’ll find detailed information about what is playing when and how it was created and processed. Enjoy!)


Get a job: Sony PlayStation, Tequila Works, and more are hiring now!

Whether you’re just starting out, looking for something new, or just seeing what’s out there, the Gamasutra Job Board is the place where game developers move ahead in their careers.

Gamasutra’s Job Board is the most diverse, most active, and most established board of its kind in the video game industry, serving companies of all sizes, from indie to triple-A.

Here are just some of the many, many positions being advertised right now. If you’re a recruiter looking for talent, you can also post jobs here.

Location: San Jose, California

Cold Iron is seeking an experienced Lead Character Artist to join us in creating a shooter set in the Alien universe for consoles and PC! Are you able to translate 2D concepts into fully realized 3D characters, armor, and weapons? Are you a passionate game developer looking to create the best experiences possible? Join our creative, collaborative studio where you will help craft visually inspiring player characters, and enemy creatures that are as fun to look at as they are to blow up.

Location: Remote

CG Spectrum is looking for mentors with AAA games experience to help develop an industry standard game design course and/or teach online. We offer casual and full-time positions at a competitive salary, alongside a flexible schedule and the ability to work from anywhere. 

Location: Madrid, Spain

The Senior Producer is vital to oversee the pipeline, scheduling, asset managing, build processes and QA of the whole game. They will work closely with Creative Director and General Manager in budgeting, scheduling, identifying process risks, problem solving as well as communicating with both, internal team and publishing partners. they and will use their experience on the front lines to improve efficiencies, communication and quality.

Location: San Mateo, California

 As a Global Partner Marketing Manager you are a leader within the Global Third Party Relations department, responsible for shaping the global strategy and operational direction of marketing for your designated accounts and key partnerships. The role encompasses segmentation strategy, cross-functional communication, and competitive analysis with a key focus on data-driven decision making and lifecycle management to grow and deliver on account goals and KPIs.


The Weekender: Eye of the Beholder 2 Edition

So I’ve been trying out The Mighty Quest for Epic Loot past couple of weeks. Fun Fact: This game originally launched in 2015 on PC as some weird blend of loot-tastic action/RPG and a Dungeon Master type deal as players built their own Castles/Dungeons for players to raid for said loot. It didn’t last that long, closing down shy of two years after launch. In January 2017 it came back on mobile, soft launched in only a few territories. Whatever they were testing seems to have worked because it released world-wide in full the other week. 

The problem is, it’s now just one Red Hot(TM) Free-to-Play gacha mess. Energy gating how long you can play in one go, chests that you can unlock by spending keys, which can be bought for money. Hey, want to double the loot you got from this chest? Watch an add! Can’t be bothered to play? From Level-5 there’s an ‘Auto’ mod, and you can even buy ‘Instant Win’ tickets that by-pass playing levels out entirely. I mean look at this non-sense:

epic loot

The worst thing is, they’ve gotten rid of the Castle building elements, which I personally think was the most interesting part about it, but what do I know? Here I am, playing it anyway… It’s an incredibly pretty game. Like, I really dig the production values that have gone into designing the character models and levels and I’m not going to lie, I’ve taken more-than-appropriate satisfaction from putting different pieces of bad-ass gear to my dude. 

Tl;dr – Don’t play Might Quest for Epic Loot, you will probably end up hating yourself (while looking like a baws).

Meanwhile, in the world of mobile gaming… 

Out Now

Beholder 2 (iOS Universal) – Full review coming soon!

If this had already been announced, I must have missed the memo as I was not expecting to see Beholder 2 on the release docket this week. We reviewed the first game back in 2017 and while it had some interesting ideas in terms of the choices and trade-offs, it was too easy to succumb to ‘efficiency’ rather than trying to deal with morality. Beholder 2 seems to be a rather expanded affair, with your character a fully-fledged member of the Ministry of Security. You must work your way up the career ladder, spying on your co-workers and praising the leader at every turn. It’s only on iOS at the moment but the first game made it do Android eventually, so it’s hopefully just a matter of time.

Fluxx Digital (iOS Universal) – Re-Review Coming soon!

This is technically a ‘re-release’ rather than a new release, but you’ll remember the other week we reported that Playdek has decided to revive their digital adaptation of Fluxx from the dead. Originally released in 2012, it was lost in the Appocalypse a couple of years ago – now it’s back! This is a card game for 2-4 players where the rules and objectives can change at any moment. It’s chaotic and pretty unique, as card games goes.

We do have a review buried in the site archives, but it hasn’t aged well so I’ve got Michael on the case to re-review it for us, so watch this space. Also note – if you bought the game originally between 2012 – 2017, so long as you still have access to the iTunes account you bought it on, you’ll be able to re-download it on your modern iOS devices without have to re-purchase the game. The originally release was never on Android as far as we know, and we don’t know if there are plans to bring it to Google Play anytime soon.

Fluxx ios

Also released this week  of note was Cosmic Frontline AR, which we reviewed yesterday (it’s not very good, unfortunately) and Healer’s Quest: Pocket Wand (Android), which at first glance is a strategy RPG in the style of Final Fantasy, except it’s also got comedic themes woven into its DNA. It seems a little generic on paper, but we’re wondering if the light-hearted presentation makes it stand out.

Finally, for the more aesthetic among you, the developers behind 2013’s iconic Journey have released a new game this week. Sky: Children of the Light is a free exploration/adventure game where you can fly around, explore and go on adventures with other players.


A few update of note this week, so let’s run through them…

Chess Rush

Tencent’s version of Auto Chess received an update this week, which along with the usual tweaking of pieces and new rewards/content drops, also included a co-op mode. I’ve yet to test it out, but it sounds intriguing.


The digital version of Santorini has had a few updates since launch. Two this week fixed a few bugs as well adding in an easy share feature for private matches, along with a discount for God of the Week promos. If you’re wondering, our review will be dropping on Monday – sorry for the delay!

Harry Potter: Wizards Unite

The first official patch since the end of June, this week’s update offers a few quality of life teaks, such as making the Exstimulo potions a bit more effective, and showing how much Spell Energy you have left in more obvious places. You can also change your code name in the settings, if you want, but only once.

Star Traders: Frontiers

In this week’s episode of the Star Traders: Frontiers Update Show, the latest update adds a new ship, new salvage, replaces the Pirate template as well as a few others goodies that keep this game ticking.


On the sales front, here’s what we’ve got:

Seen anything else you liked? Played any of the above? Let us know in the comments!


How Satisfactory’s network optimizations keep multiplayer factories humming along

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

Hi everyone!

Ever been wondering how much work might go into the seemingly small, and relatively vague bullet points on the update list? In particular, the ones in this list related to network optimizations? 

Well, either way, I’m here to tell you a little about it. It’s actually a very big and pretty complicated topic, even though the results can be described in relatively simple terms.

The Problem

As you all probably know, Satisfactory is a game about managing and handling tons of buildings and resources. This creates a very unique problem that most multiplayer games don’t have to handle, as most multiplayer games only need to keep track of a few other players (or nowadays, about 100 other players) and whatever comes out the other end of their gun. Which is very different from handling a base with over 2000 conveyors, transporting thousands upon thousands of items every second. On top of that, those items move in clear-to-see patterns, meaning that it is easy to see when they end up wrong. For us this means there is less room for simplifications. Opposed to, for example, when a player at a distance of 100 meters happens to aim their gun 10 degrees wrong.

This is just a portion of a base, but pretty much everything you can see here has states that change over time. These states need to replicate for all players simultaneously.
This is just a portion of a base, but pretty much everything you can see here has states that change over time. These states need to replicate for all players simultaneously.

The Solutions

To solve this there are essentially two solutions. Solution A would be to initially synchronize the whole map to all clients fully, and then do a local simulation on all clients’ machines. This will keep everything 100% predictable at all times, and will only send and sync information when unpredictable events, such as player input, happen.

Solution B would instead run everything primarily on the server while clients send their input to the server, which would then replicate its state to all clients. Similar to how most shooters handle this.

Both methods have their pros and cons. So let’s dive a little bit deeper and explain which solution we are actually using, and why.

So like we said, solution A relies on simulating everything locally after the initial full sync. This requires us to keep everything 100% predictable/deterministic at all times. Which in itself is a bit of work, but doable, and something we want to strive for either way. In this case it would not only be a goal, but an absolute requirement. The slightest inaccuracy could cause a chain reaction, resulting in the entire game-state being desynchronized beyond repair for everyone. Keeping things deterministic for factories and such is one thing, but keeping the physics simulations for complex actors such as vehicles perfectly deterministic on all clients is really hard, if not impossible, without rewriting parts of the engine. Meaning those would likely require a special workaround solution.

What makes this even more complicated, however, is the sending and syncing information when unpredictable events, such as player input, happen. To make this work you would then also have to run everything in lock steps. Lock steps ensure the game does not advance a frame before everyone can confirm they received the input messages from all players for the given frame, which would result in stutters for all other players if just one player is running behind.

An alternative to lock steps is requiring all players to keep multiple copies of the entire game state for every frame up until 2 seconds back in time. This enables them to rewind and simulate forward again when input from a laggy client arrives. Multiple copies of the game state would eat away memory, while rewinding and simulating forward multiple frames in a single frame would cause a lot of CPU overhead and potentially performance spikes.

All are solvable problems, but require a lot of work. It also makes adding new features more difficult, as you need to consider all these cases and systems.

We didn’t choose this method. We instead went with solution B. Which, like most multiplayer games, runs everything on the server, and then sends and replicates a representation of that to all clients when needed. But this requires us to be really smart with how we use the available bandwidth, since just replicating everything straight up will be impossible in a game like this. 

So what we’ve been working with in the months since launch has been the following:

  • Minimizing what data is sent, by figuring out when data is actually needed and only send it at that time. Things the player doesn’t notice are not needed.

  • Reducing how often the data is sent. If things don’t change often or are more predictable, it can be sent less often.

  • Compressing and minimizing the amount of data needed to represent a game state.

On top of all this there is also the problem of evaluating all the objects separately for each client on the server-PC, since which data is prioritized and needed will be different for every client. This means a lot more work for the server which can lead to greater CPU load, which needs to be minimized to keep the performance of the server as good as possible.

If these things are not done properly, the server can be performing a lot worse than the clients. Clients can experience a lot of extra latency (much greater than the actual ping), there can be a lot of dropped packets (will explain what this is shortly), things will start to get choppy, and things might look strange in general for the clients. Essentially all kinds of issues can occur.

To what extent this can be addressed or fixed varies greatly from case to case, so to give a better understanding of these concepts I plan to dive into a few concrete examples of improvements we have made for this patch.


To get us all on the same page, let’s cover a few common and maybe less common terms that we are going to use.

  • Packet: A bunch of data sent over the network as a chunk. This is how any and all information is sent between clients and servers.

  • Packet loss: When data is not being received or sent properly, resulting in holes in the intended data. Which can cause all kinds of issues if not handled.

  • Ping: is the time it takes to send a data packet to another PC and get a response back. Usually measured in ms (milliseconds).

  • Latency: The time it takes from initiation of an action until it’s actually performed/the user gets feedback of it happening.

  • Send Rate: How much data is aimed to be sent per second.

  • Send Buffer: A chunk of memory that is written to, which the PC will read from and consume when sending packets.

  • Bufferbloat: when too much data is written to the buffer, making it take too long to consume and work through the data. Think of it like a queue. Sometimes this leads to an extreme latency increase.

  • Buffer Overflow: When you try to write too much data to a buffer so some of it doesn’t fit and actually gets dropped. Can result in what seems like dropped packets.

  • Replication: The act of replicating the state of something on a client. It’s often not the whole state, but it’s enough to give the correct impression of the server’s state.

  • Serialization: The act of taking a complex data structure and writing it to a linear stream of data, which can be sent in a packet to later be turned back into a data structure.

We will use a few other terms as well, but let’s cover those as we encounter them.

What we’ve done

So, when starting on this update we had a pretty big plate of things to fix. There were many issues with the net code at launch, resulting in all kinds of issues imaginable. Most of which we’ve attempted to solve now, but a few that we have plans to follow up on again a little later. Soon™.

The first overarching and biggest problem was simply the raw amount of data that was necessary to be sent, growing larger as the factory grew. Large bases and factories would  cause an always-full send buffer, meaning bufferbloat, and even worse, possibly causing overflow.

To understand what a bloated buffer means for the game, think of the buffer as a queue that data needs to go through before it is actually sent. So a full/long buffer means data has to wait around longer before it is actually sent, thus increasing latency, even on our highest priority messages (like player input and movement). Ideally, a responsive game should write little enough data so it is all consumed before the next update. Making it so that the new packets can start writing at the start of the buffer (the queue). Meaning the newest data from the latest frame gets through as soon as possible.

So, our number one goal was to reduce the amount of data sent during gameplay as much as possible. To describe that work we can take a look at two particular cases that perfectly encapsulate the issues we had and the work we’ve been doing.

Only sending what can be seen

First-off we have a low hanging fruit with huge gains: all the factories and buildings with inventories.

With the initial replication the whole building was seen as one object, meaning if we replicated any part of it, like the production indicator lamp, we needed to replicate all of it. In turn this meant we ended up having all buildings’ inventories replicated to all clients at all times, even if they could not be seen.

For some buildings this was not a big issue, as its state rarely changed (meaning no data or at least very little data was needed). But most buildings have their inventory connected to a conveyor for input and output, meaning it is likely to change all the time. In fact many times a second in many cases.

As you can see in the menu for this building here, there is an inventory for the building that constantly changes and updates. This applies to every building that stores items or produces them and is connected to one or more Conveyor Belts. That’s a lot of data!

It would be a big gain to stop replicating the inventory when it’s not viewed, which is essentially what we did, but the method of doing so was a bit complicated and required a lot of rework. Not only for the underlying code, but also for GUI and other aspects, considering there would now be a small chance that we had a replicated building (or player/vehicle) which, due to latency, had not received its inventory yet. Which all systems both need to be aware of and preferably also inform players about.

Doing this also helps to reduce CPU time, as an inventory is a big state to compare, and look for changes in. If we can reduce that to a maximum of 4x the number of players it is a huge gain, compared to the hundreds, if not thousands, that would otherwise be present in a big base.

There is, of course, a trade-off. As I mentioned there is a chance the inventory is not there when you first open to view it, as it has yet to arrive over the network. However, this time should be very short, as long as we keep the buffer bloat to a minimum, and you are playing with a reasonable ping.

This all works very well at the moment, but there is always more we can do. In the future we could work to prefetch inventory data, trying to predict potential targets before you interact with them and fetch them just in case, minimizing or even removing latency. But that is work for another update and can cause serious data spikes if we are not careful.

Minimizing data size and rate

So that was related to the “Minimizing what data is sent, by figuring out when data is actually needed” method that was mentioned before. So how about the other methods?

To cover this, the next biggest issue is a perfect fit; The conveyor belts. There are literally thousands of them that send and receive many items a second each. Often you can clearly see them with all their items even on a great distance. There is no avoiding sending data in this case, since everything is visible, unlike with the inventory, so we need another solution.


I mentioned that the code at release was not very good, but it was not all brute force or anything like that. It was already trying to reduce the amount of data used by conveyors in many ways. So, before we cover the improvements and changes we did, let’s see what we were already doing.

The conveyors have a lot of items and data, but only a small set of that changes every time in a non-simple predictable manner (items entering and leaving). This is a clear case for something called delta serialization. This is not normal serialization like most objects use. The key word is delta. Delta means that we use a previous state and only extract the difference, which usually is a lot smaller, and send that instead. Think of it like this: instead of sending the 25 items currently on the conveyor, we only send the 2 new items that were added and the 1 item that was removed since the last update. Meaning we use only 12% of the data. On top of that we don’t replicate the movement of items on a conveyor, and instead simulate that on each client (only sending the initial position when the item is added).

This is a very simplified view of it all. In reality we have to send a little extra data and have a few more systems on top of it to ensure everything stays in sync, but that’s not what we want to look at right now.

This might already sound like it could be good enough, but in our measurements the conveyors still made up a clear majority of all network data and often resulted in the buffer getting bloated and potentially overflowing. Meaning it was not enough. We had to go deeper.

In this case we have to write our own custom serialization, looking on and evaluating every bit and byte we write. It’s a very time-consuming task, and it’s always full of compromises and trade-offs. We want to minimize data, but using more data always gives better accuracy, so the trick is to find the line where we can get just enough accuracy for as little data as possible. On top of that, if we can predict some behaviours or patterns, we can skip sending any data at all, which is an even bigger gain.

However much I would like to, I won’t go in on the details of what we actually write in the delta packets here, as it’s a really complicated system and could easily cover a whole page just explaining it. In fact, the functions making up the delta serialization is over 2000 lines of code, so it’s quite a lot to explain in there.

It’s hard to give concrete examples here, but we can use an average case packete for a standard conveyor under standard load to compare the size difference. In this case the old system actually varied in size but landed around 48 bytes per delta, compared to the new system of just 3 bytes. This is just the average case, the difference is smaller in other cases, though our new method should always be much smaller than the old method.

On top of this, we also reduced how often a conveyor tries to send an update to just 3 times a second compared to the previous of over 20. This makes them accumulate a few more changes as one packet/delta, meaning we spend less data on the packet overhead. Overhead being a constant cost which doesn’t really contribute to the end result but is needed for the system to work. After our reduction, this overhead turned out to be the largest part of most of the packets. So reducing how many of the packets are sent (how many of the overheads we “pay” for) ends up saving us a lot of data, at the low cost of a little extra latency on items’ movement on belts.

This graph demonstrates a pretty common test scenario we set up, and how much data it used before and after we applied some of the optimizations we were testing. As you can see, the results of our changes were quite promising.

But nothing is without trade-offs, and the reduction in data had some costs as well. For example, the accuracy of item placements on the conveyors took a small hit, but we have added complicated systems in order to compensate for that. These can recognize and use common patterns to avoid accuracy problems entirely, or send a little extra data in the cases it is needed.

Overall the conveyors should not only use less data compared to before, they should appear more accurate, be a closer match to the server’s state, as well as feel more responsive, even though there is a bit of built-in latency. Since that latency is compensated for on the client side, it should not affect your playing experience and rather make things feel even more responsive than before.

A lot of these optimizations are things we could only do by knowing the problem area in-depth and designing everything specifically for this case and this case only. In general, data optimizations like this is manual work that will take a lot of time and is generally done at the end of a project where the problem area is well defined and tested.

There is some future work remaining on the conveyors, which could help reduce the data a great deal more, and there are some things we could improve in the looks department. Overall the new system should be a lot cheaper for both the network as well as the CPU, while looking and feeling better than before. Essentially: wins all around. Though, like with all new and complicated systems, there can be some undiscovered issues and bugs that we will try to iron out as they pop up.

What’s next?

This is probably all optimization-related talk I can cover in this blog, but there is a lot more work that we have done, and we will spend a few more weeks after Update 2 looking over these systems to make sure everything is running as it should.

There are also two other systems that we are considering to add, but which we didn’t dare to add so close to the patch going live. So we’ll see when we get time for that. But if you are a player and still experiencing a lot of lag, delays, and/or other issues when joining into a game with a large factory, know that it is being looked at. It’s all related to too much data that floods the send buffer and creates a prolonged time of bufferbloat and overflow on startup. There is no easy way to manage this in the engine, so we have to write our own system for a gradual streaming of the initial world-state to clients.

For this update we prioritized everything that affected the moment-to-moment gameplay after the loading is already done, but the start up/loading is next on the list.

After this we will not focus on network optimizations for a while, as we’ve noticed that the biggest issue for running smooth multiplayer in large factories is not the network traffic anymore, it’s rather the general performance of the PC acting as a server, which is were we will focus our optimization efforts next.

For more info about the game, and potentially more blogs, please visit  or follow the Satisfactory twitter: @SatisfactoryAF

For questions, feedback or more info about the topic here, you can use the comments below, or reach me at twitter @Gafgar_D.

Thanks for reading!



Don’t Miss: Making Insomniac’s Spider-Man do what a spider can

This month, Insomniac Games and Sony released Marvel’s Spider-Man, a fluid, polished, and surprisingly grounded take on the web-slinging hero that’s drawn wide praise and sold millions of copies.

And while it’s easy to credit the wall-crawler’s worldwide fame as a big part of that success, the work Insomniac Games has done polishing every minute of Spider-Man’s adventure is worth remembering as well. 

Recently, we were lucky enough to be joined by Insomniac Games game director Ryan Smith to talk about the development of Marvel’s Spider-Man, and learn more about the process in making Spidey feel like a genuine superhero. 

Whether it’s the incredibly dynamic wall-crawling or building a New York in need of a champion, we wanted to know what Insomniac did to fuel their Spider-Man with great powers, and an even greater responsibility. 

The swing is the thing

Smith’s perspective on Marvel’s Spider-Man starts from the fact that, no matter where the story goes or what villains Spidey squares off with, players will spend most of their time in this game doing one activity: swinging. Spider-Man’s unique traversal system has long been a draw in the various Spider-Man games made over the years, but for Smith and his colleagues, this pendulum-like movement would be the root of all their work. 

Smith starts our conversation by explaining that the pendulum movement came first and foremost. As players hold down the right trigger, Spidey looks for an object nearby to shoot a web at, then swings down, then up to continue his forward movement. Right away, Smith says this flow creates visual and spatial differences that set the game apart from Insomniac’s last open-world title Sunset Overdrive. 

“There’s also a difference in feel in terms of the speed that this character moves, the grand motions you make when you swing,” says Smith. “So you actually look at the city in a very different way: you’re looking at it a little further off in the distance.” 

Insomniac Games’ Sunset Overdrive, released in 2014

Sunset Overdrive, [the player sees] very rapid-fire changes. This one, we had a smoother motion that you’re looking at and you’re looking at bigger picture city changes.”

From there, the gameplay team needed to determine what would happen with each point in the parabolic arc where players could release the rope. “We looked at, on the swing, not just how does it feel to be on the line, but where are those right points to let yourself off the line and how can we make that a little bit of a game mechanic?” explains Smith.

This led to a decision to give players more decisions to make in traversal. Pressing jump at the end of a swing can launch them forward, but choosing to release earlier in the swing can send the player’s vector downward, changing direction toward street level. 

Next, Smith pointed out the importance of “speed cues” in this crafting process. Examples include the motion blur from a straight dive down, or the slow-moving buildings in the distance while players zip through the foreground. 

All the while, these movement systems (which include a handful of non-swinging moves like zip-lines and leaping systems), are fueled by hand-crafted interactions in the Insomniac Engine. To Smith, game physics are useful for collision tests, but when Spidey takes wing, it’s more important that “custom hero states” drive the swinging and moves.

An Empire State of Mind

The open world of Marvel’s Spider-Man might be better described as an open metropolis. It’s a scaled-down version of New York City that mushes together notable landmarks like Wall Street and Trinity Church (which is detailed so finely you can swing by the grave of Alexander Hamilton, as seen below). Unlike a lot of recent open-world adventures, Marvel’s Spider-Man doesn’t confine its hero to specific zones and then shuffle them along into new areas as the story progresses.

Instead, it keeps the city open, and uses a district system not only to organize its quests and activities, but also unique flavors of gameplay that keep the swinging from becoming stale. 

“Also if things are always consistently—‘I can just press one button and just drive through the whole city,’ then that takes away some of that player engagement and that sense of flow and involvement,” Smith says. He compares three of the game’s districts and their architecture next. “The Financial District has really tall skyscrapers, Hell’s Kitchen is maybe a little bit lower…we looked at real spaces, actually Central Park is a great example.”

To build on Smith’s point, a quick spin through the city of Marvel’s Spider-Man shows the kind of detail he’s talking about. In the Financial District, it’s easier to get a higher altitude and make wide, sweeping swings between skyscrapers over the smaller buildings below. But when heading into Hell’s Kitchen, the player is now caught more in the local grid of the city. When making navigational changes, they either need to follow that grid’s path, or hoof it over the buildings and use more lateral traversal moves to move in the desired direction.

And when it comes to Central Park, it’s a wonder Spider-Man can even swing through there at all. But Smith says getting New York’s biggest natural landmark down was a big priority for Insomniac Games. 

“You actually can swing through Central Park but we looked at those sections of the game that aren’t as natural as swinging off skyscrapers,” says Smith.” And we asked ourselves what feels right? Central Park, its central right? It defines the overall size of the island, it relates very directly to the whole shape and feel of it.”

“We did multiple tests with like a smaller Central Park, a bigger Central Park, and so we wanted to know both that if I’m swinging along side of it, what’s the right size, what’s the right distance where it feels like what’s the right size, what’s the right distance where it feels like ‘Wow, that is a Big Central Park, it feels right.’ But at the same time how can we find those opportunities in the middle to let you swing off the trees or the lamp posts that are in there?” 

If this be Insomniac’s destiny

During our discussion with Smith, one surprising caveat to our conversation was how much of Spider-Man’s feel comes from all the games the company’s produced in the past, along with its proprietary Insomniac Engine. 

Smith points to two specific titles whose DNA can be felt in Marvel’s Spider-Man in particular. The first is Sunset Overdrive, which is where Smith says the company learned about open-world traversal and shaping cities to improve gameplay. The second though, is the Ratchet and Clank series that Insomniac was previously most famous for. 

In particular, Smith discussed how the myriad weapons and gadgets that players touted in Ratchet and Clank drove the gadgets and powers that players pick up during the course of Marvel’s Spider-Man. “That was something where we were able to leverage the experience we had building [Ratchet and Clank] weapons and awesome gadgets in previous games to integrate that into combat.” 

“We knew that was a way that we could have players could express themselves and they’re gonna be still hopefully discovering different ways gadgets combined together and different strategies for taking guys down.”

Smith describes working with the company’s proprietary engine as “part of the Insomniac DNA,” and says using the engine helps his team set audacious goals for the game’s streaming budget and graphics. He adds that it also affords his team the ability to create custom workflows and tools that best fit their workflow. 


“We were able to leverage the experience we had building [Ratchet and Clank] weapons and awesome gadgets in previous games to integrate that into combat.”

Unlike the development process for Sunset Overdrive, Smith says that Insomniac Games didn’t rely on internal game jams this time around to prototype dramatic new ideas. But he does say that a lot of the game’s niche features, like a photography mechanic and subway station-based fast travel system, came from a similar instinct of random team members pairing up to implement a unique design idea. 

Per Smith, both systems solved problems that were occupying the design team at other levels. They knew even with a fun traversal system, players would still want to zip around the map, and even though exploring the city was meant to be fun, Smith and his colleagues wanted ways for exploration to feed back into the combat system.

Thanks to team members collaborating together though, both the subway system and the “landmark photo” mechanic were hashed out, letting Insomniac put a Spider-Man-flavored spin on traditional open-world systems. 

“It takes a village,” Smith told us as we closed out a conversation. But if the success of Marvel’s Spider-Man is any indication, it’s helpful when that village has a history, elders, specialists, and a known tool as well. 


Microsoft sees dip in quarterly Xbox revenue as hardware sales slow

Microsoft has closed out the fourth quarter of its 2019 fiscal year with year-over-year decreases in both its game and Xbox businesses, declines that come as the next generation of consoles looms on the horizon.

For the quarter ending June 30, the company reported a $233 million decrease in game revenue, down about 10 percent from the same period last year. That makes for just over $2.05 billion in game revenue, down from $2.29 billion during the same period last year.

Microsoft’s earnings report calls out a 48 percent year-over-year decline in Xbox hardware revenue specifically, noting that the shift was mainly due to a decrease in consoles sold during the quarter. Xbox software and services, meanwhile, fell by 3 percent year-over-year, offset partially by a rise in subscriptions. Microsoft notes that it had a strong Q4 in that category last year, which likely also contributed to the year-over-year decline.

However on a yearly basis, the company saw an increase in game revenue. Its games business as a whole saw $11.39 billion for the 2019 financial year, up from $10.35 billion in 2018. Monthly active Xbox Live users have also increased over the last year. As of June 30, 2019, Xbox Live has 65 million MAUs, up from 57 million at this same point last year.

In its full report, Microsoft also called out games, cloud/AI engineering, and GitHub as three of the four departments responsible for a 15 percent increase in its R&D expenses.

Unity Release Three New Gamekits

In addition to their already released 2D Gamekit  (and the more advanced 3D Gamekit), Unity have released three new Gamekits to their Unity Learn portal.  The new gamekits include:

Each Gamekit includes a complete project downloadable from the Unity Asset store as well as a full step by step tutorial that average around 1 hour in duration.  They are designed to introduce users to Unity without requiring art or programming ability.  Each Gamekit is designed to be extended or customized by the user.  Learn more about the new gamekits in the video below.

GameDev News