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.

The Road to Ruinarch Part 2: Launch Sales Results

A few weeks ago I wrote an article explaining the methods we used to gather wishlists for our published game Ruinarch and ended with a prediction on how well it would do. As a recap, here are my predictions for the first week:

Pessimistic Launch : (0.075 of wishlists) 2100 units

Realistic Launch : (0.25 of wishlists) 7000 units

Optimistic Launch : (0.5 of wishlists) 14000 units

Launch Excitement

Before the big reveal (just scroll down if you simply can’t wait!) I wanted to share the first few moments pre and and post launch.

We’d scheduled a little online get together to hang out on our discord server in the hour leading up to launch. Ideally at this point you’re all set and you’re really just waiting to push the green button (If you’re pushing a build right before launch you’re doing it wrong!)

Around 15 minutes before our expected launch, I got a Steam notification saying the game had launched.

Me: Hey Marvin…did you launch the game already?

Marvin : Ah no that’s just the announcement, I timed it to release at 10pm.

Me: Uh, are you sure?

Our Discord Server: DID THE GAME JUST LAUNCH? IT LAUNCHED FOR ME! (Cue fight about the game launching ahead of time in certain areas, which btw you can’t do afaik)

Marvin : What? WHAT? Wait, WHAT DO I DO?

Me: IDK I mean…just launch it I guess.

And so that’s why you all got Ruinarch 15 minutes earlier than intended. As an aside, I was a little miffed that my marketing idea of getting people to RT the launch to speed up the launch time (100 RTs and we launch NOW!) was vetoed. I feel like we launched early anyway so we might as well have tried to hype it up. :P

For a few glorious minutes after launch we were in the front page top sellers list, alongside ACTUAL hits like Fall Guys, Flight Simulator, Among Us, and Crusader Kings 3.

Week 1 Results

Happily, we very quickly blew past our pessimistic and realistic predictions, but fell just shy of our optimistic launch expectations. We sold 13882 units, which gives us a sales to wishlist ratio of 0.49, closer to Jake Birkett’s old number and exceeding the average of 0.36 and median of 0.2 established by Simon Carless’ (limited) data. As you can see there is a very sharp dropoff after the first few days, and that slow decline continues to this day.

We’re absolutely thrilled about these results but more importantly so are Maccima games, who are now planning a trip to Bali as a reward for themselves once the worst of covid19 is over.

Lack of Streamer Support

One thing I was a little puzzled by was a lack of Streamer releases in the game. Based on past experience and given the great launch, I had fully assumed at least one more Splattercat level streamer would take on the game and give us another bump. But despite tens of people requesting keys on keymailer everyday and my previous outreach not a single major streamer played the game, neither on Youtube or Twitch.

There could be a bunch of reasons for this. There were a lot of great games launching around the same time, like Rogue Legacy 2, so that could have been taking up people’s attention span. I’m kind of mystified as to how almost none of the keymailer keys that we gave out manifested in a sizeable streamer. I’m pretty sure I saw some big names there. I’ve heard some rumors that a lot of the folks on keymailer are actually scammers, but I can’t really verify this.

I feel like telling streamers they’re missing out! Splattercat’s original video is now nearing a 298k views whereas his typical videos bring in 50k-100k. That says to me that all things being equal, Ruinarch has brought Splattercat more views. Come on guys, what are you waiting for! :D

Week 2 Results

I thought it would be good to compare week 1 with a more realistic week 2 result. While obviously a strong start is great, I’m weirdly always in a hurry to see the numbers drop down and normalize so I can have a better idea of how the game will do on a regular, non sale basis. On week two we sold 1518 units, which is around 11% of week one sales. I’m not sure if there’s a lot of data comparing week 1 to week 2 sales but I’d love to see them in the comments.

Looking to the Future

Ruinarch had the kind of launch that hopefully sets up Maccima so that they will no longer need Squeaky Wheel for their next game. I think that is my Platonic ideal of a publisher. The developer should succeed in such a way that they no longer need you in the future.

But in the meantime, we’re still gearing up for future updates. We are expecting the Steam Halloween sale to happen in October. Given the theme of the sale and Ruinarch’s successful launch, we’re hoping we have a chance at a daily deal. Regardless, we’ll be joining the sale and trying to get our ducks in a row to maximize our visibility in the days leading up to the sale, the goal being to try to match or beat our week 1 expectations.

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.

Road to Ruinarch Part 1: Wishlist Gathering and Expectations

Wishlist acquisition and its effects on game launches are a continuously evolving oft-argued topic among indie developers.  Which makes sense, since game launches on Steam can often make or break the long term success of a game and the livelihoods of game developers.

I'm writing this article for the purposes of tracking the wishlist acquisition process for Ruinarch and making our own contribution to pulling back the curtain and revealing more information about the business of games. I will also be making a bold and probably foolish prediction about how well we will do on Launch week. 

As a quick refresher, my name is Ryan Sumo, and I am a cofounder at Squeaky Wheel, a Philippines based indie game developer currently working on Academia : School Simulator.  Last year, we signed a contract with Maccima Games to publish their Evil Overlord Simulator, Ruinarch, which is launching on August 25, 2020.  Let’s begin!

Pre publishing announcement  March 8 2019 to October 20 2019

Daily wishlist average: 7 Total wishlists in time period: 1422

This period covers the time before Maccima and Squeaky Wheel were involved.  Starting from March 8 to October 2019, Maccima was doing its own marketing efforts for the game and netting a respectable 1422 wishlists in the process.

From Publishing Announcement to Steam Festival Oct 21 2019 - June 15 2020

Daily average: 11 Total wishlists in time period: 2318

This period covers the time in which Squeaky Wheel formalized its involvement with Maccima and Ruinarch.  The initial announcement got a small burst of interest, but eventually faded away. There is a 57% increase in the daily averages from 7 to 11 wishlists a day.  Our internal target was 6000 wishlists before launch, so we were a couple thousand wishlists away.

We hired a PR company called Indie Bros to assist us with PR.  I primarily sought them out because they had worked in promoting Rimworld, and since we were talking up Ruinarch as the “anti-Rimworld” I thought they’d be a good fit.  In general they helped quite a bit with checking out our tags and store page, but really I was investing in their network with streamers that had played Rimworld, which did pay off in the end.

Steam Festival (June 16 - 23)

Daily average: 48 Total wishlists in time period: 308

We were very excited to join the Steam Festival because we hoped this would take us to the 6000+ wishlist point. Sadly the sheer number of entries in the festival meant that we were buried in the crowd. While there was a small boost, it was hardly enough and did not really carry over

Before Streamers (June 24 - August 8)

Daily average: 21 Total wishlists in time period: 878

We’re quietly worried, calculating that if we maintain our progress we’ll hit 5000 wishlists but still be short of our target. I pour some more money into reddit ads (about $60 daily on selected subreddits) and it does pay off a little bit. A rough estimate would be we got a 1 wishlist for every $2.50 we put in. In retrospect this seems terrible. We do get a lot of impressions this way which may be worth it in the end? We were also more active on Discord thanks to our new hire Shannelle, who has been doing an excellent job of managing the channels.

Leading up to launch our plans are to send out a build to select streamers 3 weeks before launch and open it up wide to all streamers 1 week before launch. We were hoping that this would have some impact.

Streamers Ahoy (August 9 - August 24)

Daily average: 1565 Total wishlists in time period: 23,111

On August 9, SplatterCatGaming posted this video of Ruinarch.  On that day our wishlists shot up by 2891, and while it decline after that, it averaged more than a 1000 wishlist per day since that point.  This is where working with Indiebros really paid off.  While splattercat MIGHT have picked up the game on his own without us working with the Indiebros, I’m fairly certain that having them do the outreach for us helped. Other medium to large streamers like Arch and Dr Horse soon followed suit. 

Separate from Indiebros we did our own outreach to folks who had played Academia : School Simulator, and every day since that first big video by Splattercat has seen me looking up new Streamers and sending them keys (I should have prepared this beforehand, but I was also busy running our company and project managing Academia). 

We were also part of the Yogscast Tiny Teams Festival, which was a great stroke of fortune. However it’s hard to tell how much of an impact it had given the event happened at the same time content creators were picking up the game.

On Friday the 21st we hit the front page of new and upcoming. I would say we were probably at around 20k wishlists at that point. Getting on the front page of new and upcoming did have a positive effect, but the effect may have been buried by other factors that seemed to be pushing our wishlists upwards, so I’m not entirely sure how much to credit it. I did notice an increase in “Home Page” visits in the Steam marketing graphs, so that might be related?

Why Names and Words Matter

One thing that I want to make clear is that I think that the guys at Maccima did a really great job with Ruinarch. They pitched the game as a story generator, knowing full well that content creation is storytelling, and they were banking that this would entice content creators and entertain their players.  I’d also like to think we did a good job with the rebranding.  Initially Ruinarch was called “World’s Bane”, which, while kinda cool in a JRR Tolkien kind of way, just doesn’t sound like a game from 2020.  We workshopped a lot of different names (My early favorite was Mendaxarch, can you imagine?!?!) and finally settled on Ruinarch as a cool and unique name, and we have to give credit to Jakub Chilaber for helping us with a really kickass logo. 

The game description was also very crucial. Initially Maccima had pitched the game to people as an Evil Overlord Simulator. We all agreed that calling the game an Evil Overlord Simulator undercut the really cool art and style of the game, but it was decided that we would use that in all of our marketing material.  That means that on our Steam page, on the Ruinarch Website, and our pitches to streamers, we always led with the sentence “Ruinarch is an Evil Overlord Simulator…”.  We also dropped hints in the description and in our marketing that it’s “like Rimworld but you’re the bad guy”. Why is that important? Well for one thing it entices streamers because it’s that old advertising adage of offering something that’s similar, but different. And two, Youtubers are using those cues in their titles, which I suspect draws people’s attention.

So what does all of this mean? It seems like the combination of name, description, and cool logo are helping videos of Ruinarch outperform videos of other games by the same streamer. For example, check out these videos by Splattercat:

Notice that with the exception of “Going Medieval”, Ruinarch has more views than most of the other games within a +/- 1 week time period.

You can also see that with smaller streamers like Geek Cupboard:

Notice that most of his videos average around a thousand views, but his Ruinarch (Evil Overlord Simulator) video has 6k views.

So for whatever reason, videos of our game are generating more interest than videos from other games (even those with a much larger marketing budget for big name publishers). Taking the time to craft your name and marketing descriptions may seem like a waste of time initially, but it can pay off in very weird and unexpected ways.

Future Plans and Bold Predictions

After the initial flurry of activity we’re doing a soft embargo of videos until launch day, in order to maximize eyeballs at the point where players can throw money at us.  We’re also taking advantage of the fact that we now have 3 games under the Squeaky Wheel label. We’ve added Ruinarch to our complete the set Squeaky Wheel Bundle, and timed a sale and visibility boost for both Academia and Political Animals to coincide with the launch of Ruinarch.  The idea is to maximize every single opportunity to get Ruinarch in front of Steam users.

So now we’re at the end and we can do the fun part where I predict how many sales we’ll have in our first week! Jake Birkett’s original boxleiter number of 1st week sales equalling 0.5 of wishlists has been modified by Simon Carless’ updated stats. So given we have 28000 wishlists as of this post, here’s my predictions for week 1 sales:

Pessimistic Launch : (0.075 of wishlists) 2100 units

Realistic Launch : (0.25 of wishlists) 7000 units

Optimistic Launch : (0.5 of wishlists) 14000 units

I’ll be back in a week (or a month) to let you know how it went!

Covid-19 Relief Sale Documentation

Hi all, we recently did a covid-19 relief sale by selling Academia : School Simulator. The amount raised was about $250 (thanks to everyone who bought the game during the sale!). There’s a lot of people in need and a lot of work to be done. So we decided to supplement it by adding $750.  We’re sharing this so folks know where their money is going. This crisis is only beginning, and as it progresses the team will discuss how much more we can do to contribute. Thanks again, and stay safe, stay at home, and wash your hands every hour or so.

Recipients:

Lockdown Cinema ($100/5000PHP)

Your contribution will help provide provisionary cash allowances to our fellow Filipino film workers during the Community Quarantine put into place by our government. Feel free to buy up to 10 "tickets" depending on how much you wish to contribute.

Open House ($100/5000PHP)

During difficult times like these, we rely a lot on artists to help us get through. From shows to stories, music to dance, art helps us get by. But these difficult times also mean that artists need us to help them get through, too. It’s time for us to give back to the community that gave us so much joy, memories and inspiration.

The COVID-19 lockdown caused thousands of Filipino freelancers, performers, designers, technicians, and production staff to lose their jobs, projects, and income. They are a special type of worker that escapes the protection of the public sector and are very much vulnerable. They face an uncertain future in the coming months, due to shows being cancelled or postponed indefinitely. 

Emergency Quarantine Facilities for COVID-19 Patients and PUIs ($200/10000PHP)

WTA Architecture and Design Studio has been called on by the Philippines Marine Corps to provide services of constructing quarantine facilities for their frontliners who have been stationed in several checkpoint locations since 15 March 2020.

With this, the teams behind WTA and the Anthology Festival collaboratively designed an emergency quarantine facility to help house patients and reduce the load on the hospital. To fully implement the design, WTA tapped different industry experts and lead innovators to create the EQF Team.

To know the design and infrastructure details of the Emergency Quarantine Facility (EQF), click https://www.wtadesignstudio.com/eqf

Life Cycles ($200/10000PHP)

Public transport is suspended, but doctors, nurses, and grocery and drugstore employees need to get to work. Many of them don’t have cars, and their only alternative is to walk.

Our plan is to pair up with hospitals, groceries, drugstores, and LGUs and help their frontliners get to work.

If you have an extra bike you can spare or lend, or cash (one bike is approximately Php 5,000.00)—we promise you that we’ll get it to a frontliner in need. Helmets and locks are also welcome!

Kaya Natin! Movement for Good Governance and Ethical Leadership presentsA Donation and Fundraising Campaign for Health Workers Fighting COVID-19 ($200/10000PHP)

The Kaya Natin! Movement, in coordination with the Office of the Vice President, is organizing a donation and fundraising campaign for personal protective equipment (PPE) and care/food packs for health workers and frontliners fighting COVID-19.

Each PPE Daily Set Ticket consists of one N95 mask, one gown, two sets of gloves, two pieces of head covers, two sets of shoe covers and one pair of goggles. This is only good for one (1) health worker. Each Food and Care Pack Ticket will help one health worker/frontliner per day.

A Donation and Fundraising Campaign for Health Workers Fighting COVID-19 in Iloilo ($50/2500)

Global Shapers Community Iloilo, in coordination with the Kaya Natin! Movement for Governance and Ethical Leadership and the Office of the Vice President, is organizing a donation and fundraising campaign for Personal Protective Equipment (PPE) Daily Sets and Personal Protection sets for health workers and frontliners fighting COVID-19 in Iloilo.

Project Compassion (Cebu PPE) ($50/2500)

In partnership with V-Day Cebu and Fight Like a Girl PH, 2TinCans Philippines has organized a fundraising campaign for healthcare workers and frontliners fighting COVID-19. Donations received will go towards buying and shipping essential supplies such as masks, gloves, and protective wear for frontline workers in Metro Cebu. Your donation is greatly appreciated in our effort to support our community, and those that support us.

Care For Children Bidlisiw Foundation ($100/5000PHP)

A FOOD SUBSIDY donation drive for the families of children in need of special protection, who are greatly affected by the COVID-19 crisis. Beneficiaries are from the urban poor communities of Cebu City, Mandaue City, Lapu-Lapu City, and Camotes Island.

Bidlisiw Foundation, Inc. takes care of marginalized families with children in need of special protection. These families, who belong to the informal sector of society, are currently undergoing healing, recovery, and reintegration programs.

At this time when enhanced community quarantine is imposed, our family beneficiaries suffer. The daily wage earners’ livelihood is directly hit by closure of businesses, while the self-employed have limited opportunities to continue with their economic activities.

How to do Project Management for Remote Teams

The current situation with the covid-19 coronavirus has opened up a general conversation about the future of work and working from home.  Squeaky Wheel has been essentially working from home since it started, only meeting twice a month for some face to face interactions and team bonding time.  Because of this, the imposition of the Metro Manila lockdown has not created major changes in how we run our team.

What I will be sharing here are some specific details about how we run our development team of 5 (I’m not including our CFO who handles all the bank and payroll transactions for us since that would make this too long) while working on Academia : School Simulator.  While some of this may mostly be useful for similar sized teams working in game development, I’m hopeful there are lessons that larger teams or those in different fields can pick up and adapt to their own purposes.

You Need a Producer/Project Manager

If there is only one thing you will take away from this is that you need to assign a producer role to someone on your team.  Producers are much maligned in the game industry as people who don’t really “do anything” yet manage the people who actually “do the work”.  

When Squeaky Wheel started out we had this mindset. We would set tasks for ourselves and then just work separately throughout the week.  It was a recipe for a lot of wasted effort as we often not working in sync, with designs being made months before they needed to be implemented, and mechanics that were being implemented lacking  design. It created a lot of mental stress for me, and the only reason we managed to keep going was that each individual was working hard as hell, including sometimes on weekends.

After taking on the role of producer myself, we’ve managed to make it so that we mostly work in sync and no longer work on weekends because we’re much more efficient about how we do things.

This belies a lot of “invisible labor” by the producer, who must navigate the fine line between knowing what is happening in the team and if we’re on schedule versus simply micromanaging everything.  Think of the producer as a director, a symphony conductor, or a basketball coach. Their role is to try to make sure that everyone is in sync for the betterment of the whole team.

Ideally you would have a full time producer, but if not, one of the team members needs to step up and really embrace this role. 

Setting Milestones

While this blog will cover what the week to week management of a team looks like, ultimately none of this works unless you all know what you’re aiming for. For Squeaky Wheel, what we’ve been doing is breaking our development up into milestones.

Here is what our milestone for “Alpha 4” looks like, which I can share with you since we are nearing the end of this milestone.  I won’t go into too much detail about how we arrived at these mechanics and time estimates since that would take up an entire article of its own.  

But here are the basics of making your own milestone timeline:

1. Decide what mechanics you want to add to the game (this is its own complicated process unless you have a genius designer/producer that holds all decision making power)

2. Ask for time estimates for each mechanic (rule of thumb, whatever your team says, assume they are overconfident and add a day or two).

3. The producer then arranges the milestones into scheduled updates, trying to make sure that there is just enough work to be done for each update.  For our case, since Alpha 4 milestone started, we’ve been organizing these updates into “themed updates”. We try to have at least one key mechanic or a series of related mechanics to anchor the update.

Then after that, everything goes fine and you just work till you complete the milestone.

Haha just kidding.

Throughout development the producer needs to keep an eye on this timeline, checking in at the end of every sprint to see how far along the team is with their work, and if anything needs to be adjusted.  You’ll notice that there are quite a few mechanics that have a delayed marker next to them. Depending on the situation, these mechanics have either been delayed for future updates or the team has decided they’re no longer necessary. There will also be times, especially if you’re in Early Access, that you will realize that certain mechanics must be added that you didn’t account for.  That is where it is crucial to have a producer that can discuss these issues with the team and make the necessary changes to the schedule.

Sprinting to Success (or Less Failure)

Each themed update is broken down into sprints.  Sprints have a very specific definition in Agile methodology, but we’ve taken what we need from it and are adapting it to our needs (as you should do with these suggestions).

Sprint and update length should be decided by the producer, depending on the needs and capacity of the team.  As for Squeaky Wheel, over time we found that the one week sprints we were doing were far too short to allow enough breathing room in between working on bugs and working on new mechanics.  

Similarly, our updates used to be spaced at one month intervals.  This was necessary early on in Early Access to give players the sense of continuous development.  However as we built trust with our community, we decided to announce to the players that we would be releasing updates every other month instead, and it’s been much less stressful for us overall. To review, our previous work schedule was 4 one week sprints per month, whereas now it’s 3 two week sprints per one and a half months.

Adding Up the Days

Each sprint begins in the previous sprint with a sprint review which is done via Flock (more on that later). I allot myself one day at the end of each two week sprint to chat individually with each team member about how work is going. I will review tasks that are unfinished or pending. I will ask if there Is there anything slowing them down, anything they want to discuss, etc.  I will then assign them new tasks on HacknPlan (more on that later) based on the schedule and their available time. 

This is where the time estimates you made previously come in handy. While this is not a hard science, ideally we make our estimates in days, as in “it will take me x days to complete this task”.  Since we have two week sprints, that means we have 10 workdays in each sprint. Basically the sprint review is the producer playing time management tetris for each team member, allocating them enough estimated work for 10 days.  

The producer needs to allocate time for unexpected occurrences.  For example since our game is in Early Access and is actively in development, bugs reports come in on almost a daily basis. So for our programmers I make sure to allot time for 8 days worth of work, assuming that 2 days will be taken up with bugfixing.  Our lead designer has also been tasked with community management, so I allocate 1 day for that across the entire sprint, assuming he will spend at least an hour per day doing that (we assume 8 hours = 1 day).

It is important that the sprint review be done before the start of the next sprint so that everyone is ready to begin on their tasks.  This works for our dev team of 5, and depending on how good your team and your producer are, it may scale up to 10 people. Beyond that you would likely need to organize in such a way that there are lead programmers/designers etc who handle the people under them while the producer coordinates with the leads.

Communicating Throughout the Week

The start of each sprint is where we typically do our actual face to face meetings.  We reserve space at a coworking space and meet there for the day to discuss any major issues that can be more easily facilitated through face to face interactions.  We also have lunch and sometimes dinner and boardgames together for team building and morale boosting.

Since we’ve decided to cancel even these once a week meetings, we’ll start doing these discussions on Flock as well.  For easy dissemination, almost all our documents are now in the cloud using Google Docs, so everyone can look at the doc while we are discussing the topic at hand.

During a regular day, we start things off by announcing to the team what we’re working on for the day.  This allows the producer to see if everything is in sync, and if not, communicate directly with the team member that they should start working on something else instead. This process repeats until the team gets to the end of each sprint, then the end of the update, where we release a new update of our game to the world.

Conclusion

Looking back on what I wrote, it actually seems like all of the stuff I mentioned above could just as easily be done in a real life office.  It’s just that in a real office you can kind of compensate for any misjudgements by running from one person to the next and plugging in holes.  I don’t claim for this to be the best way to work completely online, but it is what has worked for us. I hope it helps you, and if you have any suggestions about how we could do things better please drop us a line!

Appendix : Tools we Use

These are tools we use to work online which did not fit neatly into the structure of the article above. I wrote a previous article about this before which may have more useful information.

Project Management : HacknPlan

Once again this deserves its own post so I won’t deep dive into this topic.  But as a frame of reference the project management tool we use is called HacknPlan.  It is specifically made for game developers, and I have found it very useful for our needs.  We used to use Trello, then JIRA, both of which many people use to manage their teams. However for our purposes I found that HacknPlan is the easiest tool to simply jump in and start project management for game development, whereas the other tools would need a lot more tweaking.

Company Chat : Flock

I plan on writing about online communications with Flock at some point, but here are some basics. Make sure you have designated channels for different disciplines, and for major mechanics.  This makes it less confusing when everyone is chatting at the same time so that you know what you’re talking about. Never assume that the other person you are talking to knows what you are thinking.  Whereas in real life we can point to someone’s screen and make hand gestures so they know what we’re talking about, communicating with text requires extra thought. Flock has tools like video calls but we tend not to use those because of low bandwidth.

Time Management : RescueTime

We use Rescuetime to monitor our personal work use, but we don’t use it to monitor employee work time (I’m personally uncomfortable with doing that).  But it can do that if that’s how you want to manage your team.

Documents and Spreadsheets : Google Docs

All our documentation is on Google Docs.  This makes it instantly shareable, and we can easily comment on parts of the document that are unclear to us.

Version Control : Sourcetree

(this section written by our lead programmer Marnel. For more of his insights, read his blog)

For version control, we're using Git hosted at Bitbucket. We use Sourcetree as our Git client as we are not really good with the command line, even the programmers. As for managing the branches, we have a main branch called "develop" where commit/push rights is only granted to Marnel. To make changes, other team members are required to create a separate branch which is named after the task ID based from HackNPlan. These branches are branched from the latest from develop. When the task is marked for code review or for merging, Marnel reviews the changes in the branch and merge them if they are safe. If not, the task is returned to the owner for further revisions. This is repeated until the branch is merged.

We also manage other branches like release and hotfix. The "release" branch is used by Unity Cloud Build. Sometimes the develop already have changes that are not meant to be released yet. This is why a separate release branch is used. This is also the reason for hotfix branch.

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 wishlist Ruinarch.

Squeaky Wheel's 2019 Year in Review

Squeaky Wheel started off 2019 on very shaky ground. The Steam algorithm change of 2018 had severely impacted our sales, leading to sales figures of less than 65% compared to earlier in 2018. This predicament lasted into early 2019. We had little choice but to soldier on, updating the game on our regular monthly schedule and hoping that things would turn around eventually.

Another Algorithm Change, Steam Labs, Deep Dive

On September 2019, Steam released another algorithm update that seemed to be more beneficial to us, (though it must be noted that it negatively impacted other devs). They also started reminding players to leave a review for games they'd played, and our review scores are now comfortably at 75%.

On top of that, Steam also added the Steam Labs and Deep Dive discoverability tools in order to help players find games that they may not have known before. All of these things helped to bring our monthly sales figures closer to what they were in early 2018.

Climbing Out of the Dreaded Mixed Reviews Valley

Steam clings to the party line that Reviews don’t matter to sales, but anecdotally every developer is terrified of falling into the dreaded “Mixed Reviews” category, when your game reaches 69% in average reviews or lower. Our consistent updates improved the game and we slowly clawed our way back up to 70% and beyond.

Steam also quietly added a feature where they ask players to review/change their review after having played the game for a certain amount of time. I don’t know exactly how it works, but ever since they made the change, the number of reviews for Academia has increased appreciably, and luckily for us most people have left good reviews. As of this writing, we’re sitting at a comfortable 75% positive reviews.

Publishing Ruinarch

Our cashflow had stabilized enough that during the third quarter of the year we made the announcement that we were publishing am evil overlord simulator game called Ruinarch (Wishlist NOW!). I wrote more about why we made that decision here, and even shared our contract details in this blog post.

The Maccima team is working on Ruinarch full steam (here’s their latest update) and we’re hoping to launch by mid 2020.

New Team Member and Collaborator

Early in the year, we hired Marica Uchida to help me handle the nitty gritty stuff related to running a business. This allowed me a lot of freedom to focus both on improving processes in the team as well as exploring business opportunities, like the Ruinarch Publishing deal. Without Marica I would probably have lost my mind many times this year, so her additional was very well timed.

While we were at our favorite local game conference, ESGS, we met a lot of cool people, but most notable Jin, who is working on a game called Lawmage Academy. When I noticed that the Lawmage Academy Twitter account had twice the number of Academia, I know that A) we needed help with social media and B) I had found the right person for the job. So we contracted him to help us manage our social media on a freelance basis, and we’re excited to see how that turns out!

Slowly Working Our Way to The Finish Line

Most of 2019 was kind of a boring grind to be honest. We spent the time with our shoulders to the grindstone, slowly working on and improving Academia : School Simulator in the game that we all know it be. All of this work will hopefully come into fruition in 2020, as we’re actively working towards a version 1 release of the game.

Thanks to the team for continuously pouring their heart and soul into the game, the players for playing, giving feedback and bug reports, and everyone else that has supported us this year. 2020 is shaping up to be an exciting year!

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 wishlist Ruinarch.

What Does A Healthy Publisher/Developer Relationship Looks Like (With Real Contract Details!)

Squeaky Wheel and Maccima Games teams celebrating the contract signing. Will the happy times last?

Publisher and developer relations have always been fraught with peril.  There is a natural imbalance that occurs when a much more experienced entity with capital deals with a financially naive developer that wants to put their art out into the wider world. Recent news has borne this out, as I have heard of another publisher mistreating or wilfully misleading a developer.  The point of this article is not to name and shame (and honestly, depending on when you actually read this, I could be referring to an issue from 2019 or from 2022), but rather to show what a healthy publisher/developer relationship can look like. I will also be providing actual contract details for Ruinarch (wishlist now!) to serve as a datapoint, as I believe information asymmetry is one of the key issues that leads to developers being taken advantage of.

First off, let’s define our terms.

Publishing

A publishing deal is one that first and foremost provides funding.  For absolute clarity, I will refer to any deal that offers no money as “distribution” which I will describe later. I am aware that others may disagree with my definition, but I believe it is important for developers to hold that distinction in mind. 

Aside from capital, a publishing deal typically also offers knowledge sharing and advice.  This means advice regarding all aspects of game development, from programming to marketing.  This is most useful for a first time developer, but even accomplished developers derive value from having a new set of eyes on their game.

In exchange for capital and information, a publisher will typically ask for profit sharing based on revenue generated after they recoup their costs. Basically, since they fronted the money, they want to be assured that at the very least, they will be able to recoup the risk that they took spending that money in the first place.

This profit sharing agreement can take many forms.  For example, the publisher could ask for a 75/25 split on revenue until they have recouped their costs, and thereafter the split is 50/50.  For our own deal with Maccima (as I’ll discuss later) we get a 100% recoup first before splitting the deal 70/30 in favor of the developers.

Distribution

A distribution deal is one that provides no funding, but basically provides marketing and distribution support in exchange for revenue.

I am personally quite wary of distribution deals.  The up front money from a publishing deal establishes “skin in the game” for the publisher.  As a developer, I am also more appreciative of the up front money because it immediately takes a lot of the risk off the table and lets me make the game without fear.  A distribution deal feels to me like I have taken most of the risk by making the game on my own, then someone is going to come in at the tail end of the process and take some of my hard earned revenue.

However, to paraphrase Shark Tank , “70% of a hundred thousand dollars is better than 100% of 0 dollars”.  There are many reasons why you would want to take a distribution deal:  

1. You are a developer that just hates everything to do with marketing and money and you want to hide in your room and code all day. 

2. You trust the people behind the distribution deal, and they are up front with exactly how much money they are planning to spend on marketing (this shows skin in the game).

3. You already have an established game and want to expand to a market that you are not familiar with, like China or the console market.

These are all valid reasons to accept a distribution deal.  As a developer you will have to make the hard decisions about whether or not a deal is suitable to you.

First Contact

Publishing deals can take a long time to negotiate, and there is a lot of wooing that happens even before the first draft of the publishing deal is presented to you.  Before we secured a deal for Political Animals, I had written on and off to Positech Games about the possibility of a publishing deal. Cliff brushed me off the first few times, but I eventually wore him down (politely, mind you), and in a meeting at EGX in 2015 where I presented him the current prototype of the game sealed the deal.

I first noticed and reached out to Maccima Games on February 9, 2019.  Soon after, I visited them to try to get a better idea of the team and how serious they were with the game.   I broached the idea of possibly publishing the game, but also told them that if they wanted to try for a bigger publisher (eg Paradox Interactive), I would use my digital rolodex on their behalf and try to secure interviews for them.  Early on I already established that no matter what happened I wanted to help them succeed, which helped to build trust between us.

The Pitch Deck

A few months later I invited Maccima to an invite-only PC dev session with some other local devs, where we would get to show each other our games and give each other advice.  I chatted with Marvin, the head of Maccima, to get a sense of where they were in development. I explained to him how much money in the bank we had, and how I’d approach a publishing deal.  He told me that they were still interested, and were now preparing a pitch deck for publishers in general. 

I have written about what should be in a good pitch deck before, and Maccima’s pitch deck nailed the most important parts.  It was solid, and their expectations were reasonable. Most importantly, the amount they were asking for was something that we could afford.  After reviewing our finances with our COO (wherein we definitely answered the question of whether we could afford this risk), we decided to offer them a contract.

Here is a link to Ruinarch’s (formerly World’s Bane) Pitch Deck, with financial data removed as requested by the developer.

The Contract

Finally, here’s the main event, a copy of the contract in place between Squeaky Wheel and Maccima Games. One of the nice things about being a small indie dev/publisher is it allows us to share things like this without dealing with a large bureaucracy. I made sure to ask permission from my cofounders as well as Maccima games, and would not be sharing this otherwise.

It’s important to note a few things. This is not meant to be an example of the “best” contract, merely an example of an actual contract.  What works best for us may not work for you. The point is to negotiate until you are comfortable with the contract.

This document is a copy of the original, with personal details, dates and actual dollar amounts removed. I have left the comments in to show that this contract was crafted after negotiation between the two parties.

In the following paragraphs, I will discuss some of the key parts of the contract that you should pay attention to when negotiating your own.

Sales and Rights

Sections 3 to 7 cover what the rights of the publisher are with regards to the game. For example, we wanted exclusive and worldwide rights to sell and publish the game on PC/Mac and Linux, extending to DLC. We have right of first refusal for any ports or sequel, but if we’re not interested, then the developer is free to shop the game around. It’s made clear that all business transactions must go through the publisher.  So for example, on the off chance that Epic Games (ahem) wants to throw a bunch of money our way, they would be dealing with us, not the developer. As a courtesy to the developer they would be included in any discussions, but its important that there is only one point of contact in these kinds of decisions. There are also numerous protections for the developer, such as stipulations that we cannot create sequels, ports, or DLCs without the agreement of the developer.

Royalties and Recoup Rates

Sections 8 and 9 deal with the numbers.  These sections get very detailed, and explain how much of the royalty goes to the publisher, how exactly those number are derived, and how the money will be transferred to the developer. There was a lot of clarifications involved in this section, as you can see from the comments. To protect the Developer, they will be given direct access to financial data (which we can do with Steam).  In absence of that, we promise to share documentation of funds received.

Termination

This is maybe one of the most fraught parts of a contract, but also one of the most important.  A publishing agreement is a relationship, and like all relationships, it can go sour. This section stipulates what should happen in that rare case, and it can be the key to an amicable separation or a messy divorce. There was also a lot of discussion here, but the basic agreement is that we can terminate the agreement if the developer continuously misses milestones.  The developer can terminate the agreement if we continuously miss payments. 

The most interesting part of this is subsection e, which states:

e) The Publisher agrees that Developer cannot be held liable for delays due to acts of god, sickness of key staff, and other events beyond Developer’s control.

This is something that the developer asked for specifically, and which I agreed to immediately.  While we’re all in this business to make money, we must also remember that sometimes life happens, and we have to make room for that possibility.  

Negotiate, Negotiate, Negotiate

If you leave this article with only one lesson, it is that you should negotiate. Contracts can be changed. There is no such thing as a one size fits all contract.  It is the publisher’s best interests to not have changes made, because each change requires lawyers, which cost money. Any change in the contract may also affect their contracts with other developers, and so the costs cascade and increase.

But as a developer you must be comfortable going into this relationship, so if there is anything that really jumps out at you that you feel is unreasonable, ask for it to be explained and if necessary, changed.

Conclusion

We are not presenting this contract as the perfect contract by any means.  In fact I suspect that the contract will be picked apart by developers, publishers, and especially lawyers for various reasons. Ruinarch is also still in the middle of development, so things can still go sour.  We have already agreed with Maccima to extend development because the initial time estimates were a little too tight. Here’s hoping that we will still be friends come next year.

Our goal is that having this out there can help prepare other devs and prospective first time publishers manage their expectations and offer at least one data point for what an actual contract looks like. We also hope that both developers and publishers understand that at the end of the day, this is a relationship, and both sides need to make sure that even as they look out for their best interests, they must take the time to make sure they are on the same page.  The best contract in the world cannot fix a bad relationship, but a contract dispute can be fixed by two people sitting across from each other and negotiating in good faith.

Thanks for reading, and hope you found this useful! If you want to support us, please wishlist Ruinarch.