How Can You Get The Most Out Of a Games Expo As An Aspiring Indie Studio

We’re approaching a year into the development of Carried Away. It felt like a good time to attend a games event and take some lessons from experienced developers. We attended EGX Rezzed in London last weekend. We attended talks, visited booths and bombarded members of the public with our unpolished pitch. Some of the above have been really insightful, while other parts we’re probably more fun than useful.

Bombarding the public

We thought it’d be great to ask some of the 10,000 people that were at Rezzed for their opinions on our game. We were able to show people videos and gifs that we’re not quite ready to show on the internet. It was great to hear people speak positively about something that we’ve created, in fact nobody had anything bad to say! ….this started to make us wonder.

The vast majority of the friendly gamer community are going to be enthusiastic and positive, but most likely kind and reserved when face-to-face with some nervous game developer. We we’re looking for critique or suggestions, but mostly got observations and some friendly chats. We did get a couple of people interested in doing some pre-alpha testing along the way which was useful.

More useful - we lucked out half way through the event when we unknowingly bombarded a member of the press which he indicated to us by his black wristband. He was interested to know more and we exchanged business cards. Score! Pro tip: keep a keen eye out for people with black/press wristbands.

Checking in at booths and sucking up to fellow devs

Finally, the last piece of the jigsaw was to speak directly to other people that had been there and done that before. We grew our network way beyond what it was over the space of those 3 short days. While the advantages of this may not be immediate, who knows when we could reap the rewards of knowing the right people in the right places.

We researched as many of the showcased games as possible beforehand to understand which games are most similar to ours, both in terms of what we want to achieve in sales, and similarity to our game in scope and genre. We also checked out games which we knew to be struggling to see if we could learn anything that would help us avoid a similar fate.

A cool VR game we tested at Rezzed "Giant Cop" and some minatures

A cool VR game we tested at Rezzed "Giant Cop" and some minatures

We showed genuine enthusiasm for the games that were on show, we wanted to learn as much as we could about them and their teams and the development process. When it was appropriate we struck up technical conversation. This indicated that we too are developers, and often led to a brief conversation about our game.

By spending longer at the booths with the most similarities to our game, we hope that it has put us in a good position to contact these developers in future. Hopefully to exchange favours, contacts and knowledge.

Attending developer talks and Rezzed sessions

The talks we attended were ones that we thought would be most applicable to our situation which is building up to greenlight, alpha and early access/launch.

DISCLAIMER - no notes were taken at these presentations. My memory isn’t always 100% true to me. Pro tip #2: take a note pad.

Talk #1 - When to show and who to tell

This was a star studded talk which was hosted by Independent By Design. It included Dean Hall, creator of DayZ, Paul Kilduff-Taylor co-founder of Mode7Games and Lorenzo Conticelli lead artist on Town of Light. They all work in game design, but it was immediately clear that the genres in which they operate have shaped their thinking. Dean has primarily worked on first person, persistent survival games, Paul on simultaneous strategy games and Lorenzo on narrative driven psychological thriller - all vastly different. I think this is important to keep in mind when taking advice from anyone. There isn’t a one rule fits all approach for anything in game design, and most things should be taken with a good pinch of salt.

There was a couple of points that the whole panel agreed upon. This was that they would focus their communications efforts according to the stage of development they are at. For pre-alpha it is important to engage the core community of testers that are able to help shape the future of the game.

Another agreeable point was that it is important that you have worked out your angle to show your game when you decide to start showing people content. It can be easy for people to look at your game and say ‘it looks like minecraft/ NFL/a horror game’ when in reality you may be creating something entirely different. First impressions matter so make sure you focus on what you are to avoid people second guessing what your game’s about.

Here are the key, most memorable points that each developers were made during the talk:

RocketWerkz newly announced game - Stationeers. A persistant space station survival game

RocketWerkz newly announced game - Stationeers. A persistant space station survival game

Dean Hall
Hot tap, cold tap analogy. Initial conversations should be around generating excitement and positivity. Hot tap. When things get too hot, turn on the cold tap of realism and critique in order to manage both excitement and expectations. There was a lot of joking and irony in what Dean said - in his own word, DayZ is the Nickelback of gaming. Most people think there was way too much hot tap.


Simultaneos turn based strategy

Simultaneos turn based strategy

Paul Kilduff-Taylor
Start telling the people you trust as soon as you can, but only when you are happy with the concept in your head. Talking about it will help you see if the concept really is a good idea.

A Psychological thriller

A Psychological thriller

Lorenzo Conticelli
If the game is narrative driven, it is best not to give away too much about the plot. It is better to use artwork to communicate your game. But be careful not to confuse the audience of what the game is.


Talk #2 - How good comms can save a bad launch

Josh Bishop from Bright Rock Games, developers of War For The Overworld talked about their rocky launch and the uphill battle since. We didn’t think that talk was entirely applicable to us, but thought it was a good idea to be well prepared if the worst happened around release. For those of you that do not know, War For The Overworld was very successful on Kickstarter.

Like a lot of campaigns, it was built around promises which inevitably leads to certain expectations from a heavily invested community. It is natural to be optimistic around the birth of a new project (see Dean Hall’s hot tap analogy above), but when dates are missed, features dropped and bugs present on release there will always be backlash which are reflected in the reviews. The advice on how to recover from this was simple, but should also just be viewed as general good practice for building a community;

  • Be nice. Resist responding to trolls

  • Be authentic and honest. Be open and share what you know. Be realistic about your promises.

  • Encourage a ‘super community’ that will help respond to queries. Give these people additional access to content before its release and

  • Admit mistakes early, and communicate what you have learned and how you will avoid similar errors in future.

Doing the above has allowed Bright Rock Games to eventually reinstate trust with their customers. It has lead to lots of positive comments around how they are not ‘a standard money grabbing studio’.

Talk #3 - Games industry PR

We have been contemplating using a PR firm around the early access release, but the first piece of advice is even more relevant if you want to go it alone. We attend a talk from award winning Stefano Petrullo, founder of Renaissance PR. PR is the process around getting your message to the media, so that they can write the stories about your game.

The first piece of advice he gave was to focus your PR efforts (whether you use a 3rd party or do it in house) around what makes you interesting and different. That could be that you’re making a chair lift & gondola construction game (cough cough) or a game that explores the issues surrounding mental health. Whatever it is, this is the angle that you should take. This is what will make interesting reading which is what media are aiming for. The fact that you are entering Early Access, or that you’re indie developers, or that you are based in a fancy location or that you’re on sale for the first month isn’t attention grabbing. It could apply to anyone.

For those that do choose to use a PR firm. First of all, consult at least 3 PR firms, each may have contacts that are more applicable to your title. Agree measurable targets with the firms to gauge success and whether the PR firm has fulfilled their contract (e.g 3 top tier news publications, 5 interviews with the media, etc.). Lastly, understand how those targets are going to be reached. What is the pipeline or process for achieving these targets. (an event? Mailing list? Megaphone in Piccadilly circus?)

While PR may seem like an unnecessary expense to small indies, the expertise of knowing and understanding the audiences of different publications may be the difference between snowballing success, and struggling to get in front of your target audience.

Talk #4 - Surviving early access

I’ll keep this one short and to the point. Thanks to  Andrew Spearin from New World Interactive for the presentation. Early access isn’t dead. Just make sure you treat it like Early Access. Be engaging. Be honest about expectations and don’t over promise. Update frequently, even if it is just small. Listen to the community and show them that their suggestions are being implemented, but importantly, don’t let them dictate the design. Reward early adopters. Treat it like a real release, after all, if you’re asking for money, your customers are going to expect a certain amount of value from the  game.

If you ignore these, you’ll end up feeling like early access is as broken as Walter’s moral compass. People will not want to engage, but most of all, you could damage your final release with bad reviews, reputation and broken trust.


Well done if you made it this far and thanks for reading our tips on how to get the most out of an expo. Our key takeaways were the contacts we made and the realisation that only certain advice is relevant to your game. Lastly, if you’re attending any expos, stay positive, brave and enthusiastic, check out lots of games for inspiration, and most of all, have fun! Speak to everyone you can (without being weird) because who know what they might reveal!

How have you benefited from expos in the past? Is our next logical step to take our current game to one? Am I talking a load of gibberish. Talk to me fellow devs :)



Entry #312 F*** collab

[Edit] Work around found

Thanks Sean Kumar for pointing this one out!

If you encounter the Spinny wheel of death, simply right-click on any script and choose reimport. This will force Unity to recompile the script, breaking it out of the infinite spin, and you have escaped the grip of that damned wheel.


This blog is a guest entry from Andy. I’m the lead programmer on our project Carried Away, but I have also been referred to as the lead protagonist in the battle to fix Collab.

Against the grain of things, I’m not here to talk about all the stuff we have been working on this week, but instead, to use this as a platform to have a good old-fashioned British moan about the state of Unity’s Collab feature.

I’ll share the 2 most common issues that we constantly encounter when using Unity’s collab tool; as well as our solutions that we use to overcome them. Now, don’t get us wrong, collab is a great tool that enables us to work remotely in the same project without too many issues. It really is great for those of us too scared to venture into the land of Git/Svn, but there’s no real value in us talking about that. I’m going to focus on the feedback that we have shared with Unity in the hope that it will help other developers who are encountering the same problems.

F*** collab issue #1: Renaming files

TLDR; Don’t rename files

When we rename a file as part of a push, we normally encounter problems when this update is later pulled by the team. The renamed file gets correctly updated with its new name, but it does not get the new contents.

The most common occurrence of this problem is when we are renaming some of the poorly named classes in our project. In particular, we had a moment where scripts stopped being named XXController, and started being named XXManager. Renaming all the old scripts to match the new naming system I would go into the script and, using Visual Studio’s global renaming tool, rename the class and all references to it. I would then rename the file in the Unity’s Project view.

Signing off at the end of the day with a message of “Peace out guys, I’ve made that sexy as hell push we’ve been talking about all day, I’m outta here!”, usually starts a torrent of messages consisting of ‘don’t leave!’, and reports of a bad push containing the error “The type or namespace name ‘blah’ could not be found...”.

Investigating further quickly reveals that while the file has the correct new file name, and all references to the class inside the file are correct, the class in the file has the old name! And this means that any other changes made in that file haven’t been pushed either.

There’s a super easy fix to get around this if you are encountering the same problem:

The original pusher makes a small, insignificant change to the affected file(s) (like adding/removing whitespace) and then do another push. This forces collab to see the change and then everyone is happy again.


“Stop renaming files!” - Will, every time I rename a file

F*** collab issue #2: Spinny wheel of death

This one really grinds my gears. Our small studio has opted for 2 unity pro licenses for the people that will really use Unity a lot. However, it is exactly these same people (the two computers with plus licenses - me and Will) that encounter this problem.

Any interaction with the collab system - pushing, pulling, even just clicking on the drop down collab menu - will intermittently cause the project not to enter play mode, and to be stuck in script recompiling mode indefinitely until we restart Unity. Very annoying, especially when experienced in combination with the renaming file bug.

No fix for this one as of yet. So there it is rant over. But one more time because it feels good;



Anyone else having these issues or know how to avoid spinny wheel of death when so much as glancing at the collab button?

(ノ´・ω・)ノ ミ ┸━┸




Dev blog #3 - The Piste Map

Welcome back to the third installation of our development diary and thank you to the 150 people who participated in our naming poll! After much deliberation, disagreement and head scratching we have named our first child Carried Away.

Carried Away is a physics based puzzle and construction game where the player builds chairlifts, gondolas and jumps.

Poll results - thanks for the ‘U guys suk’ name suggestion, it was a good one :)

This week we will share with you what is on the horizon for us and you in terms of game features and how that has formed our piste (road) map.

In an oddly fortunate way, the not so straight forward journey that got us to where we are today gave us some valuable development experience. With that in mind, we thought it wise to try our hand at planning. A new and strange concept to us. There was even a point in time where we tried to use this in conjunction with agile working methods but this was a step too far.

Feature planning

I wouldn’t claim that we use particular advanced techniques to manage our work, but so far they have been effective, and dare I say, on track. Back in January we created a non-exhaustive mind map with all the juicy bits that we wanted to squeeze into the game.

Feature map on my animal office wallpaper - can you guess the animal?

The Piste Map

From this we created a milestone path which outlines when we will be tackling each of these features. This allows us to focus on the most value adding bits first. All going to plan we will aim to build an alpha version of the game next month.

Our development piste map is a summary of our milestones, I am in the process of creating a development notes page where you can track our overall progress and find this updated map in future.

Key: Green - complete. Purple - In progress. Red - upcoming development

Subscribe to hear more about how our studio is progressing, and what we are learning over the coming weeks and months!



Dev Blog #2 - Call that a sandbox?!

Last week I shared an overview of our story so far. Summer projects, quitting jobs, re-scoping, re-planning and a change of platform. This week I'll share more recent developments with you.

A month later than planned, we recently finished what I called the ‘sandbox milestone’. This sandbox milestone was to create all the fundamental building blocks for our physics puzzle and construction game, in essence, a prototype v2.0. A build that allows us to freely create within the defined rules and boundaries of our universe. A developers sandbox.

It is the foundations on which we can iterate and develop the rest of the features and game play elements that we have dreamed up. I'll speak more about those next week. 

Whether it is actually a sandbox by definition is an ongoing debate between us. For me, it seems to fit, but Andy disagrees. This is an overview of the broad areas that we have been working on.

Test run for jimmy the skier.

Ski Lift Mechanics

On the surface, we needed to create a believable ski lift system that would behave in a predictable way. But in reality, we wanted to go way beyond that.

We wanted to create a game that would test a player's logic and push them to embrace their inner-engineer. A game that would require the player to conquer the challenges of mass, tension & compression, as well as assess geometry and budget. We wanted to provide depth to the experience and a platform where the player can get better at the game, improve their scores and beat their friend's.

Ultimately, we set out to create a game that would make the player feel rewarded for their success. But success and reward isn't for everyone, so don't let that put you off. Equally important to us, is that when it all comes crashing down, it provides entertaining, unrepeatable outcomes, that make the player want to try again. Cos win or lose it should be fun.

A failed lift tower in post milestone 1 build

We asked a lot of our selves. But lets be honest, all of the above is intentionally vague ;)

Construction mode

We set out with the goal of making the most user friendly construction tool for 2D truss-like structures, or bridge building games. We wanted a building tool that would let you engineer what you wanted as quickly, accurately and frustration-free as possible. We felt that other tools out there could be improved. We took what works from others, and used that as our starting point but have since improved on it by adding multi build for building twice as fast. We also included a way to move (or adjust) multiple points at once, as well as connect them to an existing point. 

Whats the best building tool that you know of? What would you like to see in ours?

Example of multi build

So that's the whistle stop tour. If you want more information on what on earth we're doing, subscribe to receive these updates via email. Leave a comment, get in touch, tell us what you think.

But most importantly, if you think I've abused the term 'sandbox,' stoke the fire of Huge Calf disagreement in the comments below.  





Dev Blog #1 - You can't push a rope

Yet to be named ski lift construction game is Huge Calf Studios’ maiden voyage into indie game development. This first announcement provides an initial glimpse into an original concept. A concept which we think will turn the bridge building genre inside out!

Pre-alpha game play

Pre-alpha game play

It started in May ‘16. Like many, I was dreaming of leaving the day job. My younger brother (Will) and his friend (Andy) were about to graduate and look for jobs. A passing comment about teaming up to make 'that ski lift game' that I had thought up a few years before, quickly turned in to a summer project. Now, approaching a year later, I will attempt to share the journey so far. 

It’s been a steep learning curve and we are all getting a lot out of the process. Every day has brought a new lesson. This is the most obvious and persistent one that I'd like to share with you. Design, art and coding have all followed Hofstadter's Law - It always takes longer than you expect, even when you take into account Hofstadter's Law.


The humble beginnings: May - June '16

Initial prototype built in a long weekend or 2

Initial prototype built in a long weekend or 2

We created a prototype of the game over the course of 2 long weekends. Andy put revision for his finals on hold and we created something which resembled a ski lift. Nothing really worked, but the ball was rolling. Originally, we planned for this to be a mobile game. 

We worked hard on creating a rope that would perform how we expected it to. This is the feature that really sets us apart from other bridge building games. It needed to be flexible, light, strong, be able to hold tension, and most of all, move. We experimented with lots of different methods. Closed circuits, static rope with moving chairs, invisible pulleys. We got there eventually, but it did feel like we were pushing rope sometimes.

Moving rope prototype. (Sorry about image quality - it's all I've got!)

Moving rope prototype. (Sorry about image quality - it's all I've got!)


Goblin Engineering: july - october '16

Not long after we started making this game (but way after we thought we would have finished it), we decided that it would be great if we could make this game accessible to everyone, regardless if they liked skiing or not. We decided to make it a Goblin Engineering game, with the same concept of getting something from one side to the other. Down the rabbit hole we went.

The goblin days and transporting gold. (The rope is missing, which is probably why I took the screen shot, bugs are running theme in my archive)

The goblin days and transporting gold. (The rope is missing, which is probably why I took the screen shot, bugs are running theme in my archive)

We put a lot of effort in to the story behind why these goblins existed and what they were transporting. But ultimately couldn't convince our selves that this was a concept that people would buy in to. So we stopped focusing on our imaginary customers and reverted to making a game that we want to play. So we went back to the original concept of ski lifts. It took us until October to make this decision. 

Not all was lost, a lot of time was spent making the physics realistic, and the input reliable and easy to use on a touch screen device. We were pretty happy with the results and would even go as far as saying they were better than any other mobile bridge building game. 


Immobile: November - December '16

This was an exciting time for me in particular. I had worked out that I could leave my job and survive for long enough until we got this game out. Its an all or nothing approach which may prove to be a terrible decision.

We had an alpha version of the mobile game out. It was being tested by friends, family and the odd stranger. The feedback helped us improve the game dramatically at this stage. We even had a release date.

But then after reading numerous postmortems and deliberating (and arguing) for over a week, we made the decision to make a fully featured PC game. The summer project that we started 7 months earlier had evolved.


Yet to be named ski lift construction game: January - February '17

The decision to move this to PC is what we feel to be our best decision yet. The limitations that mobile imposed were no longer there. Now we really could make the game that we wanted to.

A complete redesign was thrashed out in the first week of January, this included new features such as a level builder, a move from 2D illustration to 3D low poly models, and a redesigned construction tool (again we think this is as good as any other PC based bridge building game construction tool that currently exists.) At this stage, none of us had any 3D modelling experience, I took on the challenge in order to make some place holder assets, with the aim of getting someone experienced involved when we knew what we needed.

Progress after 1 week of teaching my self blender.

Progress after 1 week of teaching my self blender.

We created a level builder that was developed for our own use, but we think it is a pretty powerful tool for whipping up new levels in a jiffy. It has now become a fully fledged feature of the game. It provides the user the opportunity to create (and someday share) their own challenges. We have a good physics simulator and a tool that can be used to easily create ski lifts.

8 months after starting and were now happy that we have essentially created the foundation blocks for our game. We're excited to start implementing and working on the following:

  • Aesthetics

  • More lift types

  • More characters

  • Skiers, bridges and jumps

  • Win criteria and scoring system

  • UI overhaul

  • Sharing features

  • Campaign

  • Tutorial

  • Open Beta

  • …. Skiing cows

  • Music

We are running a poll on what we should call our game. We would love it if you could take 30 seconds to cast your vote!