Posted on Leave a comment

Blog: Bringing Galaxy on Fire to Vulkan – Part 3

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.

Written by Max Röhrbein-Kling and Johannes Kuhlmann

This is part three of our series of blog posts on our experience with bringing Galaxy on Fire 3 – Manticore to Vulkan.

Our posts follow this structure:

  1. Introduction and Fundamentals
  2. Handling Resources and Assets
  3. What We Have Learned (this post)
  4. Vulkan on Android
  5. Stats & Summary

Before we dive into the matter, we would like to point out once more that the focus of our Vulkan renderer was to ship a game. Thus, it is more pragmatic than perfect and we have mainly done what has worked for us – so there is no guarantee that our best practices will also work for you. We do believe, however, that our implementation is still reasonably versatile and well done. And we hope that you can learn a thing or two from our approach.

This third post covers a bunch of little problems we encountered while implementing Vulkan support and getting it to work on different devices.

You Have to Pay Respect

One of the things we learned when bringing our Vulkan renderer to different devices and GPUs was that it is very important to pay respect to the targeted devices’ limits, properties, and capabilities. With Vulkan, almost anything can be queried. Most things you have to query before you go ahead and do it. Some things we knew about, some came as a surprise. To shed more light on this issue, we are now going to discuss a few examples that struck us as the most important ones.

One such example is maxMemoryAllocationCount of a Vulkan device. This number tells you how many VkDeviceMemoryallocations can be live at the same time. Per spec, the minimum is 4,096. As it turns out, there are numerous devices out there that have a maximum of 4,096 (Adreno GPUs, for example) – a number we are apparently able to exceed with all the vertex/index buffers, uniform buffers, textures, and so on. So, as most Vulkan tutorials recommend, you should think about memory management early on and not make one allocation per buffer.

We also had problems with the alignment of our data. There is the device’s minMemoryMapAlignment and then there is the alignment you get from vkGetBufferMemoryRequirements(). In some cases, we had to take the maximum of the two in order to get the correct alignment.

You will also want to check the API version of the device you have. Make sure it is actually the one you programmed against. We had some Vulkan implementations where the major version was 0 and things like the VK_KHR_swapchain extension or validation layers were not available at all.

A Vulkan implementation must support one of the following texture compression methods: ASTC, BC, or ETC2. If you want to be compatible with all Vulkan devices, you better support all three texture compression formats. However, on Android, we have gotten away with only supporting ETC2 so far. This is due to the fact that all devices we target support it (presumably due to it being required by OpenGL ES 3).

The framebuffer formats also vary from device to device (be it RGBA or BGRA, or whatever). And depth and stencil formats are wildly different between GPUs, too. They can also be combined or not, for example.

Additionally, there are some other small things like the alpha compositing mode (VkDisplayPlaneAlphaFlagBitsKHR) or the surface transform (VkSurfaceTransformFlagBitsKHR) for which different values are supported by different devices.

Validity Does not Imply Correctness

If you have worked with Vulkan, you have hopefully also used its validation layers. These layers basically stand in-between your game/application and the Vulkan driver, making sure your usage is valid. The layer concept is not exclusive to validation, but it is normally the first use case you come in touch with. There are different validation layers that focus on different areas where problems might occur. For example, there are layers for parameter validation, API state, and correct threading. The validation layers are Open Source and can be found on GitHub.

The beauty of the layer concept is you can enable error checking and validation when you need it and disable it to have zero overhead when you do not need it. We would like to emphasize that you really should use the validation layers whenever something is wrong. Make them super-easy to enable (without rebuilding) and maybe even run with them enabled by default if performance permits.

The validation layers are still constant subject to change. Even which individual layers there are and what layer does what is not set in stone yet. Therefore, you should get them from GitHub and build them yourself if you want the latest checks.

You should load the validation layers in order. Contrary to what we had assumed in the beginning, the validation results may be influenced by the order you specify the layers to be loaded in. There is a recommended order which can be found here and here.

The validation layers are specific to the device you are running on. Of course, their code is the same for all devices, but the layers ask the given Vulkan device for its limits and capabilities. The layers do their validation based on that information. So, just because you do not have any validation issues on one device, it does not mean you will not have any issues on other Vulkan devices.

One very Android-specific issue we faced was that at some point our validation layers were not found by the Vulkan driver anymore. It just kept looking in the wrong folders. This happened after we integrated the Google Play services into our game. The same engine was able to find and load the layers successfully in a rather empty project without anything from Google Play in it. This bug seems to be specific to ARM Mali GPUs. We have reported the problem and hopefully it is going to be fixed at some point.

It is Easy to Lose Your Device

One thing that eventually will happen with Vulkan is that you do something wrong. On Android, you will then most likely get the dreaded VK_ERROR_DEVICE_LOST result which means your driver or GPU had to be restarted. Your Vulkan device will probably not recover after this without a restart of the game. It may continue rendering, albeit with worse performance as the error keeps occurring.

This problem is very difficult to debug because everything is asynchronous. Via the Vulkan API you submit commands to the driver. While these commands may already be processed asynchronously, they will most likely also be executed asynchronously on the GPU. The result from the execution will then again be sent back to the driver asynchronously. If there is an error in this procedure, your Vulkan code will only detect it when it tries to call one of the Vulkan functions that may return the error. So, it is rather difficult to pinpoint the one Vulkan call causing the problem.

If you get VK_ERROR_DEVICE_LOST, it is best to simplify what you are rendering until the problem does not occur anymore. From there, you might be able to debug whatever problem you have with one specific asset or its render setup.

For us, causes of a lost device included:

  • reading and computing things with garbage uniform data
  • sampling textures to whom nothing was ever assigned to
  • synchronization issues, i.e. reusing or destroying resources while they were still used elsewhere

Of course, there were certainly other causes as well. But the ones listed above struck us as the most prominent.

Drivers Have Issues, too

Normally, when something goes wrong, we first suspect it to be our fault – a notion that very often turns out to be true. However, this changed a bit when we were working with Vulkan on Android. At various points, we had to accept that it might not have been our fault and that there might simply be problems we could not fix at all.

In addition to the validation layer problem in one of the previous sections, there were two cases where we concluded that the driver must be at fault. Both happened on Qualcomm Adreno GPUs. Of course, to say it again, there is still a chance that these problems were caused by something we did. But in both cases, we could work around the symptoms by avoiding the addressed features.

In the first case, our uniform structs were assigned to the wrong uniforms in the shader. So, basically our rendered objects behaved very weirdly as their uniforms did not have any sensible values. We tracked this problem down to our DescriptorSets somehow being wrong. We made sure our binding numbers were correct in VkDescriptorSetLayoutBinding. And everything seemed fine, but our uniforms were still just as wrong as before. As it turned out, the driver was not using the binding numbers to bind the uniform structs, but instead their index in the array of VkDescriptorSetLayoutBindings inside VkDescriptorSetLayoutCreateInfo. A simple sort by binding index fixed that problem after days of debugging.

Another problem manifested itself with lots of flickering of one or multiple objects. The flickering intensified when pulling down the Android menu from the top of the screen. This problem was apparently somehow caused by our usage of dynamic pipeline states. Specifically, we had the viewport and scissor rect marked as being dynamic which results in them not being part of the graphics pipeline state. Disabling these features made the flickering go away. Luckily, we did not really make use of the ability to change around the viewport or scissor rect a lot.

In addition to things simply being broken, we also had problems with various GPUs behaving drastically different from each other. These were problems where we were wrong according to the Vulkan specification, but everything was still working correctly on a lot of devices. On others, however, this was not the case.

For example, we could map a memory buffer twice (using vkMapMemory()) even though that should not be possible. Or we forgot to specify external dependencies for our subpasses (VkRenderPassCreateInfo), but everything still rendered fine on all devices. At least most of the time. On some devices we encountered some objects to be missing occasionally for one frame at a time. Another example is that we specified a depth of 0 in VkImageCreateInfo for our 2D textures and it still worked on quite a few devices. The correct value should have been 1, obviously.


There are lots of little – or not so little – things that can go wrong in a Vulkan application. Luckily, the validation layers report most of these issues.

And then there are issues where you spend ages looking for the problem, have checked the Vulkan standard a dozen times, but everything looks correct to you. In such cases, it might help to assume your driver may not be implementing the standard correctly and see if that reveals a workaround to you.

In the next post, we will talk about some of the challenges we faced when bringing the Vulkan renderer to Android.

Posted on Leave a comment

Go on a beauty adventure with shu uemura x Super Mario Bros.

Go on a beauty adventure with shu uemura x Super Mario Bros.

Score major style points with this collection of beauty products from shu uemura. Each item features special packaging inspired by the Mario Bros. franchise-especially the super cute Princess Peach. In addition to limited-edition eyeliners, blushes, and other makeup, the collection features a cool way to organize it all with the Adventure Makeup Box.

Level up your look (or pick up a gift for your favorite gamers) on the shu uemura site.

Posted on Leave a comment

Classic Postmortem: XCOM: Enemy Unknown, which turns 5 today

In honor of the 5th anniversary of the release of the brilliant XCOM: Enemy Unkown, we present this classic postmortem, which first appeared in the January 2013 issue of Game Developer magazine.

The game was a “reimagining” by Firaxis of the classic 1994 strategy title UFO: Enemy Unkown, as well as a reboot of the XCOM series. It was a smashing success, earning numerous awards and GOTY accolades.

This in-depth look at what went right and what went wrong during development was written by Garth DeAngelis, who was the lead producer and a level designer on XCOM: Enemy Unknown.

There may have been wounds, but somehow, the XCOM: Enemy Unknown development team evaded permanent death.

In 1994, Microprose released a special PC game called UFO: Enemy Unknown. The turn-based strategy title accumulated a devoted fanbase for its unique take on high-level management against an alien invasion blended with boots-on-the-ground, intimate combat controlling individual soldiers. Fast-forward almost two decades, and Firaxis Games has released XCOM: Enemy Unknown, a reimagining of Julian Gollop’s original design.

The road to completing XCOM was an arduous one. We made many of the same mistakes that other devs have made (and documented in previous Game Developer postmortems): feature creep, communication shortfalls, not enough time, not enough people… If you’re a game developer, you know the story. But through it all, the entire team remained resolute, and in October 2012, against all odds, the development team managed to save Earth ship XCOM on PC, Xbox 360, and PlayStation 3.

Lead designer Jake Solomon planted a small seed within the creative walls of Firaxis Games in 2004. As the self-proclaimed “biggest fan of the original X-COM” and as a designer/programmer working directly with Sid Meier, it made sense to spark discussion regarding resuscitating one of the greatest strategy titles of all time. After shipping Civilization Revolution, the stars began to align, and the rebuilding of XCOM became a reality.

Before any code was written or any art completed, Jake defined core pillars that would act as the foundation for pillars that would act as the foundation for designing the rest of the game. All facets of game development had clearly evolved since 1994, from game and narrative design to user interface, but Jake remained adamant that certain high-level elements from the original remain holy. These inspirations included maintaining a turn-based combat system, which seemed risky in the modern age of frenetic first-person shooters and real-time action games.

The game would also preserve the symbiotic relationship between the micro combat layer and a macro, grand strategic mode, where the player runs and builds their own secret headquarters to counter the simulated alien invasion. Fans of the original game understood the appeal of these interdependent systems, but to those unfamiliar with the XCOM franchise, this was a foreign game structure, and that equaled potential big risk.

Other smaller pillars included: updating systems such as the fog of war and how visibility would be communicated to the player in a 3D environment; fully destructible environments, a satisfying staple from UFO: Enemy Unknown, but a potential challenge in a game of this scope; reintroducing players to permanent death, and the fact that when it comes to XCOM soldiers, there are no such things as extra lives; and recreating the tense atmosphere from the original.

It was critical to place the player in a world they recognized—in settings they may recall from their own neighborhood or city—and then introduce a menagerie of new and classic aliens into these usually safe environments. This led to an unnerving despair that XCOM fans are all too familiar with. Collectively, these pillars provided the foundation for a challenging experience that presented true consequences, just like UFO: Enemy Unknown.

Firaxis underwent a pitch process that previously had not been attempted with past projects, but then again, we were pitching what was essentially a new IP as a big-budget endeavor, so we needed to make a major splash.

Getting the green light to remake an antiquated turn-based strategy game would be a challenge, and simply verbalizing what made XCOM so special and ripe for a rebirth wouldn’t be enough. The team needed something that would make everyone understand why we were so passionate about undertaking this project—something beyond a static presentation.

Jake began working with project art director Greg Foertsch and a small band of artists to create a gameplay previsualization. Over the course of multiple months, Greg and his team ate, breathed, and slept UFO: Enemy Unknown, ultimately planning a storyboarded sequence that would illustrate how Firaxis’s take on the XCOM universe would not only look, but also how it would play.

On Fridays, Jake would sit in a room with the team while they immersed themselves in the original game, becoming familiar with its nuances and big concepts alike. This collaboration led to a compelling previsualization that not only got the development team on the same page, but also communicated to nondevelopers the potential for a classic turn-based experience to be reborn as something cutting edge, distinctive, and thrilling in the modern age of video games.

Even before beginning work on XCOM , we heard it all before: Games had become too easy. The development (or marketing) buzzword “accessible” translated to “dumbing down,” the idea that developers would take an otherwise deep, rich, and satisfying game and distill its intricacies to its barest form so the entirety of the world could understand, buy, and play said game.

It sounds hyperbolic, but I’ve seen games with easy modes that literally played themselves, making failure impossible, so this stigma against accessibility wasn’t without merit! Making a game “for the masses” could be the ultimate transgression, especially for a complex game with a hardcore past, and we anticipated that XCOM fans would be skeptical that our work would hold up to those who fell in love with the original.

While UFO: Enemy Unknown may have been magnificent, it was also a unique beast when it came to beginning a new game. We often joked that the diehards who mastered the game independently belonged in an elite club, because by today’s standards the learning curve was like climbing Mt. Everest.

As soon as you fire up the original, you’re placed in a Geoscape with the Earth silently looming, and various options to explore within your base—including reading (unexplained) financial reports, approving manufacturing requests (without any context as to what those would mean later on), and examining a blueprint (which hinted at the possibility for base expansion), for example—the player is given no direction.

Even going on your first combat mission can be a bit of a mystery (and when you do first step off the Skyranger, the game will kill off a few of your soldiers before you even see your first alien—welcome to XCOM!). While many fans on the team found this learning curve to be a part of the game’s charm and wore it as a badge of honor, we ultimately knew that, in 2012, we needed to enable gamers to experience the truly fun elements without overly testing their patience. But neither could we bear to dumb XCOM down.

We were on a mission to flip the perception on streamlining, to remove the stigma that accessibility equaled a dirty word. We wanted anyone to be able to give XCOM a whirl without expecting them to become fluent in the game’s many systems on their own accord. At the same time, we needed to preserve all of the richness, depth, and challenge ingrained in the core pillars. If someone wanted to walk away from the experience due to the game’s challenge, we were okay with that; but we didn’t want to alienate anyone simply due to a lack of information.

To accomplish this, we built an optional, integrated tutorial that peeled off the components of XCOM one layer at a time. It was important to keep this hour-and-a-half experience optional, as experienced players could save Earth again without the tutorial force-fed to them (and we also knew some players, even in 2012, would want that old-school badge of honor by skipping the tutorial altogether, which is somewhat appropriate for certain types of X-COM fans).

The introduction to the game wasn’t the only area we redesigned. Jake and the design team refined low-level mechanics from the original, such as removing Time Units and capping the squad loadout at six. Both of these changes were the result of internal playtesting over the course of many months, with the development team finding a combat “sweet spot” with respect to approximate time spent on a map and number of decisions made per turn (we found, depending on map size, battles should average 20 minutes, not to exceed 50 minutes on the absolute longest missions). Six units also made every decision vitally important, promoting group tactics with no moves feeling like unnecessary filler.

This “new era of accessible” mindset also helped the design and user interface teams build a platform-agnostic experience. This is an element that could have gone horribly wrong (and did have its inherent challenges, detailed later), but the team did an admirable job of crafting a historically PC experience for consoles as well. We knew games like XCOM weren’t traditionally available on Xbox 360 and PlayStation 3, but we’re extremely happy we could provide the same experience (without compromising features or “dumbing down” the console versions) across all platforms.

The developers at Firaxis are extremely professional, with each discipline playing the hero role at some point and overcoming monumental obstacles throughout development. From the audio group to the animation and narrative team, they were continually course-adjusting due to dependencies, yet still producing incredible content to polish the game.

On the engineering front, months of changing design had to be technically supported in many complex situations. Systems were built, iterated upon, and some were even discarded after determining a new direction was needed. For example, over the course of a few milestones in midproduction, design asked for sightlines to be drawn from every game unit, soldier, and alien alike, so it was clear what each unit could see.

Our graphics engineering team and artists diligently worked to make this system digestible, but unfortunately, it was tough for the player to determine what was going on amidst the plethora of multicolored lines. After months of trying to get sightlines to work, we eventually realized that the strongest solution was to remove them.

There were plenty of other challenging systems to decipher: the building visibility system underwent various ceiling, wall, and floor rule changes; destruction fidelity fluctuated through a shaky toughness system; and the fog of war was a full 3D cloud early in production, which proved to be a nightmare for both graphics engineering and performance.

Additionally, each gameplay layer (combat and strategy) received drastic overhauls after months of playtesting. In all of these cases, initial engineering efforts had to ultimately be thrown out. To the team’s credit, they understood the nature of iterative design and admirably continued to put in the time needed to make the game a better experience.

In addition, the engineers banded together in a Herculean effort to fix thousands of bugs in postproduction. XCOM is a large, system-driven game with many procedural elements. This meant that many bugs were not only difficult to reproduce, but challenging to even find! Together, engineering raised the bar of the final player experience by squashing these bugs feverishly. Obviously, we couldn’t find and fix every bug, but we’re proud of the effort given in the race to the finish line.

The art and content teams also worked minor miracles. A primary example was the game’s levels. We all love maps and levels, and want more of them; but they are a nexus of many different disciplines somehow crafting the same sculpture all together, and this requires tight coordination and lots of time. Firaxis had never created a level-driven game before (with a strategy system still on top of it, no less), so we had to learn how to build a pipeline that would let us efficiently design and build level assets.

This specifically required an inordinate amount of collaboration between level design and level art, weeks of gameplay testing and feedback per map, and an extreme amount of content creation (we needed to have approximately enough maps for two full playthroughs). In the end, our modestly sized level team ended up exceeding the original goal of 70 unique maps.

Beyond levels, there was still an entire headquarters to build on the strategy layer, with dozens of expandable rooms that could be hand-placed by the player. After making various isometric prototypes, we realized the base wasn’t nearly as gripping as we’d like; something was missing.

Lead technical and HQ artist Dave Black pitched the “ant farm,” a diorama-style side view that instantly connected with the entire team. This was an entirely new process as well, but Dave and the art team concurrently exceeded expectations on headquarters while finalizing all of the combat maps.

We’ve heard countless horror stories about publisher-developer relations, with publishers stifling creativity, dictating direction, or creating impossible deadlines—but our partnership with 2K Games was not one of those horror stories. While there was give-and-take from both sides (as in any relationship), we were overwhelmingly happy with 2K Games’s support—especially considering no major publishers have funded a large-scale, multiplatform, turn-based strategy game in recent memory.

2K believed in our vision and greenlit the project, something we’re not so sure would have happened elsewhere. The 2K Product Development group believed in the potential for a reimagined XCOM and also understood that taking risk was necessary. We were ecstatic to learn we would be given this opportunity.

Furthermore, 2K trusted in us as a studio to own the creative direction of the title. While they provided in-depth milestone feedback, every item was up for discussion, and they ultimately trusted in our design vision. 2K also provided us with additional resources to build an integrated tutorial, something that became critical late and ballooned beyond our initial resource estimations. This type of support proved invaluable to finish the game.

Also, 2K’s public relations team was instrumental in raising the awareness for XCOM. They took the time to understand the vision and value of the project, and allowed the team leads to directly and candidly communicate that vision to the player base. PR worked diligently to uncover many valuable opportunities for the game, including a cover reveal with Game Informer magazine and various demo presentations to targeted press.

These presentations planted the seed in our most passionate advocates—the press—to pass along what they liked (or disliked) about the game’s potential. There was also a strong working relationship between PR and the development team, leading to joint initiatives like the “Jake Solomon Undercover” video and exciting panel discussions like PAX’s “1000 Stupid Ideas on the Road to Glory.”

[embedded content]

XCOM required constant design iteration, with some features being implemented beyond Alpha. It may sound cliché, but Firaxis has always lived by the mantra “Find the Fun,” and the company takes that very seriously. Sometimes, fun can be a challenge to find, especially in a product that is unlike any other we’ve built before. XCOM boasts two interdependent systems that could almost be standalone games, and discovering that special synergy between the two was the key to unlocking the magic within the XCOM universe.

Trying to focus concurrently on both gameplay layers was challenging. We spent various milestones on certain features that didn’t progress as we’d hoped. By midproduction, the strategic layer was a turn-based card system for various months, and it stagnated while the team focused on improving combat. Ultimately, the strategy layer was molded into the version we’re satisfied with, but it was neglected for too long and required a late Half-Life-inspired Cabal process to get there.

We (myself, Solomon, and other members of the dev team as necessary) would meet every morning, every day, until each component of the strategy layer had a concrete game plan and a clear implementation schedule. Additionally, the tutorial and narrative, critical components of the game, couldn’t be pushed to final until the design was locked. And since the design tentpoles ran late, the narrative team (including animators, writers, and audio) came under immense pressure to finalize high-quality cinematics in an extremely short timeframe.

The extra design time helped make the game as good as it could possibly be from a gameplay perspective, but it’s worth asking whether we could have made tough calls on certain systems earlier in the schedule. This is one of game development’s largest challenges: Holding a game’s design to immovable deadlines can be stifling to the iterative and tricky-to-quantify creative process.

Shipping an unpolished combat game with a completely disconnected strategy layer would have spelled disaster for the future of XCOM, so we kept the process malleable much later into the schedule, allowing the team to find the answers through discovery and experimentation.

Practices like the design cabal helped the team focus on areas of the game that weren’t fun, but in a perfect world, we would have locked down as many high-risk systems as possible as preproduction wrapped up. We did ultimately cut content, but the bulk of our wishlist shipped in the final product, which was great for the game but taxing on the team.

By Alpha, only a few systems needed to be implemented, but a new challenge was looming around the corner: the bug database. Before Alpha, the team had a good sense of the state of the game and which systems were most playable, but it was difficult to quantify the true workload until QA began fully testing the game for a few weeks. The reported bug count rapidly multiplied like termites silently infesting the framework of an otherwise beautiful house.

Initially, we weren’t quite sure what to expect, but as the picture became clearer, we knew we were in for an inordinate effort to keep pace with the influx of bugs. There were concerns about the amount of work needed to fix the game relative to the engineers on the team. We had a ship date to hit and we wanted to get our dedicated engineers help.

But the mythical man-month is a very true concept. While our publisher was generous with additional resources to assist toward the end of production, we found that a flood of external helpers had undesired consequences. Knock-on bugs due to unfamiliarity with the codebase, content that needed to be fixed by internal artists, and communications inherent in outsourcing relationships all led to an extreme amount of overhead that ultimately fell onto the laps of internal team members who were already responsible for an aggressive workload.

Outsourcing challenges also hit the content-creation team during production. Communicating with an external cinematic team overseas led to a staggered communication channel. Since there were dozens of unanticipated clerical issues just to get their tools up to speed with ours (no fault of theirs), it was extremely challenging to troubleshoot any setbacks. Also, providing creative feedback to most external partners often led to significant delays due to the remote feedback loop and misinterpretations of feedback via email.

Once we were late into production, the leadership team wanted to maximize each developer’s working hours by being judicious regarding meeting requests, even amongst ourselves. Process-driven meetings were reduced along with costly, 20-plus-person large-scale meetings. We still maintained informal but intimate one-on-one reviews with each discipline’s lead, which was intended to be more focused and fruitful per developer. While the leadership team and some team members appreciated this, others were understandably yearning for additional official communication channels.

Also, team members wanted quicker information on the high-level changes to the design of the game, but with our lead designer doubling as a gameplay engineer, he would often be tied up with coding. Finally, cross-discipline groups (like level design and level art, and feature-specific teams) surely could have benefited from a more formalized stand-up process, which we implemented toward the end of production.

Moving forward, the leadership team knows it needs to strike an appropriate balance between optimal information flow and excessive meeting time, hedging toward more opportunities for formal communication.

Not only was the game structure of XCOM unlike anything the studio had built before, this was also the first time we’ve had to concurrently develop versions for three different platforms. It turned out managing all three was a massive amount of work.

Design-wise, the team knew there would be feature parity between PC and consoles; the only difference would be the control scheme. While the design and UI team did an admirable job on this front, there were continuous challenges throughout development to accommodate multiplatform user interface design, specifically tied to this genre. The team had to ensure all tactical commands were accessible via gamepad, and this involved quite a bit more than accommodating a point-and-shoot mechanic.

The movement system, mapping a system to support dozens of contextual abilities, and crafting a uniform Shot HUD were just a few areas that took time to master across the board. While this specific instance arguably didn’t go “wrong,” it is a small example of the multiplatform challenges faced daily.

The system-specific optimizations needed for each platform were significantly more difficult, particularly for the consoles. Understanding the console constraints for items like number of maps, audio files, texture budget, and animation sizes was a continual process between engineering and the specific disciplines. There were also severe, system-specific bugs, technical requirements, and crashes that ate up much of our senior engineers’ time.

Our systems engineering team was a very talented duo, but they didn’t have a dedicated platform engineer, which meant that they had to partner on all of these complex issues across the board. While they worked together effectively, they simply had too much work on their plates: universal systemic issues, art optimization requests, and other general and technical requirement bugs, just to name a few major workloads.

Our lead engineer assisted on the most difficult issues when he was free from putting out other fires, and another internal systems engineer joined the cause late in the project to own the Xbox 360 technical certification requirements, but these were solutions that emerged late in development.

We’re not proud about the fact that we had to crunch to finish XCOM. We have a dedicated and passionate team, and all team members put in serious extra hours at some point for the good of the project. For many, the malleable structure of the game led to frustration as we were knee-deep in the trenches. Certain dependencies were continually pushed (especially impacting audio, effects, cinematics, and user interface) and the lack of testing on late gameplay systems led to a heavy bug load for the engineers.

On the art side, the content creators had production crunches to finish all maps. As said before, this was the first time we created a game of this structure, and the first time we had to iterate so much on the process itself. While we improved certain inefficiencies throughout production, we simply couldn’t accurately predict how much time we’d need to make the game the way we wanted to make it.

In the end, we avoided permadeath. And after all of the extra hours, the thousands of bugs fixed, the hundreds of level playtests dissecting every piece of cover, the dozens (hundreds?) of gameplay prototypes and healthy debate that accompanied each new system, through every team meal, and in the wake of every hopeful or concerned hallway discussion, in the end, the XCOM development team emerged victorious.

We shipped the project within weeks of our original target release date, earned a near-90 Metacritic from video game journalists, garnered hundreds of game accolades, and won 13 Overall Game of the Year awards. Most importantly, a wildly creative and cross-discipline team banded together to contribute to the unlikely revitalization of a classic game, capturing the magic of X-COM for a new generation of gamers and hardcore fans of the original alike.

Posted on Leave a comment

Video Game Deep Cuts: XXX Loot On Your Steam Death

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.

[Video Game Deep Cuts is a weekly newsletter from curator/video game industry veteran Simon Carless, rounding up the best longread & standout articles & videos about games, every weekend. 

Some of the highlights include more loot box opinions, the history of the ill-fated BMX XXX, what happens to your Steam account when you die, and more.

All kinds of interesting links out there this week – and I’m increasingly intrigued by this ‘premium game + DLC/loot boxes’ conundrum linked below. Are big developers and publishers being ‘greedy’ by resorting to this method, or are their sales dipping, so they are trying to get back to ‘even’ by getting more money off bigger fans? Some games are clearly doing it very wrong. 

Also, let’s not forget that many NES/Super Nintendo games cost $50, decades ago, so the cost of premium games hasn’t kept pace with inflation (at all, actually, since many prime Steam Early Access games cost closer to $20-$30.)

Ultimately, I guess the end goal is clear – charge the amount of money for the game and its extras that makes the majority of your players still like you. (It’s more about sentiment per game than a particular formula?) And personally, I don’t have any issue with cosmetic loot boxes that bring you fun extra stuff. But YMMV – and probably does!

Until next time…
– Simon, curator.]


Behind the addictive psychology and seductive art of loot boxes (Alex Wiltshire / PC Gamer)
“Loot boxes are everywhere. They’re in shooters, RPGs, card games, action games and MOBAs. They also take the form of packs, chests and crates. They’re filled with voice lines, weapon skins, new pants or materials to get you more loot boxes.”

A dog has turned my life into an RPG (Christian Donlan / Eurogamer)
“I met a mysterious old man this last Saturday. He told me he was 87, and I did not believe it. Then, to prove it, he lifted his huge round sunglasses and made me stare at his eyes, which were light blue and rather milky with cataracts. “Still don’t believe it?” he asked. I told him that I still did not believe it, and he laughed, delighted.”

Nintendo Classic Mini: SNES developer interview – Volume 4: Super Mario Kart (Akinori Sao / Nintendo)
“We began with experiments for a multiplayer F-ZERO game. In F-ZERO, you race at over 400 kilometres per hour along incredibly long straight lines, but we realised that splitting the screen into upper and lower portions for two players to do the same thing was out of the question.”

Inside the development of Conan Exiles: The Frozen North (Gamasutra staff / Gamasutra)
“A few months ago, Gamasutra brought Conan Exiles creative director Joel Bylos onto our Twitch channel to discuss Funcom’s hit online survival game. Recently, Gamasutra’s Bryant Francis and Kris Graft had the pleasure of speaking with Bylos again about the game’s launch on Xbox One’s preview program, as well as the design of the game’s  new Frozen North expansion and what new features can be expected from it.”

The inside story of the Xbox One X (James Temperton / Wired UK)
“In the former document archives of a Seattle-based insurance firm lurks the quietest room in the world. The human ear can hear down to zero decibels. Here, the sound of silence has been measured down to negative 20.  [SIMON’S NOTE: this is archetypical Wired puffery, but also entertaining at the same time!]”

Designer Notes 32: Asher Vollmer (Soren Johnson / Designer Notes / Idle Thumbs)
“In this [podcast] episode, Soren interviews independent game developer Asher Vollmer, best known as the designer of Puzzlejuice and Threes. They discuss why paper prototypes don’t always translate well into video games, whether a game should take up 100% of your brain, and how he feels about the Threes clone 2048.”

The Story of CD Projekt – Witcher Documentary (Noclip / YouTube)
“In the opening episode of our six-part series on The Witcher, we talk to Marcin Iwiński about life in socialist Poland, the business of games distribution and the founding of CD Projekt. [SIMON’S NOTE: a bunch of the other episodes are already up!]”

‘It Made Absolutely No Sense:’ The Story of ‘BMX XXX’ (Blake Hester / Motherboard)
“Playing BMX XXX is mostly like playing every other action sports game: You ride your bike around a level, do tricks, and score as many combos as possible. In the early 2000s, this was nothing new. Thanks to the popularity of Tony Hawk’s Pro Skater,action sports games were the thing. The only difference is, in BMX XXX, game characters are not famous BMX pros, they’re sometimes naked women.”

‘God of War’ Hinges on the Bond of Its 2 New Actors (Patrick Shanley / Hollywood Reporter)
“The anticipated video game’s leads, who have spent years working as Kratos and his son Atreus, can finally reveal secrets about the antihero’s new direction: “He’s definitely a changed person.””

How the biggest theft in EVE Online history ended in death threats (Brendan Drain / RockPaperShotgun)
“From record-breaking heists and scams to public assassinations and spy infiltrations, New Eden has been home to some incredible tales of espionage, theft, and political intrigue. This month another chapter in EVE’s long and bloody history came to an abrupt end as two players conspired to pull off the biggest political betrayal and theft of assets in the game’s history.”

What happens to your Steam account when you die? (Chris Bratt / Eurogamer)
“Chris Bratt delves into what happens to your Steam account once you die, discovering that you can’t easily leave a digital library to a friend or loved one even if you were to write it into your will.”

A Problem With Modern DLC (Raycevick / YouTube)
“[SIMON’S NOTE: one of the better analysis video channels on YouTube delivers again.]”

The World Record History of Super Mario Sunshine any% (AverageTreyVG / YouTube)
“In this video, I explain the entire history of world record speedruns for the any% category of Super Mario Sunshine – from its release in 2002 to the current day (September 2017). This game has a rich history of trick discoveries, rivalries, movement optimizations, and dominant players that seemed unbeatable in their time. [SIMON’S NOTE: I guess there’s a whole subgenre of speedrun history analysis, wow!]”

How Sony’s biggest failure led to an indie renaissance (Matt Suckley / ZAM)
“The PSP Go came out when Apple’s App Store had already begun to make mobile games mainstream, but had not yet given rise to the multi-million dollar free-to-play giants we recognize today. Instead, the marketplace bristled with low-priced slices of creativity from small studios that could have only dreamt of such exposure previously, and certainly weren’t represented on PlayStation.”

What’s up with all these niche ‘hardcore realism’ games from Eastern Europe? (Jessica Famularo / Gamasutra)
“Over the course of the past five years or so, there’s been a rise in hardcore, realistic games coming from Eastern European developers: a shooter with military-grade tactics; a true-to-life medieval times simulator; fantasy RPGs with intricately branching dialogue trees and brutal strategic combat.”

Now Ubi’s opened the door, can we have our “Skip Boss Fight” button? (John Walker / RockPaperShotgun)
“Ubisoft made a fascinating announcement this week. They revealed that the latest Assassin’s Creed is to add a “Discovery Tour” mode, removing all the combat and challenges from the game, to let players just freely experience their in-depth recreation of Ancient Egypt.”

The Evolution of Rodeo in Titanfall 2 (Chin Xiang Chong / GDC / YouTube)
“In this 2017 Game Developers Conference talk, Respawn Entertainment’s Chin Xiang Chong leads viewers on a guided tour of the development of ‘rodeo’ gameplay in the Titanfall series, including looks at early prototypes & meditations on the lessons learned.”

Games on the Mersey, Part 5: The Lemmings Effect (Jimmy Maher / Digital Antiquarian)
“It was another member of the DMA club, Russell Kay, who looked at the animations and spoke the fateful words: “There’s a game in that!” He took to calling the little men lemmings. It was something about the way they always seemed to be moving in lockstep and in great quantities across the screen whenever they showed up…”

Where Video Game Conventions Draw 300,000: Not in the U.S. (Laura Parker / New York Times)
“Next week, 300,000 video game fans, developers and publishers like Sony, Ubisoft, Activision and Microsoft plan to congregate so they can showcase their wares and participate in a cosplay zone, an e-sports tournament and a 48-hour jam. Their destination: São Paulo, Brazil. [SIMON’S NOTE: there’s a reason that I popped out my monocle reading this article which I’ll explain at a later date!]”

Daytona USA: why the best arcade racing game ever just won’t go away (Will Freeman / The Guardian)
“Released in 1993, and available in a variety of cabinets from basic standing model to full-on deluxe recreation of the player’s 41 Hornet car, Sega’s masterpiece always pulls a crowd. And not just in this specialist coin-op den.”


[REMINDER: you can sign up to receive this newsletter every weekend at – we crosspost to Gamasutra later on Sunday, but get it first via newsletter! Story tips and comments can be emailed to MINI-DISCLOSURE: Simon is one of the organizers of GDC and Gamasutra & an advisor to indie publisher No More Robots, so you may sometimes see links from those entities in his picks. Or not!]

Posted on Leave a comment

Fire Emblem Heroes: a new update and more events

Fire Emblem Heroes: a new update and more events

To celebrate the 1.8.0 update for the Fire Emblem Heroes game, from 10/9/17 at 12:00 am to 10/22/17 at 11:59pm PT, you can get Orbs up to 10 times from a Log-In Bonus! These Orbs can be obtained from your Present List.

Features of version 1.8.0:

The Sacred Seal Forge Opens Up
A new option, Sacred Seal Forge, has been added to the game. Using it, you will be able to both create new Sacred Seals and enhance existing Sacred Seals.

You can access these functions after clearing the Intermission map, named “Awakening Ancient Power”, which appears after clearing Chapter 13, “Diabolical Bloodline”, in the Main Story mode.

Sacred Coins, Badges, and Great Badges are what you use to power the Sacred Seal Forge.

Beginning with version 1.8.0, Sacred Coins can not only be earned through the Arena Assault mode, but also through quests, Tempest Trials, and other new places in game. Badges and Great Badges can still be earned in Training Tower, but starting from version 1.8.0, you’ll earn even more of them.

Use Sacred Seals to enhance your army’s strength on the battlefield! Please note:

  • The Sacred Seal Forge can be accessed from a new Sacred Coin icon on the Home menu, or by going to Advanced Growth in the Allies menu.
  • Sacred Seals that can be created and enhanced will continue to be added to the game.
  • You cannot own more than one of each Sacred Seal.

It’s Easier to Change Teams

  • Before going into battle, you can now quickly move from the confirmation screen to the Edit Team screen.
  • After you decide on your team, tap the back arrow to return to the confirmation screen.

Quick Questing
Three new functions have been added to make quests easier to access.

  • You can now move to the appropriate map directly from the quest list.
  • Symbols have been added to mark maps that have quests to complete. (Quests available across multiple difficulties will only be marked at the easiest difficulty.)
  • Quest information can now be checked before deployment.

Now that quests are easier to access, try and earn even more rewards!

Easy Auto-Battle
An Auto-Battle button has been placed on the menu at the bottom of the battle screen. Activate it by accessing the Settings screen and setting your preferred option for Auto-Battle Button.

  • If the Auto-Battle Button is switched on, the weapon triangle will no longer be displayed while playing Arena Assault.

Take advantage of special events!

Voting Gauntlet: The Blood of Dragons
10/9/17 at 12am to 10/14/17 at 8:59pm PT

Eight Special Heroes from The Blood of Dragons are going head to head! Get in on the action before it ends on October 14 at 8:59pm PT.

Bound Hero Battle: Minerva & Maria
10/11/17 at 12am to 10/17/17 at 11:59pm PT

Sister princesses of Macedon from the Fire Emblem: Mystery of the Emblem game appear in battle in Special Maps – it’s Bound Hero Battle: Minerva & Maria!

Challenge your skills on Hard through Infernal difficulties! You can also obtain Orbs the first time you clear the battle.

As with other Hero Battles, if any of your allies fall in battle, it’s game over, so proceed with caution. Bound Hero Battles also have a special rule: you cannot use a Light’s Blessing or an Orb to continue a battle if you lose, so make your moves on the field very carefully!

Summoning Focus: Minerva & Maria’s Battle
10/11/17 at 12am to 10/17/17 at 11:59pm PT

Check out this summoning focus featuring sisters Minerva and Maria, as well as Palla, the eldest of the Whitewings, from the Fire Emblem: Mystery of the Emblem game – part of the Bound Hero Battle: Minerva & Maria! For new summoning events, the first time you summon, you won’t have to use Orbs!

Learn more about these updates and events, and more about the game at the official site.

Game Rated:

Fantasy Violence
Suggestive Themes
Partial Nudity
Digital Purchases

Posted on Leave a comment

How the Blade Runner game ensured players never knew who to trust

“Every time a player started a new game, the dice would pick whether characters were replicants or not.”

– Playful’s David Leary, reminiscing with Eurogamer about his work on Westwood Studios’ Blade Runner adventure game.

There’s a new movie out this week bearing the name Blade Runner, and that seems to have at least partially inspired Eurogamer to revisit Westwood Studios’ 1997 PC adventure game of the same name.

Released more than a decade after the original film, Blade Runner is a game devs should know about because it did something very rare in the ’90s: it presented players with a detective story that changed every time you played.

“Every time a player started a new game, the dice would pick whether characters were replicants or not,” Leary told Eurogamer, recalling how he helped out on the game and coded a script that would (presumably semi-)randomly dictate which characters were secretly robots. 

“Creating the code was not that technically difficult,” he continued. “The challenge was to make sure the pieces wouldn’t fall apart.”

He goes on to talk about those challenges in a bit more detail in the full article, which is well worth reading over on Eurogamer.

For a bit more historical insight into Westwood’s often-overlooked Blade Runner game, check out Gamasutra’s own 1998 interview with Westwood cofounder Louis Castle, in which he discusses everything from the intricacies of fitting the game on 4 CD-ROMs to the challenges of simulating cool 24-bit smoke and mist effects on 16-bit graphics cards.

Posted on Leave a comment

Game devs help raise nearly $400k during One Special Day charity event

There’s some nice news out of the U.K. this week, as Oxfordshire-based charity organization SpecialEffect announced today that it has raised over £300k (~$392k USD) to fund its charitable work during its recent One Special Day fundraising event.

This is a big deal because SpecialEffect’s mission in life is to help people with disabilities play and enjoy video games. 

To that end, the One Special Day (which was, incidentally, September 29th) fundraising effort was supported by studios and companies across the game industry, encompassing everyone from 505 Games to Double Fine to Unity to Zynga. 

SpecialEffect had set a fundraising target of £100k, and with that thoroughly surpassed it has announced that the next One Special Day will take place next year on the 28th of September.

Devs curious to learn more about SpecialEffect’s efforts and how to support them can do so via the organization’s website.

Posted on Leave a comment

Gamasutra plays the Star Wars Battlefront II multiplayer beta

We do love Star Wars here at Gamasutra. And since now we’re actually getting new Star Wars games (and not just updates to the first Battlefront from EA), we were excited today to play the multiplayer beta for Star Wars Battlefront II on the Gamasutra Twitch channel. 

Now that our space adventures have concluded (with many explosions but few lightsabers), we’ve done the due diligence of uploading them for your viewing convenience. If you’re curious about the multiplayer beta (and what our thoughts are on the broader design of the Battlefront series), you should watch!

And while you’re at it, be sure to follow the Gamasutra Twitch channel for more gameplay commentary, editor roundtables and developer interviews. 

Posted on Leave a comment

Video: Game career advice from women who have been there and done that

Getting started in the game industry is hard! Luckily, there are lots of people who have done it and are passionate about helping others do the same.

A number of those people took the stage at the Career Seminar during GDC 2017 to offer would-be game devs — especially women — some advice gleaned from their own experiences entering the game industry and working at companies like Hangar 13 (Mafia III), Microsoft/343 Industries (Halo 5) and more.

It was a great set of microtalks, packed with advice meant to help anyone who has felt marginalized, pushed aside, or lacking in confidence.

It’s well worth watching, as you’ll probably walk away with practical tips and tricks you can use on your path to a meaningful career in game development. Now, you can do so completely free via the official GDC Vault YouTube channel!

In addition to this presentation, the GDC Vault and its new YouTube channel offers numerous other free videos, audio recordings, and slides from many of the recent Game Developers Conference events, and the service offers even more members-only content for GDC Vault subscribers.

Those who purchased All Access passes to recent events like GDC, GDC Europe, and GDC Next already have full access to GDC Vault, and interested parties can apply for the individual subscription via a GDC Vault subscription page. Group subscriptions are also available: game-related schools and development studios who sign up for GDC Vault Studio Subscriptions can receive access for their entire office or company by contacting staff via the GDC Vault group subscription page. Finally, current subscribers with access issues can contact GDC Vault technical support.

Gamasutra and GDC are sibling organizations under parent UBM Americas