What Goes Into Porting To Consoles (for non-developers)

Hi there!

We often get the question about when our game, Ultimate Chicken Horse, is coming to console. A fair question for sure, as the game seems like the perfect fit for consoles. Sometimes people understand that it's a lot of work to port a game, but most of the time people get annoyed because "can't you just sell it on console?". I wanted to write an answer today about what goes into making a game for console, directed at people who aren't necessarily game developers. If you are a game dev, feel free to use this to answer people who ask you.

Setup

The first step is to plug in the development kits and get all the accounts set up so that you can actually use them. This usually requires a static IP address, which you have to set up if you don't have one. The kits also need license keys and need to be properly registered, then you have to (figure out and then) navigate through a bunch of menus to find the spot to allow the console to connect to your PC. If you haven't done it before, this is not a trivial process.

Exporting from the Game Engine

We use Unity, and exporting from Unity to console is meant to be easy. While it's not particularly difficult, you still need to get a special Unity plugin to be able to do this. The Unity plugins from the platform holders (Sony, Microsoft, Nintendo) are often a few versions old, so you need to make sure to roll back Unity to a version that works with the plugin. You'll also need another license key to actually do the export and try to get the game to run on the console.

Platform-Specific Features

Our game was first developed for Steam, and there were many Steam-specific things in the code such as Steam matchmaking, player authentication, version checking, achievements, etc. On console, the game won't even start until all of this is removed. Usually, that means replacing the Steam stuff with platform-specific stuff like achievements that are handled differently on different consoles. Beyond that, there's also the social integration, user accounts, and user interface that needs to be added to make sure that when a player, for example, pressed the Xbox button, they get access to their Xbox account.

Certification

To release on console, you need to pass a certification process. For each console this is slightly different, but in any case it's a list of hundreds of very specific things that your game needs to be able to do. Sometimes these are rules that you need to abide by, other times these are functional features that need to be added. Then, there's a list of test scenarios that you'll need to pass for certification. For example, if you unplug the internet, turn a controller off, switch to Netflix, sync a new controller, plug the internet back in and switch back to the game, will it track the user change and make sure they're still signed in? Things like that. Once you think you've covered all your bases, you send a build to the platform holders and they test the game, and inevitably come back with a bunch of issues that you didn't see. Getting back to you can take a while, and then fixing the issues can also take a while before sending for certification again.

Age Ratings

These are a nightmare that no one wants to deal with. There are different rating systems for a bunch of countries and regions, each with their own governing boards, requirements, submissions and payments. The IARC (International Age Rating Coalition) is trying to simplify this process, but it's going slowly. We have to submit the game to ESRB (North America), PEGI (Europe except Germany), DSK (Germany), CERO (Japan), GRAC (Korea), and more. What's more, in some of those cases you need to do them in the language of the country. For example you can't get an age rating in Japan without a Japanese company, and to launch on Sony Japan you need a rating from CERO. So... not super straight-forward.

Release

Once you've finally done all of this, you need to talk to the console folks and determine a launch date based on other releases that are coming out. You'll want to be slotted in at a time where there aren't a ton of big hyped games coming out to maximize visibility on the storefront. In addition, the more you lean toward exclusivity toward one console, the more they'll try to give you in terms of marketing and visibility. Once you've figured that all out, you can release! 

So, all this to say, that going from PC to console is not a quick process. This article barely scratches the surface of the technical side of porting, and there's a ton more to know about it. I wanted to give an idea of what goes into it though, so that you (the average non-game-developer) understand and also so that game developers can share this as a beginning of an explanation about the difficulties we face and the reason that the port doesn't take two weeks.

We'll keep on trucking though, we're working on it!

Project Management - Diving into the World of Multiple Projects

Today's blog is going to talk a bit about project management and how we're very soon stepping into the world of multiple projects (not necessarily multiple games, but multiple things between which we need to divide our attention). 

Early on in the company's existence, and up until this point, our development has been fairly linear. What I mean by that is that we were always prioritizing features and tasks that contributed directly to the betterment of Ultimate Chicken Horse, our first game. There was still prioritizing to do, of course, and making the decision to add online multiplayer about halfway through the development was a very big (and important) decision for the health of the game and company. 

As far as project management is concerned, this was a fairly simple task. Do stuff as well as possible, as quick as possible, without any real hard deadlines and always trying to make sure the next release has significant improvements (or bug fixes). What we did was we had a big backlog of features and improvements that we pulled from and put into our sprint, as we mentioned in a much earlier blog post. 

Now that we've started work on consoles, and we'll soon be thinking about a next game, we're going to have very different work to do and different tasks to prioritize. This is certainly more interesting and more fun, but also means that we can no longer stick with a single, static backlog and pull from the top of it without worry. The problem with simply having 3 backlogs, say, for UCH / Console / NewGame, is that nothing tells us what needs to happen first and when it needs to happen. How will we know to pull tasks from one backlog instead of the other if the priorities are all relative to other tasks within that backlog?

The solution that we've devised, which is probably standard for many people, is a milestone system that divides the backlog into key milestones. For example, the next milestone could be a new build for the PC version of the game with bug fixes and some new improvements, and the one after that could be console work and getting the game to be playable on them. Each of these backlogs will have tasks within them and will have a due date, and before each sprint, we'll look at how many tasks are left to determine how likely we are to finish before that milestone date. If we see that we have three weeks until the next milestone but we've done most of the tasks for it, we'll prioritize some tasks in the later milestone, or even some bigger tasks two milestones from now. 

So what does this do for us?

• Allows us to work toward small goals (milestones) instead of seeing a huge looming goal 6 months from now
• Allows us to break our work up into different projects in an organized fashion and without forgetting about one project or another
• Simplifies meetings by giving us somewhere clear to put tasks
• Creates a nice mix of priority set by upcoming due dates but also by project, without focusing 100% of our attention on one goal

Project management is something we've obviously done and kept in mind, but as things ramp up and as we start working on several different things that have different requirements, we needed to find a solution to make sure that the work doesn't get messy. We're going to see how this new system works, and see how we feel about the process. Just figured we'd update you and maybe give some inspiration for your own projects... it's not always the most interesting thing, but project management can be an important ingredient to the success of a project!

How We Try to Be Responsive to Our Game's Community

Hi everyone!

This week, I wanted to talk about how we try to be as responsive as possible to the community here at Clever Endeavour, and how we have a few shortcuts that help us achieve this goal.

We don't have other companies to compare to (because we're only working at our company, obviously), but we like to think we're fairly responsive to the community. This includes emails, tweets, Facebook posts / comments, Reddit comments, Discord messages, Steam messages, and any other form of communication. I should mention, by the way, that we always try to have a casual, not-too-corporate tone and that we deal with the community as Clever Endeavour, a fun and silly company-person, or as real individual people (Rich, Kyler, Alex, Ben).

Emails. First off, we have two main emails that can be used to reach "the company". These are contact and support @clevendeav.com, and these help us filter the kinds of emails we're receiving. The contact emails are usually press / YouTuber requests, people giving us suggestions, or people emailing us about (usually not very useful) business opportunities. The support emails are bug reports or issues people are having with the game.

The two of them are treated very differently: contact emails are answered almost solely by Rich, while support emails go into a Google group which is accessed by all members of the team. Still, Rich looks through them and assigns them to other, more technical members of the team if he can't answer them himself. As well as being assigned, these support tickets also have tags denoting if they've been answered, if they need more information from the player, if they need more information from another member of the team, etc. The fact that one person funnels them to the right people however, makes it so that it's quite rare that something slips through the cracks or doesn't get addressed (not necessarily solved, though) in less than a couple of days. 

Twitter is another one of our main forms of contact with the community. It's easy, however, to miss what's going on on Twitter without looking at it all day every day. We use TweetDeck to show notifications, activity and messages but we also have a search which filters for the term "Ultimate Chicken Horse". This allows us not only to interact with people who mention the company Twitter handle, but also the people who are asking generally about the game. For example, "does anyone know if there's a 4-pack of Ultimate Chicken Horse"? Well, responding to that Tweet allows us to connect with that user, and they also will often follow us as a result.

We respond to practically every Tweet that mentions us, even if it's to ask questions which we've clearly answered 6000 times. We also emphasize that silly tone on Twitter... Rich does most of the community management stuff and has been trying to (and continues to try to) establish a personality for the company which interacts like a human would. 

Facebook has been less of a factor for our community. We've put less time and effort into it, and the mentions and followers we have are significantly less than what they are on Twitter. Still, in most cases, we answer to comments that mention the company, and we post regularly on our page. One important thing that we did is turned off direct messages to our Facebook page (which is set 'on' by default). This is super important because it means that people won't message you and feel ignored, they'll simply look at the email on the Facebook page and contact you in the way you want to be contacted. 

Reddit is another good tool for interacting with our community, though it's less constant than Twitter. The big difference is that we'll make posts on Reddit once in a while in a subreddit like r/games, and then respond to the ensuing comments. After a couple of days, however, that dies down and we don't deal with it anymore. On our own subreddit, we answer regularly to things but it hasn't been extremely active. We're labelled as developers so that users can see who we are, but also see our regular usernames and know that they're speaking to a developer and not a hollow corporate personality. A new feature that you'll hear about next week should help make this community much more active however...

Lastly, we have a fan-run Discord where users can look for games, make suggestions, etc. We also have authority to post in the #announcements channel, so we can use that as well to get to our community. Having it be fan-run is a really good way to give the community manager some more time, and also let the community evolve as it should as opposed to forcing it in a potentially wrong direction. 

The most important part of all of this, in my mind, is the speed at which you respond and the voice with which you respond. Our emails, tweets, and every other message we receive or see are responded to with warmth and with purpose, even when those messages are useless or annoying. In the case where they're complete spam (like fake YouTubers), we just ignore them of course. The voice with which we respond is fun, helpful (trying, at least), and that of a gamer who understands how you feel when things aren't working.

Now go out there and tackle some community! We'll try to do the same.