Guest Blog: Can Games Benefit From Blockchain-Based Public Infrastructure?

In recent months I’ve seen a plethora of projects announced which combine blockchains and games. I’ve been talking about the potential for decentralised technology to disrupt the game industry for several years so it’s wonderful to see this becoming reality.

However, blockchains are complicated beasts that confuse and infuriate in equal measure. In this post I want to introduce the notion of sustainable public infrastructure as I believe it’s a key notion in understanding why developers could benefit from the technology. Without this understanding, the oft-asked question is “wouldn’t it be better as a centralised service?”

A little request before going further. New technology sometimes requires an open mind, especially one which is mired in the ​denial and anger​ phases of acceptance. There’s nothing wrong with experienced hands taking a doubtful view but sometimes that same experience can be a blocker to innovation, especially when implementations are highly immature. Learning about blockchains forces you to think about economics, game theory, and the very notion of centralised infrastructure. Whether you want to use it or not, it’s a fascinating and stimulating area to explore.

For the first time ever, blockchains allow self-sustaining public infrastructure for the digital world. Unlike private infrastructure, such as offered by Apple’s App Store, this new form of public infrastructure is paid for, provided and governed by its community without requiring a central authority. It’s able to do this by clever application of cryptography to economic theory for which the original ​Bitcoin whitepaper​ is a suitable primer.

What do I mean by self-sustaining public infrastructure?

Infrastructure - These are the basic structures of an enterprise, providing users with facilities and services. In the centralised world this may be a service such as Gamesparks and much of the same can be done in a decentralised world, although it’s certainly harder.

Public - Currently, most services that developers use are offered by private companies as a commercial proposition. The service is entirely under the control of its owner, with fees, terms and APIs liable to change without warning. The company may disable a service entirely or they could go out of business. A decentralised public service doesn’t have these problems since it’s run for the public good, in this case for the benefit of its community of users, including developers and gamers. API and software changes are handled by the community, perhaps over Github, social media, or governance platforms, ensuring changes are made for the overall benefit of the network participants. As long as there is demand for the service to exist then it will continue.

In addition, both the data and the software are open. In principle, anyone building on the service has access to the same data, the same APIs, and the same core software. This is likely to increase overall network value. Private services still have very significant value to add, especially whilst decentralised technology is immature, however they would be building in a way inherently compatible with everyone else.

Self-sustaining - In the real world we pay taxes to create, maintain and upgrade public infrastructure. In the decentralised world cryptoeconomic incentives are used instead. These can take different forms but the primary ingredient is typically a native cryptocurrency. Blockchain-based infrastructure may require its currency to be used in exchange for services and pre-sold to bootstrap development. More interestingly, the infrastructure can make rewards available for users who are maintaining, upgrading, promoting or providing content to the platform. It also helps solve a tricky on-boarding problem since early adopters are highly incentivised to promote usage in order to create demand for the currency. This doesn’t mean Joe Public has to be exposed to cryptocurrency though, which remains frictional and highly volatile.

In summary, the key benefit is that it’s possible to create services which are run entirely for the benefit of their users. This avoids developers and gamers being subject to the whims of central actors. This isn’t just with regard to terms, fees and APIs, but also to restrictions as evidenced by Sony’s interoperability lock on Fortnite, or encroachment on 3rd party applications as Apple and Facebook have done. A service based on public infrastructure is inherently neutral as it doesn’t compete with its community. As blockchain enthusiasts will also tell you, it’s trustless, although I would argue it’s more about choosing your trust points and distributing trust.

Now that’s disruptive, as Bitcoin has shown.

As interesting as this is, it only matters if game developers are offered services which genuinely benefit them. The feature that interests me most is allowing users to actually own their content by recording ownership on a public blockchain instead of private app stores. In itself this is not really of a benefit, even though it’s a much-used soundbite. However, services can be created based on the principle of true ownership which offer unique opportunities to developers, to gamers, to sellers, to publishers, to brands, to stores, to eSports teams, to artists, and so on. In my view, allowing users to own digital content just as they do physical content could facilitate major changes across digital media and especially games. It simply wasn’t possible until the advent of blockchains.

Some of the ideas being explored here at Fig.co and at other blockchain companies include taking advantage of true digital scarcity through collections, cross-game items, innovative gameplay features, ad networks, early adopter rewards, decentralised publishing, fraud reduction, access to funding, trading markets, digital merchandise, shared content creation, automated royalty payments, and even creation and trading of decentralised land.

Almost all of these are facilitated by public infrastructure supporting ownership data and content management services because anyone is free to use the platform as they wish. It’s the framework from which many different projects can hang, each of them benefiting from others on the same or other open platforms.

In conclusion, no one knows which of the above ideas will successfully bring something new to a mainstream audience but that public infrastructure for games is now possible will allow us to find out. If you’d like to know more about blockchains and their potential uses within the game industry then join me for my talk at Develop or catch up with me during the conference. Alternatively, I’m @alex_amsel on twitter.

Alex Amsel is speaking at Develop:Brighton on Tuesday 10 July with his session entitled Blockchains in Gaming: Today and Tomorrow. Alex is developing a game community blockchain project Shard at Fig.co

Guest Blog: The Unexpected Variability of Physically Based Viewports

In the last few years Physically Based Rendering has taken over most pipelines.

PBR is supposed to produce better results, and save a lot of artist time, and it has so far delivered on those promises. PBR materials look fairly good in many different lighting conditions, cutting down a lot of the fiddling that lighting changes in WIP game scenes used to cause.

To achieve that, PBR goes much more in-depth into the physics of light, than the very approximate models from earlier years. You might remember BlinnPhong, one of the few lighting models which used to be commonly used in games. It didn't include roughness, metallicness and other important characteristics of materials which we now might take for granted. To our current, more discerning, eyes, it tends to make everything look like plastic.

Example of lighting model supporting roughness

BlinnPhong can't adequately simulate all types of materials, but it was never supposed to be possible to have a one-size-fits-all lighting model. In the real world, materials can have wildly different characteristics, and many other lighting models have been devised and published in research papers over the years. Some of them were invented specifically for rendering, and some others for use in optics, manufacturing, and other kinds of applications.

All this various research on lighting models extended our understanding of how light ultimately works. We didn't seem to take advantage of it in games for some time though, mainly due to the limited power of our hardware. The advent of PBR depended on an increase in processing power, which duly happened.

Most 3D programs have introduced support for PBR. You may think that any PBR implementation should be the same, but PBR is a fairly flexible label. It only promises "physically based" rendering, and not "physically correct" rendering, and with good reason. The physics of light can get very complex, and a perfect simulation can't fit within real-time speed constraints, as of yet.

As a consequence of this inherent complexity, PBR systems are built out of a great number of choices between different, often equally valid, tradeoffs, and it's unlikely that all those choices will match perfectly between different teams and different programs. Implementors of PBR systems have to carefully consider many approximations, which will allow them to get to real-time speed, without giving up too much quality.

Subsurface scattering and translucency support

Different teams will have different priorities: a racing game might need better looking metallic materials, and having to fit within budget and time constraints, they may choose to offset that by neglecting the skin material implementation. They can get away with never showing a character up close, but the players are going to look at the cars all the time.

A team who’s developing a game engine for general use will need to produce decent looking materials for any possible object they can think of. The racing game team car material might end up looking better, compared to the general engine one, because it’s the main priority for that team.

This is how PBR implementations end up diverging, as everybody tries to do their best to optimise for their specific objectives. The only way that two different 3D programs, engines, or games, can match their PBR system perfectly is by mutual agreement to do so. Which is what Substance, Unity, and others, attempt to do.

But even if at some point in time two PBR implementations might match perfectly, they may still diverge in the future, as renderers get reimplemented, refined and updated.

As an example of the rapid progress of game renderers: Unity is currently developing two new renderers: the lightweight, and the HD rendering pipelines. Their new rendering system, the Scriptable Rendering Pipeline is scriptable, as it says on the tin. As a consequence, many new different ad-hoc renderers based on that may pop up, as game developers optimise the rendering pipeline for their needs. These new renderers will not be guaranteed to preserve the look of your material as it was in substance, even when they happen to be physically based.

Personally, I welcome our new rendering overlords, as I love writing graphics code, and to make even better PBR systems, we need to be able to go beyond the status quo. But this innovation may come with some breakage, as innovations usually do.

Claudia Doppioslash is a Graphics Programmer, a speaker and an author. She works as a game development consultant. She is the author of the book “Physically Based Shader Development for Unity 2017”, published by Apress, and of the Pluralsight course “Developing Custom Shaders in Unity”. She can be found on Twitter @doppioslash and is speaking at Develop:Brighton on Thursday 12th July 4PM in Room 3.

Guest Blog: Five Top Tips for Planning Your Game Launch

Creating and releasing games has never been so interesting or so scary. It’s well documented now that Steam has around 200 new releases per week. Mobile has been equally busy for some time now and console is also seeing more developers release on Sony, Nintendo, and Microsoft’s platforms. Because of increased competition, planning for the launch of your game is as essential as, well, making the game itself!

We’ve recently announced a new title, Mars Horizon (along with a podcast about it) and we’re moving from that announcement to the more detailed planning for the game’s launch. This links to what I’m going to be talking about at Develop this year - surviving the Steampocalypse!

So I thought this is a good opportunity to share some of the research we’ve been doing around planning our launches and some of what we’ve learned (sometimes the hard way!)

Announce Early (But Plan Ahead) - As an indie you’re always up-against it in terms of resources. You don’t want to announce the game until you are ready, but also you don’t want to launch without any lead-in. My feeling now is that lead-in is key. So having time between the announcement and the launch to gather interest in your title is vital: you can use that time to court influencers, get wishlisted on Steam, and build a fan community. However, if that gap is too long, then you can’t sustain interest in the fallow periods and you then have to put more energy to re-engage people.

An example of ours where we did this was Dark Future: Blood Red States, which we announced - with a release date of 2015! - over three years ago, and it’s still not in the hands of players. It will absolutely be worth the wait, but to avoid making this mistake yourself, make sure you’re rock solid in your release window, and do think about whether you can sustain interest in your title between announcement and release.

Better late than never - it’s Dark Future!

Pick a Good Date - This is an eternal question - when should you launch? Okay, so you’re never going to avoid clashing with multiple games, but to mitigate this to some extent, you can think about the following: avoid clashing with any major events or expos (use this list to check), and note the couple of days either side too. You don’t want to announce a game two days before a big event as all the journos will be busy traveling there and won’t have time to cover your game. Then check announced upcoming releases (try here, here, here and here),checking for any titles in the same genre and platform as your project, and avoid them..

Also avoid any AAA title release dates if you can. That’s not to say you’re necessarily competing with those AAA titles, but they can cast a long shadow and will take up journalist and influencer time and attention.

Get Visual - For the actual release, and in the run up, people want to see visuals of gameplay!

Animated Gifs, short videos, screenshots - that sort of thing. For example I remember this gif from Tabletop Simulator going viral a few years back and these visuals that get across the tone or core ideas of your work really are the things that do best online. If you’re lucky one of them will go viral and then you’re rising to the top of many people’s attention. This is doubly true on social media: Facebook and Twitter data shows time and time again that videos and images work best. So put the time in and make them look great!

Trailer, Trailer, Trailer - I’m far from the first person to point to this. I’ve heard lots of other developers note how key it is.

As well as videos and images, you need - need - to have a strong trailer.

Out of all the marketing assess you create, this is probably the key one. So do plan time and effort into it and if you can’t do it then budget for someone who can. For example look over our videos and you’ll see the dramatic difference in views, from the smaller bits of gameplay or behind-the-scenes videos getting comparatively few views, to the more important trailers which command many more views. Apply the same creativity into planning your trailer as you do your game and test it out with a small audience before you launch it worldwide to make sure it hits all the right notes.

Repeat, Repeat, Repeat - It’s very unlikely that you’ll have that one big announcement and people will bookmark it and come back on launch day and buy your game. One of the things with so many games being launched is that the space is busy and audience mindshare is limited. You’re either going to be able to be loud (if you’ve got enough clout, like a Rockstar announcement of Red Dead Redemption 2, for example) or you’re going to need to repeat your messaging. This means that players need to be reminded of the message of your game and its launch until you are sick of saying it. In that way you keep it in their mind and that will hopefully translate into a paying customer.

Best of luck with your launch (oh and please don't schedule it on any of or launch dates - k?)

Dr. Tomas Rawlings is Design Director at Auroch Digital, so he feels your pain about running your own thing. He is an award-winning games designer who has both created original titles and worked with well-loved IP such as Games Workshop’s Chainsaw Warrior, Star Wars:The Battle for Hoth and the multiple award winning Call of Cthulhu: The Wasted Land. He is a well known speaker on video games and also a consultant who has worked with major organisations. He can be found on Twitter here and is speaking at Develop on Tuesday 10th July 11am in Room 4.

Guest Blog: Why Players Love Stories

For the nearly twenty-five years I’ve been working on videogames, there has been a strange double standard about narrative. On the one hand, game developers often like to dismiss the importance of narrative materials with statements like “it’s the gameplay that matters”, yet on the other hand players have always ‘voted with their money’ and put tremendous stock into good storytelling. Looking at the UK software charts for this week, it’s headed by FIFA 18 – which is clearly rather light on narrative! – but other than Street Fighter: 30^th Anniversary and Sega Mega Drive Classics, the rest of the top ten is packed full of highly narrative experiences like Detroit: Become Human, Far Cry 5, God of War, Dark Souls Remastered, and Fallout 4.

I set up my company, International Hobo Ltd, because back in the nineties it was apparent that developers were having difficulty getting gameplay and stories to work together and it seemed sensible to develop a team that specialised in what we called at the time ‘design-integrated narrative’ or (more succinctly) ‘narrative design’. When Richard Boon came to work for us in 2000, his job title was ‘Narrative Designer and Script Writer’, and the term grew in popularity when Stephen Dinehart IV used ‘Narrative Designer’ as his job description at Relic back in 2006.

What I’ve come to realise over the last fifty videogame projects I’ve worked on, and particularly as a result of my research into how and why humans enjoy games (I’m presenting my latest findings on this at Develop:Brighton next month), is that “it’s the gameplay that matters” misunderstands the relationship between games and stories. It’s a mistake that scholars in game studies repeatedly make as well – they assume that the ‘game’ is the crunchy designed systems, and the ‘story’ is this kind of wrapping paper that you dress up the mechanics in. There might be a recognition of the importance of that ‘wrapper’ in getting players interested in playing the game, but sooner or later, everyone comes down to the importance of those game systems and the lesser role of narrative.

Trouble is, that doesn’t describe how people play games, much less why we enjoy them.

If you want to understand the relationship between games and stories, you have to start by recognising that stories are far more fundamental to the human experience than games. Stories are what we do – your whole sense of yourself as a being is rooted in the story you tell about yourself. We can’t not tell stories, because we’re wired up to think in imaginative ways, and stories are at heart structured imaginings. Other animals play – if you have a dog or a cat, you won’t be in any doubt about this! – and other animals play things we can call games (like ‘fetch’, or ‘chase the laser dot’), but no other creature makes such elaborate games, and again, it’s because games are also at their core structured imaginings. The rules of chess, and the possibility that some state of the game means somebody wins is both the foundation of the game of chess, and the basis for stories about chess.

Games and stories belong together – every game tells stories for the player, either about what the player does (winning, getting a ‘rare item’, levelling up) or about what happens in the fictional world of the game (getting revenge, rescuing a friend, finding a forgotten tomb). It’s inevitable because humans are a story-making species – we experience life as a story, and everything that happens can be understood this way. But there is a truth to the division between ‘game’ and ‘story’ in that sometimes games tack on a story that has nothing to do with the game experience at all… but it is nothing essential, nothing fundamental, that makes this split between games and stories: it’s just bad game design, or rather, bad narrative design.

The best game stories are those that use the systems of the game productively to create narrative experiences that the player feels like they are crafting for themselves. Often, there’s a bit of legerdemain involved… an illusion of greater control than actually exists – but players who are enjoying themselves will always come along for the ride! There are lots of different ways to do this – including at one extreme the Japanese RPG approach of having an animated movie that punctuates playable sections, and at the other extreme games like The Sims that leave it almost entirely up to the player to create their story while still providing a set of carefully crafted props (houses, furniture, ‘dolls’) for the player to use as raw materials. What works is what the players are happy to go along with – which is a surprisingly large set of things!

Good narrative design is about aligning the story and the game so they work together, and this process often begins by examining which stories the game systems naturally produce. Commercial videogames benefit from stories in part because the fictional world of any game is one of the main draws to get players interested in the first place (or to put it another way, whatever we may think about marketing, it does work!). But they also benefit because stories are easier to enjoy than most games, which require you to spend some time getting to grips with them in order to get full value. Of course, plenty of people enjoy stories without games – the movie industry is ticking along quite nicely! – but not so many people enjoy games without stories. Commercially successful games stripped of all their fictional elements are rare, and almost always abstract and fairly simple like Tetris or Super Hexagon. And even these tell stories – “the straight finally came!” is a Tetris classic!

Players have a variety of reasons for playing and enjoying games – International Hobo currently uses a model of ten player motives, which I’m presenting at Develop:Brighton this year for the first time. But the Narrative motive, the desire to engage with a fictional world, and the connected desire to relate to characters in a story that builds to a climax, is particularly powerful because it works for just about everyone, which the Victory, Problem-solving, and Acquisition motives don’t – despite their incredible power over players for whom these experiences are key to their enjoyment of games. Players love stories because stories are what humans do… and games are perhaps the most amazing, surprising, and unexpectedly rewarding narrative medium we have yet discovered.

Chris Bateman is founder of International Hobo and will be speaking at Develop:Brighton on Tuesday 10 July. Find out more about Chris and his session here. 

Guest Blog: The Art of the Small

When opportunities arise, it is important that we make the most of them. In this article I want to look at the small opportunities; the events and funding pots that give studios a bit of breathing room to try something new. It is all too easy to think of these chances as the right moment to execute a master-plan; to start working on the passion project that will make you into a superstar. While I'd never say to anyone it’s not worth working on that dream game, it would be wrong to not pass on the advice I've gained from where I have gone for the passion project, as well as from the times I haven't.

Before I get into the how of the small, I want to talk about the why of the small. I'm going to talk about two examples where I think this ideology applies, the small grants (<£5k) and game jams. Both opportunities give you a chance to create something new; to take a step back from ongoing projects to realise an idea that’s been at the back of your mind. It is surprisingly easy take that opportunity for granted and try to fill it with the first thing that comes to mind. An example of this would be using a small grant to make the proof of concept for a huge RPG from scratch; with crafting, vehicles, an engaging story, and dynamic characters who develop over time, when you suddenly find two months in that all the money has been spent.

One of the universal truths of games development is nothing is as small as you think it is. If you take a small aspect of a bigger project, estimate how long you think it will take, and added some padding time for unexpected issues, if you doubled the time in your head you might then be close to how long it will take. In contrast, these opportunities give you a fantastic space within which to create something focused. Imagine having a new empty room suddenly appear in your house. A lot of people dream of implementing a minimalist style within their home, but their rooms are already full of belongings and furniture. You could fill the new room with the unsorted belongings from the rest of the house, or you could take advantage of the space to implement your minimalist dream. This is the idea behind the art of the small; to make the best use of the time afforded to you by a small opportunity by creating something focused and polished that showcases your ability to create a complete entity as opposed to your ability to build something wide instead of deep. 

Looking at an event like Develop Game Jam (which you can sign up for this year here: https://www.eventbrite.co.uk/e/develop-game-jam-2018-tickets-46545765638), you can see it as just an opportunity to make something new, but I think that undermines a very key aspect of the jam, the competition itself. Game jams present a very compact form of the project bidding process. From a given brief (the theme), groups build a game (the prototype/pitch/spec) which they then take to the judges (the client/brief setter) to have their game judged. At the end one team walks away with the prize (the project/funding). If you responded to a brief with a large amount of documentation without a lot of substance, you'd be unlikely to win. However, if you were to respond with something targeted at answering the questions of the brief in a concise manner, you'd have a much better chance of securing the bid.

It is time to look at ways of implement the small in a project. Every idea can be reduced to modules and components, the parts which make up the whole. Even passion projects are equal to the sum of their parts. For me, the art of the small is about focusing on developing one part (module/element/mechanic) to a high level of detail/completion, and then building the rest of the game around it, only implementing subsequent components based on necessity and how easy it is to then polish the game.

The first game we made with a grant was a huge pirate RPG. At the time, we thought we were building something small; a proof of concept containing a basic version of each mechanic in our game. Ultimately, while what we were was technically impressive, it was always doomed to clunking mess. The reason it was doomed is, although we were implementing only the initial forms of the features, we unable to leave enough time to make sure that those features worked well with each other, or to remove the bugs in the rest of the game. The result was that some people who played our game were put off when the camera froze, or the menu broke, or when the game crashed. Looking back, if we'd taken just one feature (the sailing, the crafting, the boss fights) and spent all our time making that aspect as polished and bug-free as possible, we would've made a much better and more accessible game that would have been more universally enjoyed.

For me, executing a small project comes down to three key elements: the brief, the mechanic, and the polish. In the next three sections I’ll examine each in turn and breakdown how they can be implemented in the game.

It is vital that the brief is adhered to. There's no point making something great if it's not what the judges/funders want. Note I said what they want, not what they say they want. This is all about research and planning. What are the actual judging criteria? What are the judges personally interested in? What's the context of the project? For example, if it's a game jam then fun is probably key, whereas for a prototyping fund the vision and a solid base game matters more.

After coming up with an idea that fits the brief, I usually focus on a singular core mechanic that realises my idea in a simple, clear-cut way. For example, if I concluded the judges wanted something fast paced, but almost finished, and my idea was to create a kind of free running game across a city to get home from work before dark, one of the simplest, clear-cut ways I could do this is to make a 2D grappling game where the player swings across cranes or high buildings to get across the map. In this instance, if I'd gone for 3D I'd enter issues of generating the city/buildings, creating the 3D obstacles, animating a 3D character etc, but this way I get my idea across while minimising the impact on the scope of the project.

Finally, but probably most importantly, the polish is key. A small, broken mess is still a broken mess, but with less features. Polish in this context loosely translates as the removal of edges. By an edge, I mean something sharp and pointy that would stick in a player and diminish their experience. If you're making something small, it's surprisingly straightforward to achieve a high level of polish without a tremendous amount of effort. I see polish as being the sum of three elements: limiting scope, thorough debugging and adding juice.

I've already talked about scope; keeping your game to essentials only. Feature creep and working out-of-scope are killers when it comes to polish. You can address the issue of scope from the outset by only adding features to your game that actually matter to the brief. Do you need a menu? Does that AI need to react dynamically? Do you need a save game system? If you don't, don't include it. It adds more opportunities for the game to break down and more components that you need to debug and juice later.

With regards to debugging, in this instance we're talking about the removal of as many bugs that effect moment-to-moment game-play as possible. You want a player to be totally engrossed in your game. Nothing is worse for a player than feeling at one with a game to get stuck in a wall, or be instantly killed by a random object, or for the whole game to chug and break down. By removing bugs, you give the player the best opportunity to stay totally immersed within your game space, which means when they finish they will want more (assuming you've made something engaging!)

Finally, the juice of your game is the small decorative and aesthetic elements that bring the still aspects to life. There are a lot of great videos about how to juice your game (see above), but the easiest way to think about it is to imagine the most engrossing game you can and imagine what would happen if you stopped still on a single screen. Would you be viewing a static image, or would things be happening? Is the text still, or is animated? What’s happening in the background? How is sound and light used to impose a mood? Very few games have nothing happening at any moment, and those that do use it as a contrast to moments where things are happening. Aspects such a colours, sounds, animations, and moving objects all add to the juice of a game. These are the elements which bring the otherwise static world of your game to life and drawer the player in. 

Just like the art of minimalism, the art of the small requires dedication to implement. I've highlighted every aspect that I've learnt and practiced over many game jams, funding opportunities, and personal prototyping, but it's still very easy for me to fall off the tightrope and build something wide instead of deep. Ultimately, this advice should help you keep your development in check if you're trying to build something small. Every time you want to build a new feature, think about whether you need it? If so, how do you keep it from breaking what you've already implemented? Finally, how do you make it worthy of your game i.e. how do you add the juice? Using these questions as guides, you'll be well on your way to implementing the art of the small in your next project.

Adam Boyne is co-founder at BetaJester and will be speaking at Develop:Brighton on Thursday 12 July. Find out more about his session here.

Guest Blog: The Art of Storytelling

Games are one of the most interactive and immersive mediums available to us as storytellers. They provide the opportunity for players to actively affect the outcome of a scenario in a visceral way which has allowed us, as developers, to explore facets of the human experience in ways film, literature and television cannot.

Games in recent years have pushed the envelope on immersion and found ways to weaponise our interactions with a game, resulting in responses unique to the medium. When we hunt the beast and strip it for parts we feel pride from the kill, but guilt at taking a life. When we are forced to choose between saving one individual over another we feel remorse, but a satisfaction that comes when that decision pays off further down the line.

When I founded my company, I set out to make the games I felt were missing from my Library. I wanted to assemble a team to make something that told human stories from human perspectives, tapping into a wealth of collective experiences to really give the player moments they could relate to – and especially moments they can’t.

In Du Lac & Fey: Dance of Death we never wanted to shy away from important social issues such as abortion, sex, love and race. All of these are framed through the lens of women, as two of the three protagonists in our game are female with very different world views and upbringings. Our third, Sir Lancelot, must grapple with his own demons – monsters that sit outside of the usual male-lead revenge fantasy.

The Victorian era was rife with social upheaval, clashing cultures and contrasting values, and we are proud of the fact that we’ve managed to tell as many of these forgotten stories as possible within the walls of our game. It’s actually extraordinary how many parallels we can draw between us as people, despite there being over one hundred years between us. We have the tabloids and papers on our newsstands now, but this period gave birth to modern day journalism. Stories were fabricated without basis, gossip invented to sell papers, and facts overblown to keep people turning the page.

It is said that history is written by the victors, but, more simply put, it is written by those able to write. There are thousands of stories, both then and now, that’ll be lost to time due to one person monopolising the pen. We attempted to make amends with Du Lac & Fey, offering players a London they will have never seen before. London then is as London is now, a multi-cultural melting pot of ideas, lives and languages that birthed a new era of technology, art and belief. Who better to explore this new world than Arthurian immortals who, after all these years, can look upon this strange, exciting city with fresh eyes?

We are moving into a new era of game storytelling, exploring the way we handle and interact with topics such as mental illness, grief, and different sorts of love. Moreover, the demographic of gamers is shifting, and game developers seem to be accommodating that, or it could well be the other way around? It’s a fascinating time to be working in the games industry, especially when narrative-driven games seem to be at the forefront of our march forward. Above all else, I look forward to an increasing level of diversity in our developers, opening doors to new voices and the new stories those voices can tell.

Jessica Saunders is an Indie developer and and owner of Salix Games

Guest Blog: What To Do When The One Big Deal, Doesn't Turn Into The Next Big Deal

It probably seems a bit strange me writing a blog like this in May; titled nearly identically to the talk that I’m doing in July at the wonderful Develop Conference… The reality is that not even a 3 hour time slot would enable me to convey all of my thoughts and feelings on this subject – which can be seen in the recent interview that I gave with our Operations Director, Gemma, for GamesIndustry.biz. 

In the article on GI.biz we talk a lot about what happened before, during and just after the cancellation. In the talk in July I’m going to talk in more detail about what we did to survive, the trials and tribulations of numerous unsuccessful pitches and the removal of the rose-tinted glasses and ego consequent of having a big deal.

“So, what’s the point of this blog?” I hear all one of you asking (thanks for reading Ma). In this blog I wanted to talk briefly about the emotional and mental impact the situation had on me personally. I have never been shy about being brash, outspoken and, at times, inappropriately open about my feelings on pretty much everything. But, over the last couple of years it seems the industry has become more open in general about mental impact.

Firstly, I want to say that I am in an incredibly privileged position and that I am fully aware of this. I was able to start a studio due to the support of my family and loved ones, and we’ve had a truly incredible journey. Hitting 6 years in June is an amazing feeling and I know how lucky we have been in an industry that has seen wide-spread layoffs and studio closures in the half a decade we’ve been going. I’m also very aware that I am the most cliché typical game developer in the world - I have not had to deal with any real discrimination. In fact, the only discrimination I have ever had to deal with comes about when I occasionally decide to treat myself to a first-class train ticket; apparently sweatpants, trainers, long hair and a beard aren’t the appropriate attire according to the fine ladies and gentlemen in first class, who like to call upon the ticket inspector to check that I’m not bunking the fair…

However, for all my bravado and the joy this company has brought me over the past (nearly) 6 years, and without a single day’s regret, it is fair to say that it has definitely taken its toll on me… At the ripe old age of 33, I’m nearly completely grey. Which is quite depressing when I compare that to pictures of me when I started the company in 2012, without a single grey hair in sight.

My sleep patterns are broken and erratic at best and, unsurprisingly, this is worst around important deadlines. I’ll often very suddenly become completely wide-awake in the middle of night, spend a couple of hours checking/answering e-mails and messaging our US-based partners/staff/publishers/clients.

On the topic of sleep, I’m tired a lot, on average at the moment I’m usually actually in bed by 9pm because I feel completely shattered, which doesn’t help the broken/erratic sleep pattern.

For the better part of the last 18 months all I have been able to think about is when the money is going to run out. When the Disney deal finished, we had a great amount of money to keep us going and, whilst we’ve done some amazing work for hire projects and been smart with some operational cuts, it turns out studios burn money, and it can burn quickly! We’re not 5 guys in a garage on minimum wage anymore; we are 10 people, with two office buildings and a yearly running cost well into the mid-hundreds of thousands.

Whilst I’ve been lucky that I’ve never really felt like I’ve had “imposter syndrome”, I am anxious all the time. This also led me to realise something a while back - I never really “celebrate” the highs and achievements; I am always looking behind them for the next low that could occur. Luckily this isn’t something that has rubbed off on any of my awesome team members or my loved ones who are all an awesome positive presence in my life. However, I do feel at times I’m missing out on being able to feel really happy about the big work milestones, like signing deals and big development milestones.

To be clear, I don’t want this to sound like I don’t enjoy my work-life - I absolutely love what I do and genuinely feel I have the best job in the world. In fact, I’ve had some arguments with one of my best friends in games over which one of us has the best job, and that is an awesome way to feel. My school friends all hate me because when they hit Sunday are dreading already dreading what’s to come on Monday, I can’t wait to get back to the office. But the industry has still broken me down over the years. I’m definitely programmed now to always prepare for everything to go wrong. Although, this does have its advantages; it makes me more cautious about everything and I never trust a deal is done - not until the first payment is cleared – and even then, I am far more aware of potential risks that still may follow.

I say this A LOT, so much so that anyone that has seen me talk or read anything I’ve written is sick of me saying it but: I was a programmer who wanted to be a designer who became a company director. I never had any intention of starting my own company. It just wasn’t something that even registered as an option. Whilst I don’t regret it at all, I was never really prepared for what it meant to be where the buck stops. To be the one with the responsibility of people’s mortgages and kids on your shoulders. Does it feel like it’s a massive burden to bear on a daily basis? 100%. And do I feel like I can’t handle it? Very often. BUT that feeling passes quickly. I know I can do this because I need to do this for my team and for myself.

Every time I’m the last one in the office, I look around and I realise that we built this (not the building literally, however we did paint building 1). That we were just a few guys, with no real plan, who wanted to make games together, and now we’re 10 awesome people (soon to be growing). In these moments of reflection, I suddenly feel completely overwhelmed and lost for breath and then I do something that I don’t necessarily do that often. I smile.

As with everything I do, there wasn’t much of a point to this – it was really just stream of consciousness typing. But, if I had to drill it down to a point and some sort of “Jerry’s Final Thought”, that point would be that it is ok to feel overwhelmed; it’s ok to question yourself, it’s ok to feel anxious and it’s 100% ok to feel however the damn-well you feel. Just make sure that at the end of the day the thing triggering all these feelings is worth it.

Aj Grand-Scrutton is Chief Executive Office at Dlala Studios and will be speaking at Develop:Brighton. Find out more about his session here and to see more talks featured on the Indie track, click here.