As part of One Game a Month, I’m making a concerted effort to put my games “out there.” Thankfully, there are a whole bunch of distribution websites on the Internets for me to foist my games upon.
For my March game, Hackey: the Hackening, I targeted the following distribution websites and channels, based on information available on the 1GAM website:
It all went pretty smoothly, taking about half an hour for each listing. I kept a mental log of what was required for each website and decided a blog post was in order.
I also wanted to publish to IndieCity, but that is a desktop-only platform. While Unity is more than capable of targeting this platform, I did not want to spend the time creating a desktop version of my app, testing it, etc. So for now, I’ll stick to the above three.
You should have a presence on the web, such as a blog, website, or anything that you can link back to. Many websites will ask for the following:
- Company/team website.
- Personal website.
- A Website or web page for your game.
- Link to a blog about your game or company/team.
- Social media profiles.
You may already have some of this stuff available, but if you don’t, think about creating them.
Avatar pics, screenshots, icons, banners. You need all of them. I found it best to have a nice set of full-sized screenshots and art to start with, which I then resized and chopped to suit the purposes of each website.
Some websites needed tiny icon-sized images, while some wanted full banner-size images to plaster across the top of your game’s page. It’s good to have a good range of screenshots to choose from.
You also need icons and images for your profile in general, so it’s handy to have an image of yourself, or one that represents your team. Failing that, an image of a goat or monkey is always good for a laugh.
This is a broad term that involves the logistics of getting your game into people’s hands.
My game targeted the Unity 3D web player, which is thankfully supported by all the above websites. However, I did spend some time reading the recommendations and guidance of each website to ensure that my game’s display resolution was suitable, given that the game would be hosted within an HTML page.
I found a nice widescreen resolution, 848 x 480, that worked well for my game, and fit well within the websites.
For the Android version, I spent a lot of time reworking the mouse-based controls to work with touch. I think I got lucky in this regard in that my game style worked well with both, because touch and mouse controls are somewhat similar. I think it would have taken longer had I tried to implement support for joystick-style controls, e.g. Xbox.
I also had to change some aspects of play to better work with a smaller (yet higher DPI) screen, but ultimately, I think the changes made actually benefited both web and Android versions. Again, if you plan to deploy to multiple platforms, especially those with different control styles, this is something best done during early development rather than “tacking on” as a feature towards the end.
You’ll need some pre-prepared text to go with your games, which I found boiled down to variations of the following:
- Title – pretty important!
- Tagline or summary – usually a one-liner about your game.
- Description – detailed information on the game.
- Instructions – as detailed as needed.
Again, different websites require different text. But, it’s good to have the above prepared ahead of time.
Publishing your game to these websites takes time, as you must pay attention to the quality of your game’s listing and pay attention to the rules and guidance of each particular website (e.g. your game’s display format, supporting media requirements, etc).
Having experience with deploying business apps to the iTunes and Google Play stores, I knew that deploying and publishing software takes time, so was happy to include enough time in my scheduling. As always though, anything that isn’t strictly code- or feature-related tends to get de-prioritised and left until last; so, mid-way through my project, I made the effort to ensure this area gets attention early.
So, what did I learn?
- Preparation! During the development of your game, keep in mind the media and text that will be needed later on. Make it something you gather and create “as you go”, rather than hurriedly mashed together so you can hit the Publish button.
- Planning! Make sure you leave time to put your game out there. In my case, I tend to work in ~4-hour blocks, so I dedicated one of these blocks to publishing. Looking back, the publishing process actually took multiple 4-hour blocks, as I had to check up on my listings, keep them updated when new versions of the app were available, etc. It turned out to be more of an ongoing process.
- Publishing too early! I published Hackey to Newgrounds as soon as I considered the game “gamey” enough, but it was by no means a finished product. Of the 900 or so views received so far, 700 of these views were in the first few days. I feel that I wasted a golden opportunity to present the best possible product, but on the other hand, the feedback I received in those early few days was fantastic and allowed me to develop features most wanted by the users! So moving forward, I’ll have to decide when the best time to publish is, weighing the two factors.
I expect some further ongoing follow-up work, as more and more people start playing the games. I will need to respond to comments, fix bugs, look at statistics, etc. This will likely be something that I have to include in my scheduling for future projects: something along the line of “support existing games.”
My plan now is to continue developing and publishing my #1gam games and keep an eye on their popularity. I may even experiment with some small marketing campaigns, e.g. with Google AdWords!
The short of all this is that publishing, or getting your games in front of people, is a thing and needs time dedicated to it! for a time frame as short as 1 month, this definitely means sacrificing features for exposure.