Press "Enter" to skip to content

Month: August 2016

A pitching masterclass through No Man’s Sky

Over the past few days, my constant No Man’s Sky ramblings on Twitter have led to a number of interviews from domestic and international press about the game. One thing that really caught me off-guard was just how hard it is to pitch No Man’s Sky. I decided to spend some time today looking at Hello Games’ pitch for No Man’s Sky, and came away rather impressed at the care and effort that must’ve gone into iterating the high-level concept pitch. This isn’t specifically about the expectation management, or the details or minutae of the game, but how the core of No Man’s Sky was communicated – the cumulative exploration of a procedural universe.

So here are the things you would probably try, that I’ve found to be ineffective:

  • Mentioning space exploration as a thematic, or referring to other space exploration themed media doesn’t work.
  • Explaining that the game is practically infinite, and allows for infinite exploration doesn’t work.
  • Comparing it to other media, say a movie, or a performer or musician, doesn’t work.
  • Explaining the disproportionate amount of content for its download size doesn’t work.
  • Explaining that thanks to the procedural generation, everything you see or encounter is unique to your game experience doesn’t work.

The main objections you should consider for each of these is ‘is there a context’ and ‘does anyone care?’. So one by one:

  • Mentioning a genre is not a powerful pitch, nor does it emphasize the strengths of the game. Comparing it to other media doesn’t work, because the general audience tends to assume games can be photorealistic, infinite, and capable of simulating reality rather well.
  • The general audience does not care that the universe is infinite, because many assume all games are infinite. I’ve mentioned this before, but most non-gaming people don’t directly assume Grand Theft Auto isn’t an infinite world beyond the city borders, and don’t realize a Call of Duty game takes place in a map rather than a country. The question of game world size doesn’t occur, because that’s an abstract idea that requires an understanding of game boundaries, and a context of game worlds.
  • To most people, games are not movies, music or any other such form of art. Comparing a digital piece of software to something where they see people perform will never work. A board-game or other physical game is the closest metaphor people would accept and understand – and those are woefully inappropriate to explain No Man’s Sky’s experience.
  • Apple famously stopped using Gb/Tb to discuss their storage space, and now uses a made-up statistic of ‘how many photos, songs or movies will fit on this device’. The average person does not understand data storage, data requirements and data limits. They just know when a device is full, and then generally assume it’s the devices fault.
  • Procedural generation is not something you can explain easily to someone without a basic understanding of deterministic mathematical models, or without an existing context for what it leads to, like seeding in other games.

So what remains? Well, it turns out Hello Games figured out a pretty impressive way of communicating the game’s core.

  • They properly identified that communicating the astronomical size of the game in terms of our own universe works. No Man’s Sky is a game in which there are 18 quintillion planets (wow, a number that sounds bigger than a trillion!). Even if a planet was discovered every second by a player, our own actual sun -not the one in the game!- would die before every player in the world combined would have seen them all (wow science). Not that they specifically avoided the term infinite, because infinite sounds videogame-y and doesn’t actually sound all that special. 18 quintillion sounds specific, and scientific.
  • They properly identified that emphasizing that even the developers of the game are shocked to see what can exist in the universe is evocative. In fact, they’ll mention, the developers haven’t seen all that’s available in the game – and they’re commonly excited to land on a planet to see something new (if even the creators are, it must be true). The developers didn’t create the planets, or the creatures on it, they instead programmed the laws of evolution and physics into the computer and let it simulate a universe (impressive!).
  • They properly identified that a top-down approach works really well in words, but bottom up works really well in visual. Their pitch starts with talking about the universe, and then goes down through planets and creatures, down to the elements (so much detail!). Their videos tend to start with the periodic makeup of a place, then a creature, then a planet, eventually zooming out to the universe. A universe isn’t a scale or mental model most people can grasp, but it is a thing that’s easy and impressive to show (so much scale!).

Note if you shuffle this around into three recognizable focus points, you also start seeing how these communicated back at the normal gaming demographic.

  • The ‘science’ in ‘science fiction’ and making it sound as scientific as possible: the game has its own periodic table, there are specifically 18 quintillion planets. Science fiction is clearly something the Hello Games’ crew is naturally excited about, and thus a great primary talking point. Also note the appeal to traditional gaming demographics’ geekdom here.
  • Scale in relation to our own universe, explained using the Apple method: it is statistically improbable for two people to reach the same planet, if a planet was discovered every second our own sun would die before we’d have seen them all. Note the ‘completion time’ wink at the normal game demographics here.
  • Uniqueness of the experience: even the developers themselves are surprised at what they find on new planets, and it is statistically improbable for two people to find the same planet. Note the implicit challenge to traditional gaming demographics here.

Looking at the challenges they faced in communicating the game to this many people of varying understanding, Hello Games’ No Man’s Sky core pitch is a little masterclass in explaining an abstract concept to the largest possible audience.

I also promise that there’s only one more No Man’s Sky post in my queue for now.

Patch The Process

No Man’s Sky didn’t send out review builds because the game wasn’t done. No Man’s Sky gets leaked by resellers breaking street date. Polygon, Kotaku, and numerous streamers obtain a copy before release date and play it. No Man’s Sky developer and the platform holder both say the game isn’t final. No Man’s Sky developers shows changelist for the Day 1 patch to stop this nonsensical discussion about a build that wasn’t meant for the public. News hits No Man’s Sky is getting a ‘huge’ Day 1 patch that’s going to fix many of the issues.

I want to talk about Day 1 patches, but I don’t want to talk about No Man’s Sky. Since this is ‘controversial’ at the moment, I want to emphasize that I am not affiliated with No Man’s Sky. I’m not attacking nor defending No Man’s Sky. I’m not speaking on their behalf, nor do I have any insight into their process. This post isn’t even about No Man’s Sky. I’m just going to use No Man’s Sky as an hypothetical example, but this could apply to pretty much every single game that’s available today, whether it’s digital or physical. You also need to realize a lot of what I’m about to discuss cannot be discussed by a developer during the development process for various reasons, including legal contracts we have to sign to be allowed to release a game. This is also the reason I have to be vague about the details, and each of my statements is not about any specific console manufacturer or platform holder but sort of about all of them and none of them at once. Most of these things have been mentioned before in public discourse in some form or another, and I have to emphasize the examples aren’t from any one specific console manufacturer either, and might be hypothetical, modified or altered to avoid mentioning things too specifically. This is pretty much the most transparent I can be while staying without breaking NDA’s I’ve signed to be allowed to publish on all major console platforms.

There’s two things that are relevant here:

  1. Consoles are platforms and devices that come with an expectation of quality, and as such have systems in place to ensure that quality.
  2. Developers are creatives working on a commercial schedule, leading to the ancient and never-broken rule that a developer will always be two weeks late for their deadline – no matter how big or small the deadline is.

When you make a game for console – no matter which one – you have to realize the systems developers and platform holders are dealing with weren’t built for 2016. These systems are legacy systems, built upon legacy systems, built upon legacy systems. It’s like the system you are or were forced to use at your day job, if you’ve ever worked in retail, stock or booking systems, or at any checkout. Many of these systems interface closely with bureaucracy and console technology, and instead of radically changing how systems work between generations and breaking everything at a console launch, console platforms tend to try and not break things that work. As such, many of these systems are unwieldy, complicated, intricate and really built for teams that can afford to hire more people to read the manual and figure out the systems. These systems come from an age before indie, and some of the manual pages still refer to mailing copies by postal mail. Despite that, the console creators and their teams all work super hard to ensure developers have a smooth process, improving their systems where possible without touching the legacy foundation, and ensuring players get a functional game.

The most egregious example of this is called ‘certification’. On computer platforms, stores like Steam, Humble, GOG and have decided that developers just have to deal with the fallout of releasing a broken product themselves, and thus allow you to push a product or patch at any point whatsoever (they often do a pre-release check of your store page, though!). Consoles on the other hand, come from the ‘Seal of Quality’ mindset. To ensure that quality, they use a system called ‘certification’, or FQA, or TRC, or TCR, or some other random acronym that refers to something technical and a checklist. Devs like to call this quality assurance process ‘cert’, and no matter what developer you ask, you’ll find most developers understand why it exists, and we all really appreciate all the people working super hard to ensure our games are working right, but we tend to all hate ‘cert’. What you have to imagine when it comes to cert, is a giant book of checkboxes. There’s an absurd amount of them, and they could be different not only per platform, but per territory (for example, a European build has different certification rules than a US one, requiring differences between the two), and sometimes even between a patch, a DLC, and a release version.

Some of these make a lot of sense (don’t crash), and some of these are reasonable (if you leave the main menu open for 24 hours, is the game still smooth?), and some of them sound obscene (if you rapidly plug and unplug the controller, does the game know what to do?). Some of these are enlightening (your game needs to figure out what controller the player is assigned to, thus requiring the ‘Press [button] to start’ screen only console games still have), and some of them are just headaches (don’t put UI in the outer 10% of the screen, unless you use one of those ‘how big is your screen’ interfaces). Some are legal (is any form of parental control activated or is the profile under the allowed age for gameplay? if so, did you disable the required functionality?), and some can make you desperate (the console can not have had firmware updates between your release build and the patch). Did you know consoles don’t necessarily pause your game for you when players switch to other interfaces? You have to do that yourself.

Anyway, certification is a big thing. The process for it is also a big thing. In most cases, you have to fill out a weirdly complex form for your submission, and then ‘book a slot’ of sorts, or wait until you get an OK to submit your game. Since the people testing games aren’t infinite, you need to let people know when you’re submitting your build. So you check which dates are available, and usually there’s a free slot a few days from today. If your build isn’t in a certain amount of time ahead of that, your slot can be lost, and you’ll have to ‘book’ a new one. When the slot starts, and your game goes into certification, there’s a variety of reasons your submission can be rejected, in which case your slot can be lost too. Then, the teams start testing, and they report certification violations to you. In many cases, your violations are graded along a scale from ‘Must Fix’ or ‘Fix This’ to ‘Suggestion’ or ‘Whatever really’. If any of them exceed a certain level, your submission fails, and you have to start from square one and fill out the form, find a free day to book a slot or wait until certification starts, and submit a new build.

Some of the certification problems are impossible to avoid. Developers can’t control when consoles update their firmware, and when engines shift their support for firmware. In those cases, developers can request an exception to a rule. This is a bureaucratic process, and it can require negotiating, a formal request, and formal permission. It takes time. Then, when you get an exception, for most platforms you often need to fill out on the submission form how, where, and from who you got that exception when you submit again.

Did I mention all of this is poorly documented? One console has a field that says ‘assets file’. It doesn’t mention what the assets file is, nor what it does, or what these assets are. If you don’t add the file, it can’t process your submission. If you add it, but it isn’t ‘right’, your build can fail. You lose a week. If there’s a checkbox somewhere in the hundreds or thousands of obscure rules that you missed, you lose a week. If there’s something that’s subtly different between Europe and America, you lose a week. What I’m trying to say is that certification could take a week, and in the worst cases, it could take months. From personal experiences, I can say that it can make developers cry. It could delay your game. At the end, though, the game that launches checks every checkbox. You’ve got your proverbial “Seal of Quality”. Your game is allowed to launch.

Now, I’m not saying No Man’s Sky did this, but in most cases, developers with a launch date need to make sure they can hit that launch date. We start submitting certification builds somewhat early, in the hopes that one of them gets the check mark that says ‘you’re good to negotiate a launch day’. Certification is technical – it doesn’t bother with what the game is, it just concerns itself with whether it works technically. It checks whether the boxes are checked. You can market a dark gritty murder game titled Dark Horses, and submit a pony farm tycoon game, and as long as the name on the form matches the name of the game, they would not object.

So – since development is messy and unpredictable – if you’ve got a build that’s ‘pretty much done’ and it works, and you can get it through certification, that’s a good sign for your final build. So you submit it, it goes through cert, and you stage it for download and launch. For disc games, the game needs to go through certification in time to be printed, boxed and distributed. At that point, developers are usually still one to three months from release, which tends to mean you need one and a half to three and a half months to get the game done, and then you still need to keep in mind that unpredictable amount of time you’ll spend in certification. A day 1 patch is technically still submitted at least one week from launch, but until it actually goes through certification, it can’t be made available to the public.

Knowing that, it should be easy to see why Day 1 patches are often “huge”. For a game that goes on disc, the ‘gold’ build that went through certification is one to three months old by the time the game launches. That gives developers half a month to two and a half a month to do a month and a half to three and a half months’ worth of work to make the game ‘perfect’ while still hitting the release date with the patch. If your studio is huge, you probably have an internal QA department that (for good reason) slows things down internally, but if your studio is nimble and small, you can change enormous portions of the game in that span of time.

So in the hypothetical example of No Man’s Sky, when No Man’s Sky launches, for most people, it’ll launch into the intended experience thanks to the Day 1 Patch. That build is as close to what the developers envisioned as they worked, learned and improved upon that vision. That’s No Man’s Sky. The version that is on the disc, however, is months old. The only way to avoid that kind of thing is to not launch on disc.

One could argue that developers then, should make certain that a game is perfect when they submit it to disc, which is not an invalid stance. It’s just an impractical stance. If you’ve got months to improve upon a game that went through cert, do you think you would leave those months? Do you think audiences would appreciate a developer just kind of doing nothing for three months? Can you imagine the Kickstarter outrage if a developer, three months from launch, posted ‘we’re done, it’s good, we’re not touching it again until you get to play in three months’? Anybody arguing that a game should be done when it goes ‘gold’ is living in the 90s.

Developers care about the games they make, and we’re trying to make the best game we can for our players. We’ll take every opportunity we can get for that. If consoles operated like Steam did, No Man’s Sky wouldn’t have a Day 1 Patch, because the build you’d download and play when it comes out would’ve been submitted comfortably a few days before launch. Day 1 Patches aren’t necessarily a failure on the developers or the platforms side, they the result of people that care about what they make, trying to deliver the game the audience expects by the date they expect it, while everybody involved is struggling with outdated systems on cutting-edge technology. Everyone is trying their hardest. Nobody is doing anything wrong. The developer isn’t lazy. The platforms aren’t malicious. Day 1 patches are simply a patch to a submission system that’s old and convoluted.

The Center Of All Things

Games communicate something from the creator to the player, and as such, carry intent. While I can’t statistically prove it, I’ve come to believe intent is what separates a good from a bad game. Intent creates a direction, an impulse to a design. It doesn’t necessarily start at the idea’s inception – very often a game comes from messing around and experimenting, but at some point an intent must form. When an intent is decided upon, a game can form around that.

Rocket League, a 2015 favorite car-sports game, famously started as a weaponized car combat arena game, much in the vein of Twisted Metal. When a programmer added a ball for a physics test, the team decided to re-imagine the game as the first iteration of Rocket League. This is where the intent came from: create a game about skillfully navigating a ball using cars. Rocket League is many things, but that essence statement summarizes not just the core gameplay mechanics, but also the inherent absurdity and humor of the idea.

When you think about it, most good games can be summarized into simple essences without too much effort. Their intent shines through clearly, and without the designers’ interference. This is why, when I give feedback, or have to greenlight a project, I try to build up to what I expect to be the essence statement for the game, based purely on the build I played. I then question the designers or creators about their game, and try to get them to make an essence statement of their own.

Obviously, I then compare the two statements. If they overlap, the game and the designer have an aligned intent, and I have faith in the game. If not, I try to build a mental model of what led to those separate statements.

Schools often teach the Mechanics-Dynamics-Aesthetics framework to analyze game design, which is a tremendous framework focused on the input-output loop a game creates. While that is an extremely powerful perspective to have on games, I tend to shift focus to the space between Mechanics and Dynamics, and use a personal Intent-Mechanics-Declaration model to communicate flaws in the game design. As always, the model is always in flux, and I doubt I’m the first one to use a model like this. The model is rather simple and by no means exhaustive, but can be most easily communicated as three concentric circles. The Intent is a circle. Around that circle is a larger circle, the Mechanics layer. Around that is a third circle, the Declarative layer.

The Intent is the essence statement, a short and clearly communicable statement that the team working on the game should agree on. It’s important to realize this statement does not have to be exhaustive, and should be considered more along the lines of an architectural parti – something that encompasses the big idea of the game. An essence statement is also not a pitch – it’s used internally. Where Ridiculous Fishing’s pitch was “a game about fishing with machineguns” – a pitch crafted to elicit laughter & interest, internally the goal was to “create a game with an infinite positive feedback loop” – an essence that was pleasant, comfortable and positive no matter the skill of the player.

The mechanics are designed to reinforce the intent, or at the very least not contradict the intent or the other mechanics. This sounds remarkably obvious, but it’s the easiest way to distinguish the average student game from the average professional game. The mechanics are purely the technical state-changes in the game, the values adjusting, the input processing, the ruleset and the ‘deltas’ between two distinct moments in the game based on those rulesets.

The declarative layer, then, is what communicates these ‘deltas’ back to the player. They’re the graphics, the audio, the feedback. It’s each frame of the game rendered (or otherwise communicated) to the player. In other words, the declarative layer is what the player can actually process. It declares to the player that which has changed. Based on that, the players adjust their mental model, create a new intent of their own, and offer input based on their intent. Clearly, the declarative layer should communicate the mechanics and the intent behind them as clearly as possible.

When the model is drawn, you can imagine every decision made in the game as a point in the appropriate layer. The model gains value when you think of the decisions as arrows, drawn from a point in their appropriate layer towards what they’re meant to communicate. If everything is alright, your game should look a bit like a snowflake, with every single arrow more-or-less pointing back towards the center of the circle – the intent.

Considered as a whole, the model should teach you one or two things. The first lesson is that having a clear and easily communicated essence statement early on in development, will avoid disagreements about where the intent is, and as such, it’ll avoid arrows pointing in wildly different directions. The second lesson is that if you apply this model to agame, you’ll usually find some decisions of which the arrows point in the opposite direction of the intent on purpose. A model is not something that should force your hand. A model should guide your decision-making, but never force a decision.

In Ridiculous Fishing, the game we built so carefully to be an infinitely positive feedback loop, we created the second ‘boss-fish’ of the game to intentionally break with that essence. The ending of Ridiculous Fishing, then, again, breaks with the ‘pleasant’ and ‘comfortable’ essence. These moments stand out, because they’re carefully and intentionally opposite.

I use this mental model frequently, not just to give feedback, but also in figuring out what to do with Vlambeer games. You can extend the model further, to include pretty much anything beyond that. I often consider a packaging layer around the declarative layer, for the menus and other non-game interfaces. At other times, I’ll model a marketing layer around the game.

Most experienced designers and creators go through this model somewhat instinctively. Nevertheless, when working with a team, it is valuable to ensure the intent of the game is clear to everybody. Unless a team is remarkably attuned to each other, it is very likely that someone is trying to make a game unlike the game the others think they’re making. A single essence statement, a few keywords, a mock-up of the game, a sketch or silhouette or color palette or small video for the visuals, a sound effect or song to define the sonic qualities of the game – they all help. They declare an intent. They help keeping your game consistent, your team focused and your goals clear.

There’s enough to discuss when you’re making a game without having to argue where the center is.

Beautiful Things

Last week, I visited Tel Aviv to speak at GameIS, an independent games event run by a group of indies and volunteers from the Israeli games industry. It was a phenomenal event, filled with inspiring, aspiring and creative individuals. The event felt vibrant, and was full of interesting projects.

Given my political views in favor of a Palestinian state, and my heritage as an Egyptian Arab, I was not surprised to spend 6 or 7 hours of my two-day visit to Israel in security at Ben Gurion Airport. While I’m used to spending time in security, this was the first time I ever spent more than a quarter of a visit in a ‘suspect booth’.

Since my visit to Israel, I’ve had a few disappointed people from around the world reach out to me regarding the visit. People have pointed out that I should’ve taken note of the BDS Movement, an international movement to boycott, divest and sanction Israeli businesses and end international support for Israel’s oppression of Palestinians and to pressure Israel to comply with International Law.

Global politics are inherently intricate and complicated, and while I am against Israel’s economical and frequently violent oppression of the Palestinian people and state, I am not against Israel or the Israelis per se. I am against the politics of Israel, just as I am against many of the global politics of the United States, but also those of many other countries.

So to those questioning my visit to Tel Aviv, I just want to emphasize that in a pursuit to make the world more just and fair, I refuse to dismiss or limit my support to creative individuals with no or little say in these matters. In my visit to Tel Aviv, I found many of the developers to be progressive and open-minded, and frustrated by the political situation.

I was born a third culture kid, too Dutch to be Egyptian, and too Egyptian to be Dutch, and the games industry is the first ‘country’ I’ve felt I belong to. I believe in the power of creativity and games to bring people together, and just like no one can help being born in Palestine, nobody can help being born in Israel.

If anything, I hope to visit Palestine and the independent creators making beautiful games there sometime soon. I hope to continue supporting game development in all forms in the Middle East, and the rest of the Arab world, the Muslim world, and everywhere else. In the meanwhile, I will continue to voice my discontent with the political situation of Israel regarding Palestine, but I will not stop supporting the Israeli individuals and studios dedicating their lives to making beautiful games.