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.

A Response to Cliffski's 10 Tips to 10X Your Indie Game Development Process

Recently the noted indie curmudgeon Cliffski wrote a lengthy blogpost about how to improve your indie game development process, for which he received a lot of unfair criticism from the internets. A lot of this abuse was unwarranted, and I want to take this opportunity to respond to show people that you can disagree with someone without necessarily hurling abuse at them.

NOTE: It is rather cheeky to do this, but Cliffski published our first game, and by now we’ve known each other well enough that would call him a friend (although this may put that to the test!)

Tip #1 Stop fucking around with ‘fun’ disguised as work

Reading reddit is not work, unless its 100% actual new, informative, well-reasoned and argued and productivity or sales-boosting information directly applicable to indie game development on the platform/genre combo you work in

Cliffski takes aim at “useless” activities disguised as work, like reading reddit, playing indie games, and watching youtube let’s plays. While I agree that hunkering down and actually working is the key component in any endeavor, not just gamedev, there is a lot of value to wasting time. I can say this as someone who tried to devote himself to making sure every single day of his life was planned perfectly so as not to waste a minute of time.

There is a supermarket near my home that charges me 30 Pesos (about 75 cents) if I park there for more than 15 minutes. I have planned my grocery shopping such that as soon as I enter the parking lot I have already pre-mapped my route through the grocery story to pcik up everything I need in order so that I am out by 15 minutes. When I miss this arbitrary deadline I get pissed off. I tried to spend the rest of my life this way and it drove me (and my wife) crazy.

There is huge value in making an efficient use of your time. But there is also value in giving yourself a little bit of slack to enjoy stuff, play some games, and read through things. It’s impossible to know ahead of time what will be “100% actual new, informative, well-reasoned and argued and productivity or sales-boosting information” so you need to give yourself time to explore. Sometimes this means time will be wasted, and we need to be okay with that.

Tip #2 Work somewhere quiet

cliffski’s hyperbaric chamber

a coffee shop is not quiet. Nor is any room in your house/apartment where other people walk through regularly. You need to be an end-zone where people only enter your room if they need YOU.

I mostly agree with Cliff here, although to a certain extent this is dependent on your personality. There is some value to be gained from having white noise around you. When I was still exclusively a freelance artist and would often spend hours painting or creating art, I would have a podcast in the background as it genuinely helped me concentrate. This is hard to do if you are writing either code or just plain old text, as the same brain functions are triggered by hearing people speak and actually writing things down. This is because we generally “talk” to ourselves in our head as we are writing, so hearing someone speak at the same time can be jarring.

Ultimately its the being interrupted part that is jarring. So what I’ve done is to try to have the best of both worlds. I work from home in a personal office (really it’s our second bedroom where I have been graced with the use of a corner). To simulate white noise I use a couple of websites:

1. http://rainycafe.com/ : does what it says on the tin. two toggles and a volume control for rain and cafe sounds.

2. Air traffic control + Ambient vangelis-like sounds : This is my personal super weird combo. It makes me feel like I’m in a sci-fi movie.

3. Any “lo-fi hip hop” playlist on Spotify

I have gone over the deep end before and wasted too much time trying to find the “right” white noise, so just pick a sound that you enjoy but can easily ignore, and start working.

Tip#3 Get a big monitor, get 2 big monitors. Don’t feel bad if you have 3.

Three is a bit excessive, but sure, why not. More screen real estate means more information. Too much information can lead to distraction though. For folks with laptops who want a portable solution, this AOC 16-inch usb powered monitor has been an absolute godsend for me.

Tip#4 Shortcut keys and batch files etc

Zero arguments here. I have made shortcut keys for Photoshop for this very same reason. Any time spent learning shortcut keys is repaid 100 fold in the long run.

Tip#5 Comfort

When it comes to my office, no expense is spared. If you are an indie developer, your desk and office chair are probably more important to you than your car, TV, cooker and sofa combined. You will (hopefully) spend a lot of time in that chair at that desk. Get a really good one. try many, the really good ones will last a while. Mine is an aeron, 9 years old, still perfect. I actually had a desk made for me (surprisingly cheap actually), It will last forever. Do not make false economies here. Mine was about £800. Thats under £100 a year so far for the place I park my ass most of my life.

YES, YES, ONE HUNDRED TIMES YES! This makes more sense for older devs who have to deal with more joint and back pain as they age. But no matter what age you are, buy the most comfortable equipment you can afford.

This includes beds btw. I’d been dealing with some back pain for a very long time and going through a bunch of chairs to find the perfect one. Turns out my main problem was our old bed mattress that I had inherited from my parents. We bought a stiffer mattress and my back pain improved tremendously.

Tip#6 Mindset

Do not surround yourself with well meaning people who tell you what you want to hear. Thats a route that spirals down and down into insular failure and disappointment.

It’s almost impossible to respond to this because it’s so rambling and I have an image of Cliffski in his bathrobe yelling at the gamedev kids to get the fuck off his lawn. But I’ll tackle the point about surrounding yourself with people that tell you want you want to hear with a story.

Someone who used to be a friend of mine asked me to take a look at his 3d animation because he really wanted to get into gamedev. I took a look, and the animation, such as it was, was an object moving from one end of the screen to the other. I told him good job, but tried to explain that animation was a lot more complex than that, and gave him tips and links to improve. He left in a digital huff (this was over chat) and never asked me about animation again. He never became an animator.

People need different things to be able to thrive in their careers. Some need more support than others, and that’s ok! We can’t all be workaholic maniacs like Cliffski. But a certain amount of grit and persistence is needed to see any endeavor through, and if you give up after one well meaning criticism? I don’t have much hope for you.

side note: I have been trying to learn Japanese on and off for about 7 years. I am still pretty fucking terrible at it. But I am committed to learning it.

Tip#7 Focus on one thing well

If you are good at making 2D RPGs, make 2D RPGs. Unless you have three years salary in the bank, and a lot of confidence, and are absolutely MISERABLE making those games, do not change. Every 2D RPG you make improves your skills, your experience, your audience, your engine, your productivity and your tool-chain.

There is a lot of truth to this. Mastering your craft takes a long time. If you keep making the same kind of game you can reuse some code and learn to discard things that are unnecessary. But it’s also good to be good at other things. Cliffski is a good guitarist as well as businessman. I am primarily known as an artist, but recently my work has tended to be a little bit of design, business and marketing as well, and I’m a mentee at Weather Factory learning how to be a producer. I can never say that I am a master of any one thing, but I’m happy being a jack of (many) trades.

Tip#8 Seek out harsh but real criticism

Do not insulate yourself from the negative. negativity can lead to change, improvement and accomplishment. Data about what you are doing badly is absolutely essential in improving. If nobody ever tells you your games art direction is shit, or your game title is stupid, you will never improve it. If you *absolutely* cannot cope with harsh, hurtful criticism, then you probably should not try to make a living from indie game development.

I 100% agree. This goes back to the idea of having the proper mindset. You cannot get better if you do not seek criticism. Eventually you will learn to filter useful criticism from trolls, and how to extract value from criticism without taking things personally.

Tip#9 avoid chances for distraction

I used to use rescuetime. I also used to use an hourglass to focus myself on work. I now find I need neither. I’ve worked so hard, so long, I’ve internalized what they used to do for me. Most people aren’t at that stage, and they get distracted. if your phone distracts you from work, switch it off. Nothing will explode. We survived thousands of years without mobile phones, you will be fine for entire eight hour stretches. You don’t need twitter during work hours, you don’t need to check the news sites or reddit during work hours

This tip also rambles off into other stuff, but I’ll tackle distraction. I 100% agree with this. Remember that social media throws billions of dollars at engineers in order to trap you in their site, and MAKE YOU LIKE IT. I have taken the following steps to try to reduce distractions:

1. Added a website blocker to keep me from accessing social media during work hours

2. Also use rescuetime to preiodically track my usage

3. Turned off almost ALL notifications on my phone, with the exception of messenger (coz sometimes friends and fam contact me there).

This has improved my productivity and well being immensely, and I highly recommend it.

Tip#10 Avoid bullshit productivity planning admin

Some peoples reaction to stuff like this is to immediately start planning to be more productive. they will start a productivity planning spreadsheet, with nice formatting, some color-coding and even a company logo

This is where I will take the most issue with Cliff. Essentially it’s an argument for just getting to work and not worrying about the planning. This is fine if you are a single developer and answer to and only coordinate with yourself and a freelancer. This is absolute suicide if you are a team of 3 or more people (unless you’re synced, Pacific Ri style). The Squeaky Wheel team is composed of hard working individuals. But often times we are not working efficiently and in sync because we’re each doing our own little thing very well. This creates a lot of wasted time and stress for me personally, because I always felt that something was wrong and we were not being efficient. It also creates stress for the individual worker because when work isn’t properly planned, you have the eternal feeling of “if I’m not working, I’m slacking off”. As I mentioned in the first tip, this can be absolutely terrible for your mental health (if you’re not a workaholic robot like Cliffski).

Endless planning and bad meetings can be a waste of time. But taking a team and just assuming that everyone working hard will be “good enough” is a recipe for disaster. I have spent the past few weeks working with Weather Factory’s Lottie Bevan to improve my producer skills, and I’m already feeling a lot better and experiencing a lot less stress. In fact, I just spent most of today planning out the next couple of months for the team, and I feel great!

Conclusion

There are a lot of good points in Cliffski’s blog, and a lot that I disagree with. It’s good to have a conversation about it, and at the very least it makes a good starting point for figuring out what works for you!

Thanks for reading, and hope you found this useful! IIf you want to support us, you can by checking out Academia : School Simulator, buy the game now! If you're not ready to buy, please sign up for our mailing list, join the Facebook group, follow us on Twitter, or subscribe to our Youtube channel and help us spread the word!

Squeaky Wheel's Productivity Tools

As game developers, we can get so focused on the craft of game making that we can sometimes forget that the tools we use outside of actual game development can be just as important to the process. Having the right tools can make the team much more productive, so knowing which tools work best for your team is key. Here I will go over some of the tools we’ve used previously, and what we have replaced them with to better suit our needs.

From Hipchat to Flock

As a mostly virtual studio, having a good way to communicate online is absolutely necessary for us. When we first started developing Political Animals, company chats were still in their infancy, and Hipchat was one of the early companies providing this service. While Slack was around, Marnel preferred Hipchat because it had a much lighter chat client. Turns out the reason for this was that Hipchat was an incredibly primitive chat client compared to today’s updated products. It became very frustrating to use Hipchat during long chats, when it was unclear to whom we were replying to in conversations. We ended up creating our own systems for this, like copying and pasting the message we were replying to, as if we were on a forum.

Our Scheduling, aka “Today’s Bowel Movement” channel on Flock.

So we were kind of amazed when we switched to Flock and all of its functionalities. The ability to reply to specific messages, create reminders and notes, and being able to create custom avatars for people and rooms just blew me away. It felt like the difference between dial-up and broadband internet, or SD vs HD. Once we switched over there was no going back.

Flock over Slack

The leader of company chat clients is Slack. You almost can’t get away from slack advertising when listening to a podcast these days. In some ways this turned me off on Slack (I like rooting for the underdog). However we did try out Slack and some other products for a little bit just to see what it was like, and we still came back to Flock. The reason? Flock offers basically the same service as Slack, with a much more generous free version. They offer double the storage space (10GB) versus Slack (5GB) which means we have a lot more wiggle room when attaching files in chat. I’ll write a more in-depth article in the future, but I highly recommend Flock for small teams.

From Jira to HacknPlan

Jira has long been hailed as the gold standard for agile project management. What they don’t tell you is that for it to actually be useful, you need an actual full time project manager, or someone who is committed to that role. Unfortunately for us, we do not have anyone who is able to fully maximize Jira and all of its integrations. Vanilla Jira is, at least in our experience, painful to use. Basic things like looking up previous sprints consume way more time than necessary. Their strict adherence to the sprint methodology also created some annoying things like not being able to easily delete tasks (something that they added eventually). I was ready to move us off Jira as soon as I found a suitable replacement.

Hacknplan is agile project management created specifically for game development. It’s hard to immediately explain why Hacknplan is better than Jira for our needs. The easiest way to explain it is that while a good project manager could probably create amazing functionality using Jira, HacknPlan lets teams without a dedicated project manager just hit the ground running.

My favorite thing about HacknPlan is its GDM, which is essentially a living game design document. Previously, I would often want to write down some game design ideas for future reference. I would put them in Jira’s backlog, and there they would remain for the rest of their lives. HacknPlan’s GDM lets me create a category or folder containing all of these design ideas, and lets me easily access them in the future when we’ve run out of tasks and need something new to work on. The best thing is that you can assign tasks directly from the GDM, meaning there is a direct connection to your daily work tasks and the higher level design, which is something that is lacking in most agile management tools. HacknPlan has some issues (the pricing tier and some limits on the free version can be a little annoying), but the benefits far outweigh them. I’ve become quite an evangelist, and will push HacknPlan onto any developer within earshot. I’m going to write a much more in-depth post about HacknPlan and how we use it in the future, but if you are a small team making a game, I absolutely recommend you use HacknPlan.

From Google Sheets to (Sometimes) Airtable

Google Sheets is a great all around spreadsheet app that you can access from almost anywhere as long as you have an internet connection. It doesn’t do anything special, but in the hands of an expert like our designer Tristan, you can make magic with it.

Airtable is an app that lets you do some of that magic and much more without a lot of effort. It feels a little like Spreadsheets 3.0 (with Spreadsheet 1.0 being the actual paper spreadsheets), adding functionality to spreadsheets that can make them much more easier to parse at a glance. For example, while designing our research items, we decided that they would be arranged like a tree, with some items being unlocked by research a “parent” item. Noting down the parent of a research item in a spreadsheet is easy enough, but hunting down items with the same parent can be a chore, even if you take the time to color coordinate the cells properly (which can be time consuming in itself). With Airtable, it only takes a couple of clicks to instantly rearrange and group the data by “parent”, which is a godsend when we are doing internal QA to make sure that everything is working properly in the game. Even better, you can parse this data by grouping it according to two different fields. So for example I could organize the data by way of parent and research cost, allowing me to know which research items that have the same parent cost the same amount.

Airtable’s complexity is also what makes it annoying to use sometimes. For example, coloring a cell is something that anyone who has used a spreadsheet does on a regular basis. I often do this when I want to indicate that a specific task is done, by highlighting it in green. Airtable’s free version doesn’t let you do this seemingly simple task, meaning if I want to do the same thing, I would have to create a new column, assign it as a “checkmark” type of field, and us this to check off items as I finish them. So while I highly recommend that studios use Airtable and its immense capabilities (of which I feel like I have only scratched the surface), sometimes good old Google Sheets is more practical to use. Luckily Airtable lets you import CVS files so if you start out using Sheets and deciding to move to Airtable, the process is painless.

Bonus Tools : Bug Reports with Google Forms

We currently use Google Forms as a bug reporting mechanism. While it’s great and importantly, free, I have been wishing we could switch to a different service that was better at parsing the data we receive. It’s great that Forms links seamlessly with Sheets, but all that data can be overwhelming to comprehend.

I’ve done a little research into alternatives like Surveymonkey, but I’ve yet to see anything that would be exactly what we need, which is an affordable bug report website or app that parses out the bug report data in more understandable chunks. If you have any suggestions, please let me know in the comments!

Bonus Tool 2 : Rescuetime

We are a small team and we don’t do the typical time tracking expected in a virtual team. This probably won’t scale to a much larger team, but in general we’ve noticed that we tend to work longer hours than usual anyway, so asking people to time in and out just seems insulting.

Instead, we suggest that people download Rescuetime and track their productivity on their own. It’s a great free tool that helps you keep track of your computer time. We’ve found that most people are usually shocked at how little productive time they actually use during the day, and this helps give them an incentive to do better. The free tool lets you set goals (mine are to have at least 4 productive hours a day and to spend less than 30 minutes on social media during work hours) and is more than enough for the average person.

Conclusion

I hope this will be useful for other devs and studios out there to give them an idea of the tools that they can use to help make the process of making games a little bit easier. It’s important to note that these are the tools that work for Squeaky Wheel specifically. The best thing to do is to always try it out for yourself and see what works best for you and your team!

Thanks for reading, and hope you found this useful! If you're interested in Academia: School Simulator, you can buy the game now! If you're not ready to buy, please sign up for our mailing list, join the Facebook group, follow us on Twitter, or subscribe to our Youtube channel and help us spread the word!

Drawing Inspiration from a Global Community of Game Developers

I've opined before that I think game conventions are a net negative when it comes promoting or marketing your game. If it's a consumer focused event, then player feedback can be valuable. There is an infinitesimally small chance that press or streamers will find your game and help it blow up. But I think many games have proven the digital age it is very possible for you to succeed without participating in game conventions at all. But that's a topic I'll go deeper into for another day, as I've yet to give it enough thought to write anything coherent.

So what value is there in attending conventions? Why did we bring Academia : School Simulator to Bitsummit this year? Well for me, the best thing about game conferences is meeting fellow developers from around the world and hearing their stories. In where political and ideological divisions are becoming more and more stark and divided, it's more important than ever to build bridges and get to know each other better. So here are some stories from Bitsummit, with all the specific details brushed out to protect people's identities.

Note: a reminder that I am from the Philippines, which hopefully helps give context to some of what I say.

Indonesia

Three of my formative years were lived in Jakarta, Indonesia's bustling capital. This year at Bitsummit I met a few awesome young game developers who are really making waves both locally and around the world. We compared notes on whether Metro Manila or Jakarta was the worse city ( I decided it was a tie) and how linguistically interesting it was that even our slang words were sometimes similar (The slang for women's breasts is “dede” in Filipino, while it's “tete” in Bahasa Indonesia). We hoped to one day be able to grow the regional industry to the point where we could have our own GDC, aspirations we shared with a Singaporean dev that joined us for lunch.

In between dick jokes (remember how I said they were young?) they mentioned that they had read my article about publishing games in China and how that had shaped their decision to seek publishers there. Hearing these stories really affirms that the time I spend writing these blogs is worth it.

Just a day after the event, the news about a suicide bombing in Surabaya shocked the Indonesian nation. I've always had close ties to Indonesia, but now having made these new friends, I feel their pain even more intensely.

Denmark

Drinking beer by the riverside is one Bitsummit's most time-honored traditions. I had a conversation with a Danish developer about old age in the game industry. He's pushing 40 and a little worried about it, and I was happy to have a conversation with someone older than me about my fears of aging.

I asked how he felt about the influential Danish architect Bjarke Ingels and he said that while he doesn't agree with everything Ingels does, it's kind of nice that he(Bjarke) is a larger than life personality coming out of a country and region that prides itself on the Jante Law (tl:dr living a modest life is A-OK). I agreed that it's good and necessary for certain people to be able to stand out and make their mark in the world and hopefully improve it. But he agreed with me when I said it's also important not to worship these people or require everyone to aspire to be like them.

He talked about how he owns a gun and hunts in the Danish countryside, but that he can't wrap his head around American gun laws. I just shook my head sadly and mentioned how disappointed I was that some people on our forums seem really eager to have school shootings in our game. I have a standing invitation to call on him and his team if we ever visit Copenhagen.

South Africa and Germany

There is something about bi-racial couples that really makes me happy. It's like my view of the world being interconnected and everyone being equal is encapsulated a relationship between two individuals, and it's a beautiful thing. One such couple was staying in the same guesthouse as us, and we had a little conversation over breakfast. There was a disagreement about how we felt about doing game conventions:

South African : I don't know what you're talking about, I get so pumped doing conventions, I'm fucking ready to go! *stretches and flexes
Me and the German : Ugh, get out my face.

Brazil

I met a Brazilian game developer who is living in Japan. I approached him because we were both building simulation games, and we talked about the difficulty of explaining and showing a simulation game in a convention that tends to favor loud, quick to play action oriented games.

We had a couple too many beers at the mixer, and it became clear to me that with each increasing beer he began to progressively bring out his grab bag of spoken languages and accents, which led to two awkward/hilarious moments:

Ukranian : Hey, I'm from the Ukraine.
Brazilian : *something in Russian!
Ukrainian: That is Russian, but I forgive you.

Third Party : These guys are from Australia!
Brazilian : *something in ridiculous Australian accent!
Australians : …

A couple of beers later (perhaps we should have stopped, but they were free) I brought up the current situation in Brazil and he went on a passionate defense of Lula da Silva and how the charges against him were trumped up. The short argument was that yeah, the left was corrupt, but at least they did some good things. The right will just destroy everything!

I should end this by saying I think he's a really lovely person, but when we meet him next time maybe I'll tell him to slow his roll with the alcohol.

Japan

I tried out a Japanese developer's game and I really liked it. We alternated speaking broken Japanese and broken English to each other, and I encouraged him to shop his game to publishers so that he finds a wider audience. I pointed him out to publisher that I knew, and then proceeded to take one of his flyers over to said publisher.

Me: Hey have you checked this game out?
Publisher : No, what is it?
Me: *explains game
Publisher : Oh awesome man, thanks for this, (you're) always looking to help others out.

Canada/USA

I met a lovely couple living in Canada who were both game designers. We discussed the difficulty of calling their spouse their “partners”, especially in the context of a game exhibition where a partner more often means “business partner”.

One of them brightened up when I mentioned we had made Political Animals. Apparently she had really loved how it took certain risks by showing that politicians were just people responding to incentives. I told her that it really warmed my heart to hear that, especially since the game was a financial flop. She said she thinks it's well known in game designer circles because she hears it being discussed a lot. This is the first I've heard of that, but that certainly made my night.

We talked about how we were both so in love with Japan and were trying to figure out a way to settle down there or just live there for a few years, and how it sucked that Japanese immigration and residency policies made it really difficult to attract people here.

I should say I’m actually quite picky when it comes to my friends, but it was one of those wonderful moments where I felt like we instantly connected and would have been best friends had we lived in the same area.

Last Conversation : Iran

We shared a table space with a couple of Iranian developers. I had given them advice on how to get to Kyoto via Tokyo through email, and it turns out we shared the same guesthouse as well. We shared our extension cord with them, and before we packed up and left I had a quick conversation with one of them:

Iranian : Hey, thanks for being good neighbors and sharing your extension cord with us
Me: Oh no problem, its's really nothing. I uh...good luck with those economic sanctions I guess?
Iranian : *Sigh These fucking politicians.
Me : I know right? We just want to make games and get along!
Iranian : Exactly!

Note: I understand that this is a rather naive statement and obviously having made a game about politics we believe in some sort of political process. It does get frustrating sometimes that people on the ground can be friends while their leaders bicker with each other.

These are only some of the many conversations I had in Bitsummit. I left feeling a little more energized and connected to the world than I had been for a while. It's important to hunker down and build your games. But making games in isolation can become lonely and disheartening, and sometimes it's good to reconnect and feel like you're a part of a larger, global family of game creators.  Here's to next year's Bitsummit!

Bonus Conversation : China

While in line at the airport I tapped a guy on the shoulder because his bag was wide open and the contents looked ready to fall out. He was very appreciative and friendly, and we chatted a little bit while in line. Turns out he's a Chinese businessman with “many businesses” in many countries and doing “distribution”.

Chinese : I distribute cleaning implements
Me: *excited Oh! Like vacuum cleaners? (excitement context: I love my Dyson vacuum cleaner)
Chinese : No, like liquid cleansers
Me: *hiding disappointment Ah.

Since he was friendly enough I offered him by business card before we split up, and he offered his in return while his girlfriend nodded approvingly (she was very keen for us to exchange contact info). When I looked at it, his business card was an “invitation” to join Amway. He texted me afterwards thanking me again for reminding him about the bag. Needless to say, I will not be responding to any and all further texts.

Thanks for reading, and hope you found this interesting! I'd like to take this moment to say you get get Academia : School Simulator now! If you're not ready to buy, please sign up for our mailing list, join the Facebook group, follow us on Twitter, or subscribe to our Youtube channel and help us spread the word!

Lessons Learned From Two Game Launches

A little over a year ago I wrote a rather depressing blog post about Political Animals' launch. You can read it in full if you like, but the bottom line is the launch was a major flop despite the fact that it was featured on Steam's front page. Indiepocalypse aside, a front page feature should still have assured us a enough views to break even. It didn't. Academia : School Simulator, on the other hand, did well enough to ensure that we could continue development into the foreseeable future. In fact, despite not receiving any features from Steam, Academia : School Simulator sold almost 3 times as much as Political Animals in the same time period.

Why was that? Since we're talking about first day sales, I posit that it cannot be the actual quality of the games that mattered. Because if Political Animals was simply a bad game, what we should have seen was a flood of purchases based on that front page feature and then a subsequent amount of bad reviews, returns, and refunds. Instead, what we saw was people finding our steam page and then immediately deciding “nah, I'll pass”.

I realize now it's the months leading up to launch day that matters most.  I'm going to describe and differentiate what we did for Political Animals and Academia : School Simulator with the hopes that you can use the lessons we learned for your own game launches.

Social Media

Political Animals:

This was a social media failure. While we had a Website, Blog, Twitter and Facebook accounts where we would post sporadic updates, we weren't showing anything that the players could engage with. This was our fault. Cliff from Positech would push us to do video devlogs, but we would demur from lack of ability/time. This shot us in the foot at launch, as we had not built up the requisite trust and awareness from our target market for a good launch.

Academia : School Simulator

We did a MUCH better job this time around. We decided from the beginning that we would do youtube devlogs. So as soon as we had a primitive prototype that we could show off, we started doing devlogs. They were really bad at the start, but you can see the improvement in the devlogs and the game as time moved on. We had a very strict once a month devlog rule, even when we had little to show for the month aside from polishing the game for launch. While we didn't get hundreds of thousands of views, we had an active community that was asking questions and sending suggestions, excited for every month's update.

For every devlog, we posted it on Twitter, Youtube, and our Mailing List. There was a great feedback loop where at the end of every month we would see our Mailing List numbers increase.

We've been a bit negligent on the Youtube side since launch, something I'm going to rectify at the end of the month. The honest reason is that these videos are exhausting and take up a huge chunk of time to work on. So at the end of an exhausting dev month, the last thing any of us wanted to do was to make a video of our progress. But they're the touchstone of our outreach to players, so we need to get back on it.

Conclusion

It's important to have a good, consistent media plan and follow through on it. Start as soon as you can, especially if you know you have to build up trust and create a community around your game.

Steam Store Page

This was a fail for both launches. Aside from filling up the requisite store information (which by the way takes a hell of a lot of time) we essentially did not do anything with the store pages before launch. This is a huge mistake. Like it or not, many gamers are treating Steam as a one-stop shop for their gaming information these days. So there will be a lot of people ending up on your Steam Store page that will never have heard of you before or seen your Twitter, Facebook, or Youtube account. So if they end up at your store page and there have been no updates since yo made the store page live, it will look empty, and emptiness breeds mistrust.

This is even more important for Early Access games. Because so many people have been burned by Early Access games before there is a huge hurdle of trust that you have to overcome with skeptical players. In fact, some people on our Steam discussion boards for Academia wrote saying they initially thought we were scammers because of the similarity to Prison Architect and the fact that there were no updates. The worst thing is we only saw this comment days later, making us look even more suspicious! It took us a few days to gain players' trust by sharing all of the devlogs that we had previously made on Youtube and establishing a track record of development.

Conclusion

The lesson here is that once you publish your Steam page you have to start treating it as another social network that you have to manage, if not the most important social network. An active Steam store page assures players that developers are legit and communicating with the playerbase, which gives them more confidence in the game

Conventions

Political Animals

For Political Animals we went to quite a few conventions, the most important of which were PAX West and EGX in the UK. We got some good press out of it, with Eurogamer even giving us a small writeup as one of their “Best of EGX”. We met some cool players who were super into the game, and it gave us hope that we were on the right track. Sadly, it turns out that this was not the case. We spent a lot of time and energy going to conventions around the world, but I think that money was essentially wasted, especially since for Academia we didn't even go to a single one.

Academia : School Simulator

Aside from our disappointment with the results from Political Animals, the easy answer for why we didn't go to any conventions is simply because we had nothing to show yet. We were way too early in the dev process to be showing it off.

We did go to a convention, but only to a local one in the Philippines called ESGS. While ESGS is one of the biggest gaming conventions in the Philippines, it pales in comparison to PAX and EGX. We also went there post-launch, meaning we already had a game we were selling and could sell to attendees at a significant discount. We also had a free booth courtesy of indiearena, and we wanted to support the local game industry and meet our peers while we were there.

As with Political Animals, it was great to meet the players of our games, and we even picked up some local press. We also found out later on that we'd been nominated for a local industry awards, and even ended up taking home best game! So there's certainly a lot of emotional value to be gained from doing conventions, but don't go there expecting to boost your sales.

Conclusion

There are many reasons to attend conventions. Meeting players and fellow devs, getting feedback from them, and just enjoying the experience of seeing the other games. PAX was a whole lot of fun when we didn't have to man the booth. But our experience is that they are not very good value for money.

For ourselves, I think we will only go to conventions if we can get a subsidized spot, like with the Indie Megabooth, or even a free booth as with ESGS or Busan Indie Connect. We'll only go if we already have something to sell, so that we can subsidize the cost of travel. While some devs may find value in the cons, there are many devs that completely avoid them as a policy (Rimworld's Tynan Sylvester and Zachtronics for example) but are still successful studios. That's the model we want to emulate moving forward.

Streamers and Press

Political Animals

We reached out to streamers and press a week or so (memory fails me) before launch. I think we gave press a headstart just because it takes them a little longer to write an article, but that was the gist of it. We got some pretty big streamers on board, the biggest of which was TotalBiscuit. It was amazing watching him stream the game. Unfortunately I think it was a mistake to share the game a week early. By the time the actual launch rolled around, interest in the game had dissipated. Every second between the initial impression and clicking to buy a game is crucial. Bigger studios can rely on marketing right before the game's launch to help cover for this, but for a small studio it can be the kiss of death.

Academia : School Simulator

This time around we were adamant that we wanted to close the gap between first impression and game purchase. We released keys to press and streamers a few days before launch with a loose NDA that basically said “We are releasing this to you early so you can familiarize yourselves with the game, but please release your content only after the game is available for purchase. Otherwise you will receive a long, heartfelt email full of disappointment from me.” There were one or two outliers, but for the most part people stuck to the NDA.

Just to tie this back to social media, one advantage of doing those early youtube videos and spreading the word early was that we got youtubers emailing us asking for access even after our first devlog. So they were primed and pretty pumped to share the game by the time we finally released the keys.

For Academia we used a combination of both Keymailer and Woovit, so people could choose what they felt most comfortable with. Email or Twitter was a last resort, but we would ask for some verification before we would give out the keys to avoid the inevitable scammers.

Conclusion

I realize now that I didn't really write too much about press. That's because for the most part, press outlets hold much lesser sway now than then used to. I would suggest picking out the most important one for you and sending out a personal email, then crossing your fingers.

Build a marketing strategy that will inevitably attract Streamers and press to your game. Release as close to launch as you can to maximize day one sales. Cross all fingers and toes.

Timing

Political Animals

We launched Political Animals on November 2.  This was awful timing because A) It was a terribly fatiguing election (The US election in 2016) and people were sick of it and B) November is a very heavy month for launches, and we were sandwiched between some really big attention grabbers.  We had no choice with this as we could not have launched any earlier, and launching AFTER the US elections might have been even worse.

Academia : School Simulator

We consciously went for a September launch.  Our actual target was August but we needed just a tiny bit more time so we settled on September 8.  There was less of a crowd when we launched, and I think we came out the better for it.  We also had the benefit of three successive sales (Halloween, Autumn, and Winter) coming one after the other, where people are primed to buy new games.  We carefully set the discount to 10% so as to be part of the sale but not undercut the value of our new game's release.

Conclusion

The general rule for indies is to try to launch around February or August because those are the quietest months of the year for launches.  Given the number of games coming out every day on Steam this rule is rapidly losing currency, but I would still advise you to never try to launch in the October to December window because you will be facing up against studios with huge marketing budgets that will drown you out.

Final Thoughts

We learned from the mistakes we made with Political Animals and applied them to Academia : School Simulator. While it wasn't the best launch in the world and I'm sure we could have done better, we did do well enough to keep the lights on. In these dark days of the Indiepocalypse, that's already quite a feat.

Thanks for reading, and hope you found this useful! If you're interested, you can buy the game now! If you're not ready to buy, please sign up for our mailing list, join the Facebook group, follow us on Twitter, or subscribe to our Youtube channel and help us spread the word!

7 Tips for Aspiring Game Designers

Last week, we introduced you to our game designer Tristan Angeles (That's him on the left, with our programmer Marnielle) and his path to becoming a game designer. There was so much interview content that we decided to break it up into two parts. If part 1 was about his path to becoming a game designer, then part 2 is about practical tips for aspiring game designers.

1. Learn how to code

Or at least learn the basics of coding so that you can understand what the programmers are talking about. Knowing how to code also lets you make your own games and join game jams even with ugly programmer art.

2. Read Lots of Books

Read as many books as you can about any topic that you find interesting. Recently I heard a podcast interview with Sid Meier, he said "The challenge of game designers today is to bring things outside of the gaming world into gaming world."

3. Enjoy using spreadsheets

You will be using them a lot when it comes to game economy and balancing. I used to hate using Excel until I of my QA friends gave a workshop on how to use it for games. Since then I've found it to be both an enjoyable and indispensable tool.

4. Join Game Jams

One of the jams I joined was The Experimental Gameplay Project. It happened once a month, and you'd have to think about weird ideas and make games about the month's theme.

5. Learn to Compromise

Always be open to the possibility that you can be wrong. Ask for ideas from your team mates. These are the things I constantly keep on telling myself. Everything you think you know while designing is just your hypothesis or assumptions, and can only be validated once you start playtesting.

6. Find an Experienced Designer and Ask Them Questions

I once bought a book called Challenges for Game Designers by Brenda Brathwaite and Ian Schreiber. I emailed Schreiber to ask how he would approach some of the design challenges I had at Gameloft, and he responded. I think the best advice I got from him was about deconstructing games. He told me when tackling a new mechanic the question to ask was why? Why did the game designer introduce this mechanic? This allows you to make a hypothesis why a certain mechanic was put into place.

7. Watch the Extra Credits Videos about Game Design

These videos were my Saturday morning cartoons when I was getting started. These videos cover a broad range of game development topics from basic game design, to more advanced topics like game economies and balancing.

There was no elegant way to transition between the tips and this last segment, but hopefully it will also provide some more insight into practical game design:

What Resources Were Used While Designing Political Animals and Academia?

Social media was a very good resource when we were developing Political Animals. People would post news on Facebook, and it seemed like there was always something we can use or put in the game as events or a feature. In fact, when we released the game and people were posting about it on Facebook, one of the best parts for me was when people 'got' the game by relating it to things they knew or experienced in real life. For some of the mechanics like concerns, voting and bribing I based the mechanics on how I understood this paper on Vote buying by Eddie Dekel, Matthew O. Jackson, Asher Wolinsky .

Getting ideas for Political Animals I believe was the easy part since the team followed Philippine politics. Also, it seemed then that every person I asked knew something(or was an active participant) or had experience with cheating in elections in their home town.

In designing Academia, I'm trying to keep a balance between using school administration textbooks, and entertainment. I've been watching a lot of TV shows lately about or set in schools. Currently, I'm being entertained by Boston Public, just a few episodes of this series gave me respect for principals. Running schools is a hard job! I've also been watching documentaries about schools so that I can get ideas about the challenges faced by school administrators.

Thanks for reading! You can read more of Tristan's thoughts on his old game design blog (which he unfortunately no longer updates) If you're interested in learning about our latest game, Academia : School Simulator, please sign up for our mailing list, join the Facebook group, follow us on Twitter, or subscribe to our Youtube channel! !

Learning and Using GOAP (Goal Oriented Action Planning) For Squeaky Wheel's Next Game

Ryan: We've been working on a new game the past couple of months and this is the first time we're going to be talking about it.  You can find out more about the game by watching the video above, and then geek out over the AI by reading Marnielle's post below.

I’m excited that we’re making a builder type of game in the likes of Prison Architect Banished, and Rimworld. I love playing such games. Our’s is a school management game where you can design classrooms, offices, hire teachers, design curriculum, and guide students to their educational success.

For every new game, it’s always my aim to try to implement a new algorithm or system and learn something new. I’ve always been fascinated with an AI planning system called Goal Oriented Action Planning or GOAP. If you’re not familiar with it, here’s a simple tutorial. I haven’t developed such system myself as the games that I’ve made so far have no use for it. I think it’s the perfect AI system for builder games. I hope I’m right!

Why GOAP?

The primary reason is I’m lazy. I don’t want to wire and connect stuff like you do with Finite State Machines and Behaviour Trees. I just want to provide a new action and my agents will use it when needed. Another main reason is I’ve reckoned that there’s going to be a lot of action order combinations in the game. I don’t want to enumerate all of those combinations. I want the game agents to just discover them and surprise the player.

Another important reason is the AI system itself is an aide for development. There’s going to be lots of objects in the game that the agents may interact with. While I’m adding them one by one, I’ll just add the actions that can be done with the object and the agents will do the rest. I don’t have to reconfigure them much every time there’s a new action available. Just add the action and it’s done.

Tweaking The System

While making the system, I had some ideas that would make the generic GOAP system better. They sure have paid off.

Multiple Sequenced Actions

Per GOAP action, instead of doing only one action, our custom GOAP action contains a set of modular atomic actions. Each atomic action is executed in sequence. This is what it looks like in editor:

By doing it this way, I can make reusable atomic actions that can be used by any agent. A GOAP action then is just a named object that contains preconditions, effects, and a set of atomic actions.

GoapResult

I incorporated the concept of action results like how it is in Behaviour Trees. An atomic action execution returns either SUCCESS, FAILED, or RUNNING. This is what the atomic action base class looks like:

public abstract class GoapAtomAction {

    public virtual void ResetForPlanning(GoapAgent agent) {
    }

    public virtual bool CanExecute(GoapAgent agent) {
        return true;
    }

    public virtual GoapResult Start(GoapAgent agent) {
        return GoapResult.SUCCESS;
    }

    public virtual GoapResult Update(GoapAgent agent) {
        return GoapResult.SUCCESS;
    }

    public virtual void OnFail(GoapAgent agent) {
    }

}

When an atom action returns FAILED, the whole current plan fails and the agent will plan again. A RUNNING result means that the current action is still running, thus also means that the current plan is still ongoing. A SUCCESS result means that the action has done its execution and can proceed to the next atomic action. When all of the atomic actions returned SUCCESS, the whole GOAP action is a success and the next GOAP action in the plan will be executed.

This concept makes it easy for me to add failure conditions while an action is being executed. Whenever one action fails, the agent automatically replans and proceeds to execute its new set of actions.

Condition Resolver

Condition Resolvers are objects that can query current world conditions which you need during planning. I implemented this as another base class in our system. The concrete classes can then be selectable in the editor. This is what the base class looks like:

public abstract class ConditionResolver {

    private bool resolved;
    private bool conditionMet;

    public ConditionResolver() {
        Reset();
    }

    public void Reset() {
        this.resolved = false;
        this.conditionMet = false;
    }

    public bool IsMet(GoapAgent agent) {
        if(!this.resolved) {
            // Not yet resolved
            this.conditionMet = Resolve(agent);
            this.resolved = true;
        }

        return this.conditionMet;
    }

    protected abstract bool Resolve(GoapAgent agent);

}

Note here that it has logic such that Resolve() will only be invoked once. Concrete subclasses need to only override this method. Such method may execute complex calculations so we need to make sure that it’s only called once when needed during planning.

This is what it looks like in editor:

All conditions default to false unless they have a resolver which is used to query the actual state of the condition.

Usage

Once the conditions, resolvers, and actions have been set up, all that’s left to do is to add goal conditions and invoke Replan().

void Start() {
    this.agent = GetComponent();
    Assertion.AssertNotNull(this.agent);

    // Start the AI
    this.agent.ClearGoals();
    this.agent.AddGoal("StudentBehaviour", true);
    this.agent.Replan();
}

If there are new goals to satisfy, the same calls can be invoked to change the goal(s) for a new plan to be executed.

So Far So Good

Our custom GOAP system is working well for us… for now. I now have working worker agents and student agents. More will be added later on, including cooks, janitors etc. Here’s hoping that we don’t need to revamp the system as we’re already so deep with it.

Thanks for reading! If you'd like to be updated on the latest Squeaky Wheel news, please sign up for our mailing list, join our Facebook group, follow us on Twitter, or subscribe to our Youtube channel! Please let us know if this is something you would be interested in supporting via Early Access!  Any feedback on that would be most appreciated!

How to Playtest Your Game

In this post, Tristan talks about our playtesting method.

The game has finally reached a point where we're ready to show it to the world! Well not yet exactly, but we did show it to a few friends. As any self respecting game designer would know, play-testing a game is one of the more important parts of the game design process. In fact, if there are any doubts about a game mechanic, play-testing it is the way to go. In this article, I talk about how we conducted preliminary play tests for the game, and some of the interesting things we learned during the play-tests.

The Play-testers

First let me talk about the play-testers. Our very first play-testers are a few friends from the game industry who we lured with our charms, err, the promise of free food, and those unlucky enough to sit by our table during the recent Manila Game Jam held at the Ateneo De Manila University(ADMU). Seriously guys we really appreciate you taking the time to sit through the game and answer our questions. Speaking of questions, what play-test would be complete without a play-test questionnaire?

The Play-test Questionnaire

For our first play tests we decided to go for a more general questionnaire, since our primary goal in doing these play-tests is to gauge where the game is in terms of fun, and to see if any problems will arise. As we iterate on the game based on preliminary feedback,  we'll also iterate on the questions, refining them until we're ready to test the game with more people.

Our questionnaire consists of two parts: Pre-game, and Post-game:

Pre Game Questions

The first part of the questionnaire deals mainly with knowing who the play tester is. This is important because answers to the questions will mostly be opinions of the player towards the game. Knowing the play tester will help us later on when deciding how much weight to put on his suggestions/feedback later on. Here are some of our Pre-game questions:

1) Do you consider yourself as a strategy gamer?

2) Please list down at least three strategy games that you have played.

3) Rate your skill as a strategy gamer.(1 lowest,5 highest)

4) Rate your interest in a game about politics. (1 lowest, 5 highest)

5) Rate how clean a campaign you will run.(1 dirty, 5 clean)

Questions 1,2, and 3 allows us to know what the play testers game preferences are which may shed some light on some of his/her Post Game answers later on.  Question 5 is of interest because it tells us how the player plans to play the game ( good or evil) at the start, and later on we compare it to his actual play style.

Tester Plays the Game

After answering the Pre Game questions, the play tester is given a short introduction to the game, the goals of the player, and basic mechanics by yours truly. Afterwards, the player is let loose in the districts of Summer Island to test his political mettle against the opposing candidate. During the course of the game, the play-tester is allowed to comment and ask questions about the game, while we take notes.

Post Game Questions

When winner of the Summer Island elections have been revealed, it's now time for the play-tester to answer the Post Game questions. The Post Game questions deal mainly about the play-testers feelings towards the game. Some of the questions:

1)  How fun was the game? (1 lowest, 5 highest)

2) Which part of the game did you enjoy the most?

3) Which part of the game did you find the most difficult?

4) How difficult is the game? ( 1 lowest, 5 highest)

5) How corrupt were you in the game? ( 1 lowest, 5 highest)

Remember during the Pre Game questions we asked how clean a campaign the player could run? In the Post game questions we ask how corrupt the player's candidate was during the campaign. It was quite surprising and fun( insert evil laugh here) to see that most players ended up being more corrupt than they thought they would be.  But the best feedback was one tester that insisted they would be super corrupt but ended up only being moderately corrupt (wouldn't it be wonderful if more of ouir politicians were like that?)

Play-test Results

First a disclaimer before we present our results. Since we just play-tested with a very small pool of players, results from the play-test are not accurate at all, and should be used merely to present a different perspective on the game. Also, a majority of the play-testers are game industry professionals who have insight into the game development process which may or may not have coloured their reaction towards the game.

The play-testers had an average of 2.78 (skill as a strategy gamer), 3.33 (interest in politics), 2.89 (running a clean campaign), 3.22( corruption), 3.5( had fun), 3.44( game difficulty), 4.17( accurate to political theme).

Aside from the values above, we also received qualitative feedback from the play tests.

Things Players Did Not Enjoy

Too Many Stats to Track

These were game feedback which had keywords like info, and stats  attached to words like Too much or Too many. These feedback seems to deal with the playing having a hard time processing game information hindering them from making decisions during the game.

AI Turn is too Fast

These were game feedback which mentioned keywords like AI, Fast and Quick. These feedback seems to deal with the player having a hard time knowing what the opponent is doing.

Things the Player Enjoyed

Being Corrupt

These were game feedback which mentioned the keywords dirty, bribery, and scandals. The feedback seems to show that the player enjoyed doing bad things in the game.

Dominating Districts

These were game feedback which mentioned the keywords domination, and winning.  These feedback seems to show that the player enjoyed seeing his territory expand visually in the game through the borders of districts he has captured.

Looking Forward To More Play-tests

If you're looking to do a similar process during your own play-tests here's a few things to keep in mind:

• Quantitative data is not useful with a very small pool of play-testers because results won't be reliable. Try using open ended questions in your questionnaire.

• Ask follow up questions. The play-tester rated fun as 4.5? Ask him what kept him from giving the game the full 5 points.

• Always clarify if the play-tester's answer is vague. The play-tester might not mean what you think he means. (at the same team be careful not lead the tester to conclusions)

• Observe which questions the player isn't asking. If there's a mechanic important enough to the game and the player is not asking questions about it, don't assume that the mechanic is clear to the player.

Thanks for reading.  Here's a copy of our playtest feedback questions for your reference.  If you'd like to be updated on the latest Party Animals, please sign up for our mailing list!