Localization for Indie Game Developers

Note : Hey everyone, as most of you know might know from my most recent post, Squeaky Wheel has disbanded and gone on our separate ways. I am now living in Stockholm and working at Paradox Interactive. However, before leaving one of the last things I did with Academia was to add more localization to the game post launch. I finally have some data I can share with you about the results of that.

This article talks about options for localization and what Squeaky Wheel did for Academia : School Simulator. We share real data from our game to help inform your own decisions.

Why Localization?

The US, EU, and UK are traditionally known as the largest market for Steam players. However, Steam is expanding its reach around the globe and more and more players from different countries expect their games to be localized. Steam’s access to a global market is one of the best advantages it has to offer to the indie developer, and you should take full advantage of it.

How to Choose Languages to Localize

Localization is not free, so how do you decide which languages offer you the best value for money?

Gut Feel and Common Knowledge

First is gut feel and common knowledge. For example, it is fairly common knowledge that China and Russia are large, untapped markets for PC gaming, so it makes sense to localize for them. Germany is well known for liking simulation games. France and Italy are relatively large populations, wealthy countries which may have lots of gamers. Japan is not well known as a PC market, but its population does not speak a lot of English, so it’s required to localize before you can make money there (same for Korea, Turkey, Thailand). Some are risky bets like Thailand or Vietnam where they don’t speak English (which is good) but you don’t know what the PC market there is like or if there is demand for PC games (which is bad).

Analyzing Wishlist Data

In Steam’s backend, you can check the regional sales data and by clicking on the plus sign next to a country you can see the wishlist data. Although it’s not 100% sure, we assume that someone from that country who has wishlisted the game will be more inclined to buy the game if it is localized.

You then list down the number of wishlists per country, and using gut feel and common knowledge as a lens to analyze the data, choose which languages are most likely to be good value for money (more wishlists means more chances people in that country want to buy your game). Lastly, you can also make the decision depending on the cost of localization. Obviously the lower the cost, the better the value for money.

I’ll walk you through my thought process on some of the countries so you get an idea of what I was thinking, but please take note you will have to do this yourself if and when you decide to do localization. There’s strong demand from the Netherlands, but its common knowledge that most folks there speak good English, so a localization may not be absolutely necessary. Italy is traditionally a “must translate” but the demand seemed weak so unless I could get a reasonable deal for localization we might not do it. Thailand is a very interesting choice. We had a pretty big Thai streamer cover our game one time, and I always regretted not having it localized then. I also met a Thai journalist at Tokyo Game Show who was a fan of our game, and given that English proficiency in Thailand is relatively low, it may be a good bet to localize in Thai.

Pick A Localization Tool

Depending on your needs and budget, you can use google sheets, paid software like TradOS, or you could do like we did and roll your own translation tool.

Each has its pros and cons. For our first game Political Animals we used a Unity asset that loads the google sheets translations into the game when it starts. The problem with that was that when people had iffy internet connections it would sometimes not load the language.

Translation software does cost money, but if you use a software that a lot of localizers are already familiar with, it may save you some time in the long run since they won’t have to familiarize themselves with your tools.

Rolling your own loc tool was an okay compromise for us, although in the end I do wonder if we lost time(ie money) by constantly needing to design and update the loc tool in tandem with our game.

There are fancy new cloud translation sites out there that I won’t touch upon here sine I don’t have experience with them, but feel free to do your own researchand pick whatever suits you.

How to Find Localizers

You have two options when looking for localizers, a localization company and freelance localizers.

Localization Company

There are a few advantages to a localization company.

First is professionalization. Typically these companies will hire more experienced localizers, or  they have managers that will make sure that the localizers do their jobs properly and on time. They also have stricter protocols, so your freelancers won’t go “off script” or add localization that may be inappropriate or that they think is funny, but actually makes the game worse.

Second is you will only have to deal with one person, who will then deal with communicating with all of the localizers. This may save you some time.

The disadvantage is that localization companies are much more expensive than freelancers, they typically will charge $0.10-$0.11 per word. So for example a 30k word count would cost $3000. That adds up the more languages you want your game localized for.

Dealing with a localization manager is also not always ideal. Since they act as intermediary, you will have to rely on them to understand questions from developers and localizers. They will also likely be working on multiple projects and you cannot be sure how they will prioritize your project. So in terms of saving time or frustration by communicating with just one person, it’s not always a sure win. 

If you want to play it safe and you can afford it, a localization company is almost always the best idea.

Freelancers

The biggest advantage of freelancers is that they are much cheaper than localization companies because the money goes directly to them instead of an intermediary.

There are a few disadvantages though, including where to find freelance localizers in the first placeI will go into some detail later about how I found freelancers efficiently. 

Non professional or inexperienced freelancers can cause you a lot of trouble. They may be slow to do their work or have many delays. They may also try to be “funny” with their translation, at the cost of the game’s usability (meaning having funny descriptions instead of useful, accurate descriptions).

Lastly, you will have to communicate with multiple freelancers, which means answering a lot of questions, dealing with different personalities and level of English, etc. This can be alleviated with some smart organization, but it will still take a lot of time and patience.

Despite all these possible pitfalls, I decided to use freelancers. Academia : School Simulator is not heavily narrative based, so I felt like we could risk the possible lack of nuance in some translations. I probably wouldn’t do this for a game that’s very heavy on narrative like a visual novel or RPG.

How I found Freelance Localizers

I found a group called Indie Game Localization on Facebook. I put up a post describing the game, our localization needs, and a link to a google form which I asked localizers to fill out. The most important information I need is what their rates are and what their experience is. This gives me multiple data points by which to choose a localizer. It may be the case that one localizer is more expensive, but their experience warrants that cost. Or it may be that their rates are low, but they’re localizing for a language which is a little risky on turns of ROI, so I can take a chance with them. This is the flexibility that going with freelancers affords an indie developer.

There are also subreddits where you can look for localizers, or website like ProZ. However I have found the facebook group to be the most efficient.

Localization Process Agreement

I prepared an Agreement document that I sent to all of the localizers that lays out the processes for localization and payment. This document will differ depending on the exact process you intend to use for the specific game, but this is a good template to use. The main thing here is to make sure that the localizers are in agreement with the payment amount and procedures.

Localization FAQ

The game and the context of the localization will not be clear to all of your localizers. You should prepare in advance for ways to communicate with them so that you can answer their questions For this crew of localizers we had a spreadsheet where they could ask questions and the developers could answer. This was quite cumbersome, and ultimately this can probably be streamlined in a way that makes it more useful and less time consuming to answer. One of the localizers suggested a discord channel, which is a great idea.

Ideally the context of the localization should already be present in the tool you give to the localizers. That way they have less questions for you and things proceed more smoothly. However in reality it is also time consuming for developers to do this and they may not do it all the time.

A Discord or facebook group might also be a good idea, although this can also be quite chaotic.

What was the Result?

We announced the release of our localisation update on March 30, 2021. I’d been waiting for quite some time to see what the results of our localization experiment with Academia were. Short term numbers aren’t very useful with these things, and so when half a year had finally passed I took a look at the numbers and compared the 6 months before and after March 30 ( also did comparisons for 1 month and 3 months to track differences). It has to be taken into consideration that this comparison is skewed in many ways. First of all, since we haven’t been doing regular updates to Academia, sales will degrade over time. Total sales revenue declined 17% when comparing the two periods. The previous 6 months before the localization release also include the launch of the game, which means those numbers will naturally be much higher. Lastly some of these languages already had mods before we released our official localization. So for those languages specifically it will be more difficult to compare ROI since many players probably already picked up the game and installed the mod while the game was still “fresh”.

So how did our languages do?

Here is a copy of the spreadsheet where I did my calculations.

Brazil

Brazil declined somewhat at -6% in revenue 6 months after localization. When I look at the 1 and 3 month comparisons the gap is narrowing, so it may be that the Brazilian localization will be worthwhile in the long run.

Italian

I was also very disappointed by Italian which should -25% when compared to the previous 6 months.

Turkish

I was bullish on Turkish but it only showed modest growth at 8% more compared to the previous 6 months. Interestingly there was a bit of a boost at month 3, when there was 30% gain compared to the previous 3 months.

Russian

Russian shows a similar decline in sales comparative to the 6 months previous to the announcement, but similar to Brazil the gap is narrowing. At month 1 there was a -61% difference, month 3 -30%, and by month 6 the difference was -20%. I suspect within a year the gap will have closed.

Polish

Similar to Turkish, Polish posted a small 8% gain compared to the 6 months previous.

Thai

Of all the languages we had localized, Thai is the crazy outlier here, posting a 331% increase when comparing the 6 months previous to localization release vs 6 months after. At month 3, similar to Turkey, it experienced a small boost (possibly due to the summer sale?) where it showed an increase of 424% compared to the 3 years previous.

LatAm Spanish

LatAm Spanish is a little harder to track since it encompasses so many countries, so I only did the 6 month comparison, where it shows -13% when compared to the 6 months previous.

Indonesia

I initially had high expectations for Indonesia before I realized that the Steam Store page does not list Bahasa Indonesia as a language. This is a really big deal, since part of my localization thesis is that the Steam algorithm will prioritize showing content to users based on their selected language. Since Bahasa Indonesia is not a selectable language in Steam, then Indonesian players likely won’t even know that we added their language to the game. Unsurprisingly it showed a -34% difference when compared to the previous 6 months.

Conclusion

Within 6 months, only the Thai localization can reasonably be said to have paid for its localization costs. Turkish and Polish are on track to do that within a year of the localization release.

Localization is definitely a long term game. Ideally, you should have your localization all ready and done before your game launches to take advantage of how Steam increases your visibility at launch. As with most things when it comes to success in games, localization isn’t a sure thing, but with some careful choices, you can improve your game’s revenue stream over the long haul. There are many different things to take into consideration, and I hope that this article helps other indie developers get a better idea of how to approach localization for their own games.

The Squeaky Wheel Falls Silent

It is with a bittersweet feeling that I am writing this blogpost to share with you the news that Squeaky Wheel, an independent strategy game development studio based in the Philippines, will cease active game development. I know this must be a shock to some people, so I wanted to take the time to explain our thought process, and share what lies ahead.

The covid 19 pandemic was like a big pause button in a lot of people’s lives. While it created lot of destruction and trauma, It also gave some of us time to rethink the trajectory of our lives and careers. Coupled with the fact that we were winding down development of Academia : School Simulator, it was the perfect time to think deeply about what’s next for myself and Squeaky Wheel, and if those two things would be intertwined.

I spoke with my cofounders Tristan and Marnel about how they felt about moving forward with the company, and over numerous conversations it became apparent to me that our goals and aspirations were diverging. So we came to the conclusion that it was best to part ways, and we agreed to buy them out of the company so that I could move forward on my own after we released Academia : School Simulator to version 1.

Initially, my plan was to continue Squeaky Wheel along with our COO Marica as a micro publisher, focusing on the Southeast Asian region. The idea was to make some small investments in the same vein as Ruinarch, and build up a portfolio of strategy and simulation games whilse supporting regional game development. The long term plan was to be something of a Lite version of Paradox Interactive.

But then something crazy happened.

On a whim, I sent in a speculative application to Paradox Interactive, and after 4 months and 4 interviews, they offered me a position at the company. When I got over the shock, quite a few things crystallized for me, and helped me make a decision.

I’ve been very tired of leading our small company for a very long time. And while I was proud of what we’d accomplished, the truth is that I was incredibly burned out. While the initial plan of turning Squeaky Wheel into a micro publisher was exciting, it was also going to be pretty rough, with a lot of new headaches involved in becoming a different organization entirely. 

The allure of joining one of my favorite companies and simply becoming a cog in the machine was very tempting. As I told one of my interviewers, the idea of still being in a leadership role but without feeling like the entire fate of the company rests on my shoulders sounded perfect.

In the end, I accepted their offer. (Note: Actually getting to Sweden and working there is a whole can of worms that may still get derailed at any point due to Philippines bureaucracy, so fingers crossed it all works out!)

And so here we are. The Squeaky Wheel team has now disbanded and are each doing their own thing, and we’ll be cheering each other on in our individual efforts.

Marnel has hired Neil to help him work on the next big simulation game to come out of the Philippines.

Tristan is taking his time thinking about the future for him, whether that’s joining Ubisoft, joining the foreign service, or following in the footsteps of Wan Hazmer and willing himself into becoming the lead designer of the next game in the Final Fantasy Franchise.

JM has joined the fabulous folks at Chikonclub in developing the amazing game social cooking game Soup Pot.

Marica will continue as the caretaker CEO of Squeaky Wheel to manage our business affairs, and working on an exciting secret non entirely game related project with Squeaky Wheel.

With regards to our games, we will continue to maintain Academia : School Simulator to ensure that any major issues are resolved. Maccima will continue to actively develop Ruinarch. 

I’m very proud of the things we’ve accomplished together. When we embarked on this quest, we wanted to prove that you could create a successful original IP in the Philippines. It took us two games and 3 years to achieve that. The next quest was to help fund an original IP by a different studio, in order to help build up the ecosystem of game IPs in the Philippines. We did that in year 5 with Ruinarch. The end the goal was to prove that you could create a successful original IP in the Philippines, and that our games were as good as anyone else's. It was a long and difficult road and sometimes it felt like the company was held together by duct tape and prayers. But we all made it through somehow. We definitely could not have done it alone, and I’m very grateful to our team for all the hard work and support over the years. 

While it is time for us to go our separate ways, I believe the seeds have been planted for new and better things to come, and I can’t wait to see what happens next.

Squeaky Wheel could not have succeeded without the help and support of fellow game developers. It’s impossible for me to remember everyone, so please don’t be upset with me if I forgot you. It’s merely a testament to how many people need to help you in order for you to thrive in this world :

Aissa Ereneta, Madelynn Uy, Marie Cortez, our parents and families, IGDA Philippines, GDAP, Solon Chen, Alvin Juban, Indie Fiesta, Gwen Foster, Flip Velez , Francis Roque, Positech Games, Introversion Software, Indie Megabooth, Bitsummit, Tokyo Sandbox, EGX, Taipei Game Show, Tokyo Game Show, Level Up KL, BICFest, VirtualSEA.com, Michael Logarta, Lukas Stobie, Another Indie, Ysbryd Games, Toge Productions, Tanya Short,  SomaSim, Gabby Dizon, Paul Gadi, co.lab, builtable.co, Fiel Gabriel, Vernon Cenzon, Robert Yatco all the streamers and players!

Introversion Software Acquires Academia : School Simulator

London - Apr. 1. 2021 - Introversion Software, developers of Darwinia, DEFCON, Uplink, Prison Architect, and numerous failed prototypes, also known as the “Last of the Bedroom Programmers”, today announced the purchase of all rights and assets for the Academia : School Simulator (henceforth known as A:SS) IP, a GDAP Gameon award winning management simulation game developed by Squeaky Wheel. 

Introversion Software will take ownership of A:SS on all current and any future platforms, including Windows, MacOS, and Linux PCs, Amiga, Atari, Commodore, Colecovision, and Switch, Xbox and PlayStation and Dreamcast and 3DO and Jaguar and NEO GEO consoles, as well as mobile on iOS and Android tablets, and Gameboy, Game Gear and Wonderswan and Lynx and Gizmondo and Ngage handhelds. This acquisition also allows Introversion Software to continue development of A:SS going forward, which is fine since A:SS basically copied Prison Architect anyway.

In A:SS, you, the player, are challenged to build a high school with fantastic facilities like science labs, basketball courts, and art rooms, or do the bare minimum and live off government subsidies! Will you offer your delinquent students counseling, or simply send them to detention to let them waste their lives away? Will you hire the best teachers or cheap out and build giant classrooms with a 1:100 teacher to student ratio? Will you build enough toilets, or snicker as your students are forced to relieve themselves in the bushes? The choice is yours! Inspired by management simulators like Prison Architect, the game does an admirable job of making it obvious how schools feel like prisons to their students.

“Ever since we sold Prison Architect to Paradox, we’ve not really done much have we? I mean having gobs of money is fun, but at the end of the day  we need to live up to being the “last of the bedroom programmers” for chrissakes! And since we can’t seem to come up with new game ideas, we figured we’d just buy one we already know how to make,” said Introversion cofounder Mark Morris. 

“Given we basically stole the Prison Architect engine and art style from Prison Architect, it’s actually rather generous of them to buy the IP rather than sue us for it,” said Ryan Sumo, cofounder of Squeaky Wheel and original artist of Prison Architect.

“A:SS has been an intensely rewarding project for us,” continued Ryan Sumo. “Every developer loves seeing their creations come to life, but through Early Access, we’ve been building and managing this building-and-management game for more than 4 years. I think we’ve taken A:SS just about as far as we can, and we’re all eager to see where a team like Introversion can take it next!”

For more information about A:SS, visit : https://store.steampowered.com/app/672630/Academia__School_Simulator/

How We Used Airtable To Organize our in-game Events

Note: I am not affiliated with or endorsing Airtable in any way. I’ve simply found it a very useful tool that not many folks that I know are aware of, and I wanted to show one specific use case for it.

Airtable is a web app that basically makes an easy way to create an online database. I like to think of it as google sheets on steroids. We’ve talked about using Airtable as a productivity tool before, but I haven’t had the time until recently to document exactly how we’ve been using it in our game development process. In this blog I’ll share how we used airtable to organize and document our events system in Academia : School Simulator.

Events Game Design

First, I will quickly explain how our events system works (here is a link to the events game design document for further reading). Events in Academia : School Simulator are random occurrences that pop up in the game that force the player to make a decision. This was always part of our long term design, but when we added it the intention was to improve late game enjoyment of the game. It was also a way to add narrative elements to the game that would be much more difficult to add as a proper mechanic.

Organizing Our Events

Our Events system has a lot of different parameters, ranging from the Name ID of an event, the event description, down to whether or not the event is a parent, and numerous text and effects and costs of different options. As of release, we have 125 different Events, most of which have at least 2 options, with a corresponding success and failure text. In a purely narrative based game I suspect that this would be even more (now I wonder how they organize their content).

While it is possible to organize this in a spreadsheet, the information for one event would be displayed in a single horizontal or vertical line of information, which is terrible for quick comprehension.

With Airtable on the other hand, I hijacked their “gallery” view to make what I think of as a “card” view of each event. This way I can immediately see the event, see what the requirements are, what the options are, etc. I can select which fields to show so that I have just as much or as little information as I need.

I will now go through each different row or field, as Airtable calls them, to show how I used these to organize and parse data.

Name Fields

Name fields are fairly basic, just simple text. I used this for both our Name and Name ID fields. In retrospect I could have simplified things by just using the Name ID and saving myself one field. The only difference between the two is the Name ID is what we use as input when entering data into Unity.

Attachment Field

This is a neat tool that Airtable has over Google Sheets. You can make an attachment field and easily attach a file, like say an image or a pdf to each cell. For our purposes I used it to attach the icons we used for each event. This acts as both a way to visually identify the event and also as a sort of “to-do” list for me so I know which events I still have to make icons for.

Linked Fields

This is one of the cooler fields in aritable, which allows you to link to another tab. For this table I decided that it would be easiest to organize by separating the options and outcomes text into separate tabs for better organization. I would then link the records in those tab to the main Events table for better viewing. You can do something similar in sheets, but the way airtable does this is so dead simple and intuitive (see image above).

Single And Multiple Select Field

This allows you to create categories and assign one or multiple categories to a row. This didn’t turn out particularly useful for the events, but it was very handy for the Achievements. In our Achievements system we had different categories and achievement levels. Grouping the layout of the table by category allowed us to see immediately how many Achievements we had in bronze, silver, and gold, and make a decision on whether that needed some balancing.

Checkbox Field

This is also fairly simple, in that it allows you to add a check box. What makes it useful is that Airtable allows you to group the records by checkbox, so you can hide stuff that has been checked off and you can more intuitively see what has and has not been checked.

Grouping By Multiple Fields and Filters

For the most part all of the fields I listed above are replicable in something like google sheets. The magic of Airtable is how it lets group and filter using multiple fields. So for example I wanted to see how many event types there are and see that according to each event weight, I can very easily do that. I can also filter out records that have already been verified to know which events I still need to test out. I’m sure some formula wizard already knows how to do this on sheets, but for the average user the capacity to do this on the fly is a game changer.

Conclusion

I have just barely scratched the surface of what Airtable can be used for, and I’m sure that a lot of you out there will be able to expand on the use case that I have suggested here. If you want to take a look at our tables, here are read-only links to our events and achievements tables. If you find a cool use for Airtable please do let me know!

Thanks for reading, and hope you found this interesting! If you want to support us, you can buy Academia: School Simulator or Political Animals, or Ruinarch.

How much should I discount my game?

A perennial question for any game developer is how much they should discount their game during a sale. They must weigh the balance between increasing the number of units sold and possibly devaluing their product and “leaving money on the table”.  It’s something that I’ve been thinking about a lot lately as we are about to launch version 1 of Academia : School Simulator. Given that the proper launch of a game is one of the few times Steam gives a real boost to visibility, choosing the wrong discount could make a very big difference in revenue.

30% or 25%?

Initially I was set on doing a 30% discount. We’ve tried to keep Academia’s discounts relatively low to preserve the game’s value, and have used the 30% discount to signal major milestones to the game (Alpha 3, 4. etc). So having a 30% launch discount made sense.  But some doubt started to creep in. The 5% difference between 25 and 30 is equivalent to $1 in real money terms. If the amount of units sold at a 25% discount vs a 30% discount is relatively similar, then that means we could be losing $1 per sale that we didn’t really have to. For example, all things being equal, if we sold 10 units at $20 per unit, a 30% discount would net us $140 and a 25% discount would net us $150. 150 is obviously better than 140.

Intuitively, it would seem obvious that a larger discount would drive more sales, and thus net us more revenue. The question is “by how much” and “is it worth it”?

Discount Spreadsheet Explanation

Luckily Academia has been in Early Access for more than 3 years, so I have quite a bit of data to look back on. I prepared this spreadsheet to look at the data since 2019.  Here’s a quick explanation of my “methodology”

Sale type : This provides context on what kind of sale this was.

Visibility Boost : This shows whether I used one of the Visibility boosts steam gives to all developers to allow them to temporarily increase their game’s visibility.

Date: Self explanatory, also helps provide context.

Discount : Amount of discount

Units sold : Units sold in one day of discount

Units sold 1 week before : This is used as a comparison to units sold during the discount. It is assumed that this is a “normal” or control amount of units sold.

Unit difference increase : This is the difference in the number of units sold. This answers the question “how many more multiples of a regular sales day do I get by doing a discount?” I get this number by dividing the discounted units sold by the units sold one week before.

Rounded : just rounds the numbers for easier comprehension.

So for example when I compare the two sales shown above, it says to me that the 30% discount on Alpha 3 gave us 8x more sales than the Lunar New Year 25% discount, which only gave us 2x more sales. Two data points isn’t very useful however, which is why I plotted out many more discounts for comparison.

What does the data show?

So what does the data show? After plotting all the data I took the average increase of sales on dates where we did 30%, 25%, and 20% discounts.  Unfortunately we only had two datapoints for the 30% discounts, but lets assume that it’s fairly accurate.

If I am to believe this data then it says that discounting at 30% off generally increases our units sold by 10x, while increasing it by 20%-25% increases our units by 5x. Or put in other words, we double our units sold when discounting at 30% rather than 20%-25%. 

In terms of revenue generation, this puts my mind at ease and assures me that 30% is the right number for our launch discount. Even if we assume a more conservative 8x increase vs 10x, the difference is still large enough to cover the “cost” of the additional 10% discount. Taking into consideration the fact that launching verson 1 gives a game a big visibility boost and anecdotal data that Steam’s algorithm is more inclined to share games that make more money, I’m confident this is the right path. However there’s still some lessons to be learned here.

We Left Some Money on the Table

Unfortunately for us, the data seems to have revealed that the past few years of setting discounts at 25% meant that we may have earned us less money than we could have. While there are fewer data points for 20%, the data seems to indicate that there is little difference in units sold between the two of them. That means we lost a dollar ( or about 50 cents, after all deductions) for every sale we made last year by discounting at 25% rather than 20%.

I suspect this is related to psychological pricing, similar to how stores price items as $1.99 instead of $2.  The thought in this example is that $1.99 reads more like $1 rather than $2 so the buyer feels like they are getting a better deal.

Conversely, even though 25% is a bigger discount than 20%, when buyers are making a snap judgement based on price, 25% still feels the same as 20%, while 30% feels like an entirely bigger discount because of the change between 2 and 3.  So the takeaway here is avoid half measures when it comes to discounting. If you’re deciding between 50% and 40%, just commit to either, don’t do 45%.

Thanks for reading, and hope you found this interesting! If you want to support us, you can buy Academia: School Simulator , Political Animals, or Ruinarch.

How to Make a Decent Game Trailer for less than $100

Squeaky Wheel recently announced that the school management game Academia : School Simulator will soon be graduating out of Early Access. To help hype the announcement, I wanted to make two trailers, one for when we announce Version 1.0, and one for the actual release. The first trailer was released this week, which you can see above. Making game trailers is a key part of the marketing of a game, and there are many debates online about how to do it, how much it should cost, etc. I know that a lot of indie developers don’t really have a lot of money to spend on trailers, so I thought I would share my process here to give them an idea of what making their own trailer could look like.

Just to be clear, I know that this trailer is not the best, and it’s not going to compare to the best. But it is a pretty good trailer, made at a very affordable cost and with relatively little skill.

Conceptualization

The first step is to conceptualize the trailer. This means figuring out what you want to show in the trailer and making an outline of it that you can follow while actually editing the video. This is what my concept document looks like. I’ll reveal a bit of a cheat here. My original document was much looser than this, and I kinda went back and fixed it so that it looks as if it should if I was more disciplined.

You can keep it fairly simple or if you are artistically inclined and the concept is super complex you can even storyboard it. I’ve done it both ways. The important thing is to be able to get your ideas down so that you have some direction with the video.  For this announcement video I wanted to keep it fairly simple. I used what Derek Lieu calls the music video montage as my template. Basically it means cutting a video in time with the background music.  While this is usually better done with action games, you can make it work for more chill simulation games.

Finding the Music

Getting custom music done is great, but it can be creatively time consuming, especially if you don’t know what you want. I had a general idea of what I wanted, based on this trailer by Another Brick in the Mall. I wanted something that sounded classical and was also uplifting, with a relatively high bpm. Basically I was looking for lowkey excitement. I also wanted something that slowly builds up, then has a quiet release (sorry I don’t know how to speak music!) I also needed it to be around 1 minute long, which is the standard suggested length for a trailer.

After scouring numerous royalty free music websites I landed upon this track on soundstripe by Stephen Keech.  It had everything I wanted, with the one exception that it was two minutes long. There was a section of the piece that ended a little after one minute though, so I decided to go for it and just fade the track out at the one minute mark to suit my needs. The license cost $39.95 for a single track. Soundstripe sometimes has promos where its good value for money to buy a year’s worth of access to licenses. I’ve already lined up a composer for the next trailer, so I was happy to take just the one track.

To edit the track to 1 minute, I used the free tool Audacity.

Recording Video Clips

Now that you have your music, it’s time to record video clips. Since I’ve already made a couple of trailers for our game before, I didn’t have to record all new material, and I was able to focus on recording some key clips. You can record video using OBS, or spend a little extra ($37) to download Fraps. Here are some broad tips for recording video clips:

High Res

Make sure that you have a lot of hard drive space and record the largest resolution that you can so it looks good on video.

Capture Movement

Whenever possible, try to capture movement in your game. A one minute trailer demands people’s attention, and there’s no easier way to do that than with movement. Even with a game like ours where there is not a lot of action, you can fake movement by panning and tracking the camera slowly to make players feel like there’s movement.

Hide UI

Depending on your game, it may be good to have a button where you can hide your UI.

Camera Controls

Add camera controls to your game like being able to set the speed of the camera scrolling, so you can choose if you want to emphasize speed (for excitement) or slow down the camera (for drama or visualization). Being able to lock the camera onto a scene is also helpful. I messed up a little bit in the video in the scenes where the workers are building the school because we didnt have this feature. It’s barely noticeable but annoyed me so much!

Image Editing 

You will need at least basic image editing to create stuff like the logo and any sprites you may use for the trailer. I didn’t add the to the cost of the trailer because presumably if you are making a game you have all of these assets already, but just adding it here in case it needs to be said.

Video Editing Software

Next up is video editing! Adobe Premiere is the standard for video editing, but when I was cutting our previous trailer I found this neat software called PowerDirector. It does everything I need it to for the trailer and only costs $19.99 for one month or $48.99 for an entire year, which is like $4 a month for 12 months. Given that I wanted to make two trailers, it made total sense for me to get the annual subscription. But for your purposes you should be able to learn everything you need to know and release the trailer within the span of a month. 

I can’t teach you how to use Powerdirector in one article, so the following part of the article presumes you already understand how to use video editing software in general. What I will try to explain is how to use transitions within a video to create moments that are pleasing to the viewer’s eye.

Opening Scene

For the opening scene I did a bit of a cheat. It’s drilled into every gamedev that you should NOT put your logo within the first few seconds of the trailer because nobody cares about your logo. I agree to a certain extent, but I think there is value in imprinting the name of your game on a viewer within the first few seconds, assuming you figure out a clever way to do it.

In my case my initial concept for the trailer opening was to have a bus slide in from the right and “drop off” some characters, who would then move offscreen to start “building” the school.  This suggests the beginning of the school, and is capped off by the ending where a character walks home after a long school day. At some point before starting the trailer I realized I could slap on the Academia logo onto the side of the bus. It’s effective because it makes sense in the context of the universe. Buses often have logos stamped on their side. The logo will be in and out of the scene within 2 seconds, so it doesn’t overstay its welcome. But any player that watches the first 5 seconds of the trailer will at least remember that this game is called “Academia something or other”.

Jump Cuts and Building

Jump cuts are transitions where you simulate jumping forward in time. This is perfect for sections of the trailer where you show off building things. With each successive jump cut, showing off something “new” stimulates the viewer’s eye. This is particularly useful in building and management games because it really sells the idea of building something out of nothing, which is what attracts many players of this genre.

Transitions and Contrast

In art composition, contrast is one of the main techniques artist use to emphasize or highlight an artwork. It is the contrast between light and dark or warm and cool colors that helps an artwork visually “pop”.  The same principle can be used in transitions. The first few scenes start out showing a zoomed in view and using jump cuts to sell the idea of “building”. 

When the music transitions (more on that below) from a faster pace to a slower, more languid pace, I then transition to a zoomed out screen of a giant school, and slowly track the video upward. This matches the pace of the music, but more importantly it builds off the first few scenes where I show the building aspect of the game, to a scene that say “look at just HOW MUCH you can build!” It is the contrast between the smaller school zoomed in versus the giant zoomed out school that really sells the idea of the scale of the game.

Transitions and Music

Another easy way to capture viewers’ attention is by combining sound with transitions. This screenshot I took shows how I did that. Note that each transition (marked with an “A” Icon) is placed at the exact moment where there is the audio waveform increases in amplitude. When listening to the music, that increase is a thump of a percussion instrument. When that thump combines with a visual transition onscreen it triggers delight in a viewer’s pattern recognizing brain.

Off topic: when researching the right terminology for audio, I found this absolutely amazing interactive website explaining how waveforms work.

Wipe Transitions and Movement

I referenced the importance of finding some sort of movement to put in the trailer. We can combine this with the “wipe” transition to follow the camera movement and create a pleasing effect for the viewer’s eye.

Closing Scene

I had a moment of inspiration here while capturing video. My original intent was to simply fade the screen to black to signal the end of the day as a contrast and natural end point of the trailer which starts in the “morning”.  However while capturing video for the trailer I noticed that it was nighttime and there was a single janitor on the way home from the school. I paused the game and zoomed in on this scene. It felt like the perfect way to end the trailer on a poignant note, everyone’s going home, the trailer is ending, development on the game will end. So I captured it and put it in the trailer. It’s important that even though you do a lot of planning in the conceptualization phase that you still be open to moments of serendipity like this.

Thanks for reading, and hope you found this interesting! If you want to support us, you can buy Academia: School Simulator , Political Animals, or Ruinarch.

How to Fix Miscommunication Issues in Your Team

Good communication is important in all game development studios, even the smallest ones. You may think that small teams are immune from miscommunication, but if you think about it, you can have miscommunications even with the people closest to you (just ask my wife).  The only way to avoid miscommunication within a team is to be like Eric Barone and make a game on your own. For everyone else, practicing good communication skills is the only way that you can reduce friction in your team communications. 

Good team communication may sound like a silly thing to be worried about, given all the things that can go wrong with a game. But I’m sure you don’t have to go back too far in your memories to remember an interaction with a teammate that should have taken 5 minutes, but instead took 30 minutes and left the both of you exhausted.

In the following case studies I’ll lay out some of the communication issues I noticed within our team, and how we tried to rectify them.

Mahirap ba to? (Is this hard?)

Since no one is immune from poor communication, I’ll use myself as an example. Often when new feature request would come in, I would ask our devs the question “Is this hard?” and receive some of the following answer.

Answer 1 : “Not really.”

Answer 2 : “Yeah it’s hard.”

Answer 3 : “It’s not hard but it will take a long time to implement.”

Inevitably, this would lead to more questions as I tried to figure out the level of difficulty of the task. Eventually I realized I was actually asking the wrong question. The last answer helped provide me a clue to what the better question actually was. 

What I really wanted to know, in the context of my role as a project manager, was “How long will this take to implement” so that I can assess whether or not it is worth adding to the game, given its presumed impact. Since I came to this realization, i’ve been asking “how long” instead of “how hard”, and saving the team around a minute or two everytime these conversations come up.

Tatamaan Memory (The Memory Will be Hit) and Programmer Jargon

A problem that often occurs when programmers speak with non-programmers is that there are things that are jargon or just presumed as understood by non-programmers. While jargon can be useful sometimes if its clear that both parties understand what’s being said, once it become apparent that there is some misunderstanding, further clarification should be offered. It should be incumbent on the person using the jargon to be the one to clarify what it is they are trying to say.  The following are some common responses given to me by our programmers. Initially they were inscrutable to me, and took quite some time to have them explained to me. I still forget what they mean sometimes, but maybe that’s a sign that I’m getting old.

1. The memory will be hit : This basically means that this will add to the game’s memory usage, and may cause some issues in the long run. It would still be useful to follow up on how much memory this will actually use and what the actual danger would be.

2. This needs to be saved : This basically means added complexity to the game, and larger save files, which we are trying to avoid.

3. We need to “keep track” of that : To be perfectly honest this still confuses me sometimes.

The important thing to consider here is that while jargon can be a useful shortcut between two people who understand each other, there needs to be a clear understanding that if the jargon is not understood, then an explanation is needed. Speaking of which...

The technical explanation is not an explanation

Oftentimes when I ask our programmers what the implications of an issue are, they will respond with *a technical explanation*. It’s hard for me to really explain this, so an analogy might be better. If I ask someone “what would happen if I threw this ball at your face?” the answer I really want, and would be useful, is not *an explanation of the physics of acceleration, mass, wind resistance, etc*. The useful answer would be “The ball will hit me in the face, and it would hurt.”

Similarly, when asked about the impact of a design or code change to the game, it’s probably easier to explain how these changes would impact the player/game, rather than how it would change the code. 

Fewer Words is Better (Not!)

As many gamedevs are quiet introverts, many of us have embraced the idea that saying as few words as possible is the most efficient way to get out of having to talk to people.  This gives rise to two issues when a quiet dev is asked to clarify something in the game/code:

1. The person they are speaking to is either too meek or doesn’t care enough to keep asking clarifying questions. This ends the conversation very quickly but inevitably creates a problem down the road where errors that come out of the miscommunication impact the game.

2. The person they are speaking to is not satisfied with their answer so they will keep asking until they have a satisfactory answer, possibly creating a stressful or hostile environment.

Issue 2 is not only tiring to both the quiet dev and their questioner, it’s doubly unfair to the questioner because they have to expend the effort of finding context and clarifying meaning, which is a lot of mental work!

My only advice here is to ask people to consider adding clarifying context to their statements. This may involve some additional effort on their end, but saves everyone a lot of time in the long run.

Zero Information Answers

And here’s me doing a u-turn. Just as it is important to note that using as few words as possible is not the best way to communicate, there are times when we use too many words without really conveying useful information. Here’s an example:

Zero Information : Company A's cost and Company B's cost are far apart. 

Even though this statement may be accurate, it gives zero actionable information and forces the recipient to ask you follow up questions.

Some Information : Company A is cheaper than Company B

This sentence is shorter and immediately provides context. Company A is cheaper, which ostensibly is a good thing.  Recipient can then ask follow up questions like “but do they offer the same level of service?”

Most Useful Information : Company A is cheaper than Company B, but I like company B’s service better.

This sentence immediately provides context and answers a possible follow up question.  It is the perfect answer in terms of information efficiency.

Obviously we won’t be able to reach peak information efficiency all the time, but taking a little effort to think about what it is that we want to convey before typing it in can lead to great improvements in communication. This is especially useful when conversations are in chat or email. There is no immediate pressure to respond, so take your time!

Zero Information Questions

The flipside of of Zero Info Answers is Zero Info Questions.  This is when a colleague asks you a question but does not accurately provide context as to what the question is about. Here’s an example:

Zero Information : Can you review the sizes for the exam results panel? It seems like the numbers are wrong. Some of them don’t add up. Like, the sum of the heights of the student exam header (right side) is not the same as the height of the students grid.

While this question may be accurate, there are no context clues about what the actual problem is and forces the recipient to investigate further.  Instead of saying something is different, say why you think that difference is wrong, and what you assume is the correct solution.

Some Information : Can you review the sizes for the exam results panel? The numbers on the student grid are shorter than the sum of the student exam results panel.

This is more useful because it immediately tells the recipient what the problem is, and they can investigate it.

Most Useful Information : Can you review the sizes for the exam results panel? The numbers on the student grid are shorter than the sum of the student exam results panel. I think they should be the same height.

This is more useful because it immediately tells the recipient what the problem is, and what the expectations are.

Always remember, instead of just saying something is different, provide context as to why it is different (ie one is shorter/cheaper/faster than the other).

Pwede Naman (It can be/can be done)

My last example is a little language specific, Filipino to be exact, but I’m sure there must be similar language cases in other countries. Locally, “Pwede Naman” is a non committal catch all term that can provide different meanings based on context or the person using it. One person’s “pwede naman” might be a yes, but I’d only ever use it to convey a very ambivalent feeling, something like saying “I guess that’s ok…” in English.

This is fine when used in casual conversation, but I absolutely hate it when used in a decision making context. Here’s an example for when someone is asked “what do you think about adding this mechanic to the game?”.

Zero Information : I guess that’s ok.

This gives no context or value judgement whatsoever. It conveys no opinion. If you are not sure about the impact of a mechanic, it’s better to very clearly say something like “I really don’t have strong feelings about this” or “I need more time to think about this and then I’ll get back to you.”

Some Information : I like it, but I have some concerns OR I think that’s a bad idea because (concerns).

This clearly conveys how you feel (either positive or negative) about the mechanic and that you have concerns about the design, and what they are.

Most Useful Information : I love it, but I have some concerns OR I think that’s a terrible idea because (concerns). Then explain (concerns)

This is basically the same as the previous example but with a further explanation of the specific concerns, and the use of stronger language to convey your feelings about the mechanic.

This bothered me so much that during our company outing last and team building event last year I brought it up and made everyone promise to never use the words “pwede naman” again in a work context. Did I succeed? Well...pwede naman.

Conclusion

Any team of more than one person requires good communication in order to succeed, or at least have a more harmonious work environment. This is even more important in smaller teams. In large organizations poor communicators can be hidden away or have better communicators or team leaders assigned to them in order to facilitate communication. In a small team, there’s nowhere for these issues to hide. This is especially important if you are the leader of your team. You may not think that there is a communication issue because, well, people never communicate it to you. But in fact people are either too scared of you to ask for clarification or will just make their own assumptions about what you meant, either of which will lead to bad outcomes in the long run.

How to Decide what Mechanics to an Early Access Game?

Congratulations! You’ve just released a successful Early Access game and are looking forward to receiving player feedback! After all, one of the reasons you did Early Access was because you wanted to let the community shape the game right? What’s that? You have a firehose of suggestions pointed in your direction and you don’t know what to do?

Don’t worry, you’re not alone. The dirty secret of player feedback is that it’s not easy to parse what is good, actionable feedback versus the impossible task of trying to cater to the whims of every single player. There’s also the real risk that you lose the soul of your game by simply agreeing to all the suggestions sent your way. Learning to navigate player feedback to figure out what works for you is a skill learned through time, and it can be overwhelming. At Squeaky Wheel, I developed a process to help our team figure what mechanics and feedback to focus on. This is only one out of millions of ways to manage this process, but I hope it gives you all some ideas.

Make a List and Check it Twice

Our design director Tristan Angeles takes the lead on checking on and responding to player feedback since he’s the lead designer and it’s most important for him to know this information.  If there’s anything we need to know about what the players want, the buck stops at Tristan.

So I ask Tristan to make a spreadsheet of common feedback/requests from players for new mechanics and to weigh them by the number of common requests.  This can be tricky since players will ask for the same mechanic but they will phrase it in wildly different ways. It’s important to try to discern what it is the player wants to do, versus simply reading their request and assuming that’s what they want (figuring out context is tricky, but key! It’s like being a detective!)

Organize and Categorize

I then created a Trello board to help us organize and hash out which mechanics we want to keep.  I think Trello is very limited when it comes to serious project management, but for short term tasks like this and to simply organize your thoughts it is an incredibly useful tool. However it’s a tool that you need to design!

For example, this this Trello board I organized the mechanics into three lists : Aesthetic, Quality of Life, and Gameplay. I would then simply drag the mechanics into the appropriate list so we know what kind of mechanic we’re looking at right away.

Next, I ask team members to take a week to think about and pitch mechanics.  This activity is also designed. It keeps anyone on the team from simply acting like a player and saying “I want this mechanic” without thinking about the implications to gameplay. So I made a template for them to follow when adding a mechanic. Once that’s done, we go on to the next step, voting for mechanics!

Fighting/Voting for Mechanics

I would reserve a day, or possibly 2 days for this part of the process, as it can be very tiring. I first ask team members on the team to vote for the mechanics that they want to keep by assigning themselves to it. This gives the subliminal message of “you’re now assigned to this task, do you REALLY want to add it to the game?”

Any tasks that don’t have votes on them are quickly added to another list of tasks that have been “denied”

We then argue about the mechanics that have multiple votes, asking those that voted for it more specific questions and opening the floor for those against it. We also categorize label the mechanics based on length of time to complete. This helps us when we start to budget out our schedule.

Are you Willing to Die for This?

For mechanics where only ONE team member is interested in the mechanic, we ask them to sell the mechanic to us as if their life depended on it. This further winnows out mechanics. If you can’t bring yourself to explain why the mechanic is important to you or the game, then it’s probably not worth adding. Obviously this runs into the issue where a team member may simply not be capable to selling well or may be too shy to speak out to the team and defend the mechanic. In these cases it relies on the project lead to coax it out of the team member, and to make sure that generally speaking they have created an atmosphere that is open to communication and free flowing ideas.

However, bottom line for me is that a good game designer needs to know how to sell their mechancis. As a designer you have to sell your ideas to the team. It may well be that your idea is brilliant, but you need to be able to show your fellow devs why it is a good idea so that they also get on board and are eager to implement it.

Themed Updates

After a day of fighting over the mechanics and settling on what we can reasonably add to the game in time, I then take the final step of organizing the mechanics in a way where they reasonably work well together and can come together in a certain theme (eg our law and order update featured the lawyer, goons, and changes to school monitors).

Organizing by theme is a great way to split up the design tasks in a way that makes them manageable and also makes it easier for your players to understand what they’re getting with each update. It’s a win-win!

Conclusion

This is but one way of organizing your mechanics and figuring out a roadmap for your Early Access or Live Ops/GaaS type of game. This is a problem we had to face before, and there weren’t many resources online about how to manage player feedback. I hope that you find this article useful!

Thanks for reading, and hope you found this interesting! If you want to support us, you can buy Academia: School Simulator or Political Animals, or Ruinarch.