1st Months Traffic After Releasing in 5 App Stores

On December 28, 2021 we released Elements of Dreams for free into 5 different app stores: Steam, Itch.io, Apple App Store, Google Play, and the Amazon App Store. We previously covered the varied degree of developer experience for each store. This post will cover how much impressions, traffic, and downloads or plays we got for each one. Let’s dive in:


Originally we were going to launch Elements of Dreams into only 4 marketplaces as Itch.io had the ability to upload for computer play, but after talking with some other members of the gamedev community, who mentioned that traffic for their game on Steam was 10x that of Itch.io, it seemed like a must have. In some ways this turned out to be true, but in other ways not.


Steam had massive impressions with over 700,000 in the first month. These translated into over 22,000 store page views. I’ll pause here to say this was an order of magnitude larger than any of the other marketplaces. Unfortunately though, despite having a free game, the impressions and visits did not translate into game plays. Of the 22,000+ store views we had a measly 33 people download and play the game. This amounted to a terrible 0.15% conversion rate from visits to plays.


Steam is a very unique beast, and many indie game developers have been very successful with them as they provide a lot of marketing included. However if you don’t make the game the way that Steam likes to market it, it is unlikely to be successful in their store.


With Steam charging $100 per game, having a below par publishing experience, and not providing a mechanism to change a free game into a paid game this is a marketplace we would not recommend for other game developers who are initially thinking of offering there game for free and do not have amazing visuals, as we could have put those $100 toward advertising one of our other storefronts and probably had a better return than the 33 players we had with Steam.

Amazon App Store:

As covered previously, the Amazon Appstore is a relatively easy marketplace to publish to that doesn’t cost anything to join. The store seemed like an obvious go to for us as we did our Android testing during development on a Kindle Fire. The traffic that it provided for the game was pretty low though.


Amazon was the one store where you had to pay extra for analytics. As we hadn’t worked that into our budget we ended up not spending extra for it. This gave us zero visibility into the impressions or store views. The one metric that Amazon did provide is downloads, to which we had 5 (the lowest of any store).


The Amazon Appstore is a pretty painless publishing experience, that doesn’t cost anything to join. That being said you need to allocate funds for your own marketing of it in addition to purchasing additional analytics as the store itself doesn’t seem to do that well. Also the reach of it for Android is a fraction of what you get at the Goolge Play store.


Despite being free, the fact that it has limited reach and doesn’t provide much in the way of analytics (that you don’t have to pay for), we wouldn’t recommend spending the time publishing a game here, with the one exception of if you have a large Android app, since they don’t have a limit on the size currently in their store.

Google Play:

The Play Store was an obvious destination for us, as Android is the most prevalent mobile operating system outside the US. This meant that if we wanted anyone to be able to play it on their phones in another country, this would be their obvious go to. The traffic breakdown was slightly mixed.


Despite being fairly data driven, Google doesn’t provide impressions so we had no way to know that for our store. That being said they did provide store page views which were 78, so we knew there were at least that many impressions (though likely more). That being said the page store views converted into 11 downloads for the game, which came to a 14% store view to download conversation. Much better than Steam but not as good as the last two stores.


While the Google Play Store isn’t the worst publishing experience it does have some downsides (as mentioned previously) in that it is not completely straight forward to setup, it does have a cost of $25 (lifetime), and the tech support is sub par. That being said it is a must have if you are planning to release on mobile outside the U.S.


If you’re planning on releasing your game on mobile and outside the U.S. this is a definite yes. If not, it probably isn’t worth the $25.

Apple App Store:

The Apple ecosystem is its own beast, and while it has some oddities to it (for instance publishing through Xcode), from a consumer standpoint it is well known and well respected. It is also the only way to get a game onto iOS, so if you are planning to release for the iPhone or iPad it is a must (if you are just releasing on Mac you have multiple other options).


The Apple App store has great analytic support and not only do you get to see store views, and downloads, you also get things like plays per day and impressions, all included. Additionally Apple invests in making app developers successful by providing documentation on marketing and business models (things that you may not always have front of mind as an indie developer). For us they turned out to be the best mobile store. Impressions were over 4000 in the first month, which translated to 185 store views (twice as many as Google Play), and 38 downloads. This equated to a little over a 20% conversion rate from store view to download. I’ll make a note here that we shot ourselves in the foot a little for downloads as 4 days before the end of the release month we updated the game for a speed run competition and increased the price to $0.99. That effectively killed downloads over that time, and we’ve since made the game free again to bring bring that back up (fortunately Apple makes it so you can change the price of the app without having to republish, unlike some other stores).


Apple provides excellent support for developers through their marketing documentation, tech support, and analytics. That being said they are one of the more expensive marketplaces to publish to coming in at $100 a year, so if you are only planning on publishing 1 game a year or less you may want to think twice before using them.


If you plan on releasing on mobile in the U.S. they are an absolute must have, otherwise weigh the cost to exposure (which from our experience was quite good).


Itch.io is a great marketplace that is very indie friendly with lots of exposure and many features that others just don’t have. They turned out to be one of our best marketplaces.


While not having the most impressions or store page views, itch.io turned out to be our best performing marketplace for plays. From being listed in the new releases the store had over 10,000+ impressions in the first week, from there it tapered off and unfortunately there isn’t a good way to check total impressions via their analytics (one of their downsides). From those impressions we had 685 store views. This translated to 167 browser plays and 10 downloads. This made itch the best performing store with a 25% conversion rate of store views to plays.


There are very few bad things to say about itch.io from a indie developer perspective. For releasing a free game they are one of the best ways to go, especially if you can release a version that is playable in the browser (since they are the only store that supports that). Their analytics are one of the better marketplaces as it updates in real time (where as most other stores you have to wait at least a day). For us when sharing the game through links, social media, or our website we almost always shared the itch store first as it’s conversion rate was so much better than any of the others and it was able to host more versions of the game or provide a way for users to play without having to download anything.


We would absolutely recommend Itch.io. It is free, it provides great additional exposure, it has great conversion rates, and provides a friendly publishing experience.

Releasing Games in App Stores – The Good the Bad and the Ugly

While there are lots of comparison online of game development tools there is very little in the way of comparisons of game marketplaces. With Elements of Dreams we experienced some of the differences first hand as one of our strategies for releasing the game was to allow as many people as possible to be able to play it. As such we released the game in as many platforms and app stores (in our case 5) as possible. Below is our analysis and comparison.


The first thing that we looked at was cost. This varies widely from store to store. From free to $100+ per game. The breakdown here is pretty straightforward:

  • Steam: $100 per game
  • Apple: $100+ ($99 for developer and $10+ fees/taxes) for the year
  • Google Play: $25 for the year
  • Amazon App Store: Free
  • Itch.io: free.
Time to setup:

The time needed to setup each storefront varied for each and often was in direct relation to their user interface. Here is the breakdown from most time to least:

  • Steam: 1+ day
  • Google Play: 1+ day
  • Apple: 1/2 day
  • Amazon App Store: 1 hour
  • Itch.io: 30 min – 1 hour
User Experience & Ease of Use:

After gaining access to build store fronts in each marketplace, the next thing that became apparent was the wide difference in user experiences of each store. These varied from the abhorrent to the divine. Often times I was setting up these storefronts late at night, with little sleep, so if the experience wasn’t intuitive, it was often extra annoying and took much longer. Let’s start with the worst.

Steam: The worst experience for setting up a store was by far Steam. The User Interface (UI) for Steamworks is terrible. It feels old like a Java swing application that was made into a web application. It is bloated with too many menus and no clear simple navigation for smaller games. Simple things such as “how do I even get my store started?”, took much longer to answer than expected. Unfortunately much of the documentation is dated as well so that didn’t help much when setting up a storefront and uploading a game. The one saving grace to the Steamworks UI is a checklist that at least helps you know you aren’t done and provides links to the many varied sub-menu areas that need to be completed before submitting (although even these were not always clear all the requirements that were needed).

Google Play: The next worse store to setup was Google Play. Again the interface to set things up was a little less intuitive (not as bad as Steam, but worse than others). This was mostly due to the left side bar that didn’t have a clear order on what needed to be done when. Google also had inaccurate documentation which made it annoying when looking for guidance only to find the wrong thing. Also certain phrases are not allowed as part of the description (but you won’t hit this issue until the store is under review). Google play did have a checklist which helped for knowing when you weren’t yet done setting up, and linked to that page from the checklist so that was at least better, but knowing how much testing or approval needed to get done to release a game and whether a release date could be set (like in other stores), was unclear. It was often unclear if you were publishing a build or if it was under review.

Apple: Middle of the pack is Apple. Apple prides itself on usability of it’s products and this extends to it’s app store as well. While there a lots of capabilities and extra menus to go down the main workflow to get your app setup was relatively straightforward and I never got stuck when setting up the app. There UI did a good job in telling you when there is something more you need to do, and their documentation was up to date and helped me move along when I wasn’t sure what to do.

Amazon: Amazon was very straight forward interface. There were few requirements for setting up the store, and it wouldn’t let you progress to the next step until you’ve correctly completed the step you were on. While the other large marketplaces could take a day or more to get a store setup, for Amazon it only took about an hour.

Itch.io: Itch.io was by far the best experience. They have many features, but the main workflow for setting up a storefront uses a What You See Is What You Get (WYSIWYG) interface. You could change things and then preview the page as you were working through things which made setting up very easy and fast. They were the only store that allowed .gif files as part of the preview images, which makes for a better way to show off your game. Also after the page goes live you can still go back and change things very simply (this isn’t true for all stores). Itch.io was one of the only marketplaces where you could link to other marketplaces in your store as well, if you have them. Finally the topping on the cake is that you can provide browser playable versions of your game on itch.io store. This is distinct to this itch.io and doesn’t appear in any of the other marketplaces that I released to. All of this made it the perfect link for sharing on social media, those who were interested could play the game in the browser or go to a story that was compatible for the device they were on.

Image Requirements:

Each store has it’s own image requirements many often different than the rest. Of these Apple and Steam required the most images and of specific formats. Steam particularly required a name of your game on images which came out to be more annoying than useful. Google required less images than Apple or Steam, but they had to be from Android dimension devices. Fortunately, I had some friends with Android devices that were able to play the game and send me screenshots for these. Amazon and itch.io required the least images, and as mentioned above Itch.io was the only store that allowed .gifs.

After spending hours in MS Paint modifying image sizes to meet size requirements for each marketplace, I did what any sensible software engineer would do and coded up an automatic solution for myself. This saved me countless hours as I changed out images prior to launch and then shortly after launch once I had received art work from an artist I had commissioned. For others to benefit, I have opened sourced the script that can be found here. To use it place the image you want different sizes of in the directory that the script is in and use python to run it (more details in the README file with the code).

Approval time for store:

Store approval times before and after release varied greatly. I’ll go from worst to best.

Steam: From paying for my product submission fee until being approved for my store front it took 17 days (1 week for approval, 1+ week because of an issue). In addition Steam requires 2 weeks of the store being live before you can release your game. That makes for a total of 31 days before I was able to release my game to the public, despite having everything in place. Additionally they allow you to set a specific date for release but on that day you can’t change the original time even if you’re ready early. I realize that Valve has good intentions here in helping bring visibility to your game before it is released, but dictating the marketing and release strategy of other companies seems a little heavy handed.

Google: Approval time on an app for Google is about 1 week. One thing that was nice was I didn’t have to re-submit the app when the storefront art changed. This could be applied immediately. Google doesn’t allow you to set a release date, but if you know what day you’re releasing this allows you to manually release when you’re ready.

Amazon: Approval time for Amazon is less than 48 hours which was much quicker than the other large app stores (Apple and Google). However the approval process is somewhat opaque and arbitrary, as at one point my game that had previously been approved got rejected for getting flagged on the store description that had been previously approved. This caused some angst as it was close to the release day, but fortunately got it cleared up and re-approved before then. A rejection will cause a delay of an additional 24-48 hours after resubmitting. Also changing something as simple as a screenshot for the storefront (prior to release) will make you have to resubmit everything for approval. Finally Amazon allows you to set a specific release date, but if you’re ready early on that day you can’t change the time. Also it takes a bit of time (a few hours) before your app is able to be found via search from Amazon.com.

Apple: Approval time for Apple’s App Store is 3 business days on average. This can seem a little longer as once the app and store are approved, in order to change many things (including the description, the artwork, or a build) the submission has to get cancelled and then you have to reapply for release. You can set a release day and time with the App Store, but change the release to manual if you are ready early (without having to resubmit for approval), which allowed for more flexibility than other marketplaces.

itch.io: The approval process for itch.io is essentially non-existent. Once you fill out all the details for your store front that you want (there are very little requirements) you can pretty much release at will. Additionally they allow you to preview your store and create secret links to send to collaborators while you refine everything for your release date. This store was by far the best experience.

New Builds:

Releasing new builds on each store is also a varied experience.

Steam: Getting new builds out required modifying an arcane script… or if you have a game under a couple gigabytes then you can do a web upload, but the link for this capability is discrete and in the middle of a random page (and some how absent in the help documentation or any tutorials you find online). Additionally there are file name requirements that are set in multiple areas and it isn’t clear that they are linked. For me this problem manifested as I tried changing the game file name at one point, but all the places that it needed to get changed wasn’t clear so I had to abandon this initially upon release. On the positive side, there is no approval times on new builds once your store is approved, so once you have a new one it can become live as soon as you have them uploaded. So Valve gets a failing mark on ease of use, but good marks on approval time.

Google: Providing a new build for release in the Google Play store has the same approval time of about a week. Additionally the AAB file can’t be larger than 150 megabytes, so once your game gets above that amount you end up having to fork your code base to make an Android branch with reduced assets to save on size, or other space saving strategies.

Amazon: Providing a new build for Amazon is also akin to submitting a new release and has the standard 24-48 hour wait period. This is non-ideal, but uploading the Android APK is relatively painless and doesn’t have any size limits (unlike Google). This is where the issue of my prior approval on my description got rejected though, so there is room for error here when the approval is by humans who apply the rules inconsistently across app submissions.

Apple: Providing a new build for the App Store also the same as submitting a new app and takes 3-5 business days. Fortunately with Apple the approval process appears to be more consistent than it is with other app stores. New builds for Apple are unique as you do them through XCode rather than uploading through a web interface. Fortunately the documentation for this was very straightforward, but it does require you to get more familiar with XCode than you may have been prior.

itch.io: There is no approval wait times on new builds for itch, so when you have changes to make you are able to edit the store, upload the builds, and have them live immediately. Again itch.io wins here for the major ease on user experience and lack of wait time for new builds.

Tech Support:

Inevitably something will happen where you will need to interact with a human in order to resolve issues with getting a game published in a marketplace. The experiences here varied wildly and some went contrary to what you would expect from multibillion (if not trillion) dollar companies. I’ll start with the non-applicable.

itch.io and Amazon: Fortunately both itch.io and Amazon did not require any interactions with tech support. Both marketplaces were easy enough to use and provided enough guidance if something wasn’t working or got rejected that I never needed to contact tech support for it.

Google: Tech support for Google play was by far the worse. I lost almost 10 days trying to resolve an issue using Google’s tech support. Unfortunately here something that could likely have been solved with a phone chat among humans wasn’t able to happen, as Google doesn’t offer phone support for Google play and all tech support happens over email. This at times became idiotic as I got bounced between two tech support groups. Additionally tech support was often sending me to look at help documentation (without direct links) that turned out to have errors and not actually solve my issues. Unfortunately in the end I self solved my problem in a manner that I had been trying to avoid. Google gets a big fat FAIL here which is not what you would expect from a trillion dollar company.

Steam: Tech support for Steam was good. While I never had to talk to someone on the phone the email exchange with an issue I ran into was easily resolved and I was able to continue my store setup without much further issues.

Apple: Tech support with Apple is top notch. While they don’t have a number for you to call, when there is an issue that requires tech support you can set it up to have them call you (usually in less than a minute) and then I was able to solve my issue from talking to that person on the phone. Tech support is really the one area where talking to a person on the phone is extremely helpful and can unblock you quicker than most email exchanges, automation, or documentation can. Apple also have an option for chatting or doing email, but I always opted for a call as I knew that my issues could be resolved by talking with someone on the phone.

App Pricing Changes:

If you initially release your game for free some marketplaces let you change that to a priced game and some do not. Here again it varies and appears to be rather arbitrary. I’ll start with my view of the worst and go to the best.

Steam: Unfortunately once you release your game on Steam as free, you are unable to change it to a paid game later. This wouldn’t be so bad (as other marketplaces have this issue to) except that to release a new game on Steam requires another $100 fee, so this becomes something where it really can hurt you in the long run. There may be ways around this by using a freemium model (and charging for things in game) or releasing DLC’s, but to be honest Steam’s bloated and unintuitive UI has made this an avenue that I haven’t found worth exploring.

Google: The Google Play store is also an unfortunate place where you can’t change the price of your app once it is set to free. With the Play store you could at least release another (premium?) version of your app with a price and not have to spend more money, since it would be included in your original $25 developer fee. So while this is a minor inconvenience it isn’t a deal breaker like it is with Steam.

Apple: In the Apple App Store you’re able to change the price of your app or game, but it can only be done at certain increments from $0.99 to an upper limit of $999.99.

Amazon: The Amazon app store lets you change the price of your app after release and to any specific price that you want.

Itch.io: Again itch.io comes out on top here with maximum flexibility. Not only can you change the price of your game, you can make separate releases on your existing store front and charge for those but leave the originals for free. The only thing that can’t be changed in price from free is the browser version of your game. Other than this limitation Itch again takes the crown for developer friendliness.

What technology should I use to create my game?

One of the questions that plagues new game developers is what should they use to create their game? This is a multiple choice question with 3 answers:

  1. A Framework
  2. An Engine
  3. Build it from scratch

Starting with a few upfront questions can help guide your decision, to figure out what is best for you,.

First: What sort of game are you trying to build? Is it something that mechanically has mostly been done before and fits into an existing genre (such as a platformer or role playing game)? Or does it incorporate some mechanic or concept that hasn’t been done before?

Second: What is your ultimate goal? Is it to learn programming via making a game? Is it to gain experience so that you can get a job at a AAA studio in the industry? Is it to make something that will last through the ages? Is it to get something to market more quickly?

Third: How much time do you have to devote to this project? Are you planning on working on it full time or in your spare time?

Depending on your answer to each of these questions will determine what path makes the most sense for you.


Game Frameworks:

Elements of Dreams, was originally inspired by the game Weapon of Choice from the 2021 Global Game Jam (GGJ21), which was developed using Libgdx. As such we gained intimate knowledge into the pros and cons of game frameworks such as Libgdx and Monogame and how they can aid or hinder a project’s goals.

On the pro side game frameworks provide a great resource for those with development experience to get started creating games more quickly, as they provide many of the libraries that will be needed such as physics, sound, graphics, and platform exporting. For someone who knows how to code or is learning how to code they can provide a mechanism to build a game without having to think about every nuance that would go into building a game from scratch. Also since much of a game will be made with code, the skills you pickup along the way won’t atrophy as quickly as say learning to use a game engine which may have its UI change in subsequent updates over the years. Many of the well known frameworks have great communities and tutorials. For Libgdx there are two free courses on Udacity that not only teach you the framework but teach you a lot of game development fundamentals as well. Additionally game frameworks will provide the flexibility to create new or less common game mechanics (such as the voxel system in the game Fez). One other bonus is code re-usability, in that common components you build for one game have the potential to be used in future games you create. Finally many frameworks are open source and so won’t require royalties if your game happens to be a runaway success.

However frameworks aren’t all positive, they also come with downsides. The first of these is not all tools will be included. If you want to do level editing you’ll need to find or build a tool yourself (for Weapon of Choice we used Tiled), and can add to decision fatigue or slow down building the game since you will be taking development time to build tools. This can be demotivating when you’re first starting out since your now spending time building something that isn’t your game. Some tools that may have sounded good in tutorials, will turn out to be abandoned leading to alternatives needing to be found (Overlap2D which is mentioned the Udacity tutorials above was one of these examples). Another downside with a framework is things like collision logic or sprite animation will need to be hand crafted. Finally if your goal is to get a job at a AAA game studio, most do not use game frameworks so this will not be a good path for that.

In summary game frameworks are great for those with some programming experience who are looking to get into game development, increase their programming skills, and don’t mind having to build or find additional tools. I would put them in the medium time commitment category.

  • Great for people with some programming experience
  • They provide libraries to speed up game development
  • They provide flexibility to make games that have new or uncommon mechanics
  • Great free learning material for getting started.
  • Don’t require royalties.
  • Knowledge and skills won’t atrophy as quickly as game engines.
  • Code reuse, as components you build in one game can potentially be re-used in future games.
  • Additional tools for game development aren’t included so you will spend time looking for or building them yourself.
  • Not the best for people wanting to learn to code
  • Not a good path to a job at a AAA game company.
  • You will need to write additional logic for common things such as collision logic and UI layout (leading to more development time needed).

Game Engines

After the GGJ21 and first attempting Weapon of Choice with Libgdx, I decided to try and re-implement more of the full vision of the game in a game engine. Game engines are more full fledged programs than game frameworks. Some of the more popular ones include Unity, Unreal Engine, and Godot. As a technology they have their own tradeoffs.

On the positive game engines are often batteries included. Along with a lot of the features that are included in game frameworks (including cross platform exporting, physics and graphics libraries), they often come with level editing, sprite editing, and animation built into the software. This can lead to faster development time for your game because you won’t have to go looking for or building additional tools that you would with game frameworks. Additionally many AAA studios use them, so they can become a good path toward getting a job at one of them. Game engines, while they have some programming that can be done in them, also provide a lot of capability for building an entire game without needing any programming knowledge (see Godot’s visual scripting or Unreal Blueprint as examples). Finally popular engines and those supported by companies have a plethora of tutorials and large communities to help you get started and past many problems you run into.

While there are many good things, game engines have some drawbacks as well. The first is that the knowledge you gain from them can atrophy as quickly as the software is updated. So if an engine comes out with a newer version that changes the user interface (UI) and menus you’ll need to relearn portions of the engine just to be able to do something you were able to do before. Another downside is some of the most popular game engines (Unity and Unreal), require you to pay money to the companies that own them after your game makes a certain amount of money (note that this doesn’t apply to all game engines, as Godot is open source and won’t require this). Another downside is that engines will allow you to create known types of games that exist today, but if you’re attempting to create a new game mechanic or genre that hasn’t existed before, then the engine may not have the flexibility to allow you to create what you want. Finally the programming languages that are used for each engine are usually very specific (C# for Unity and C++ for Unreal), so to fully utilize the engine you will need to learn or know these languages eventually.

In summary game engines are great tools for game development, especially for those under shorter time constraints to devote toward development, people starting out in game development without knowledge of programming languages, and those looking to gain skills that could lead to a job at a AAA Studio. That being said there are some downsides in that what you learn today about an engine may expire by the next version, if your game is successful some of that money could go to the game engine company rather than your own pocket, the engine may not provide the flexibility needed for new game genres or mechanics, and finally you may have to learn specific programming languages in order to fully utilize the engine.

  • Batteries included so you don’t need to look for additional tools shortening development cycles.
  • Good tutorials and documentation for those looking to get started who have little experience.
  • Programming knowledge not required to get started.
  • Popular in the AAA Game Industry, so gaining skills with them can lead to a job at one of those studios.
  • Knowledge about game engines can expire quickly requiring you to relearn things about the engine in order to get something done for a game you previously knew how to do.
  • Some of the most popular game engines will require you to pay if your game makes enough money.
  • The engine may not have the flexibility needed for new video game concepts or mechanics.
  • To fully utilize an engine you will likely need to learn the programming languages that it uses.

Building From Scratch

The final option for creating a game is to build or program it from scratch using the C or C++ language. While this isn’t a path that I pursued for Elements of Dreams it is a viable option for those who have an abundance of time.

Lets start out with the positives of this approach. The C and C++ language have been around for decades, so any skills that you learn from building a game with them will be valuable for a long time after. Those skills that you learn, if they become sharp enough, could provide a path into the AAA Game Industry as a game engine developer (which is one of the most highly paid positions). You will be able to have full control of the game you’re creating allowing for you to create concepts or mechanics that don’t exist in current games. Fixing bugs in the game will be easier as you will have full knowledge of how the game is implemented rather than relying on a framework or engine which may have internal components that you don’t have a clear idea on how they work. C is one of the most portable programming languages so there is a possibility you will be able to port your game more quickly to new systems rather than waiting for a game framework or engine to support that new platform. Finally there is at least one tutorial to get you started with Handmade Hero.

The biggest drawback to this path is the time commitment. Not only will you need to learn the C or C++ language intimately you will need to implement every part of a game yourself including sound, physics, graphics, cross platform exporting, etc. Each of these areas is its own technical specialty and so will take time to become fully capable.

In summary there are some big benefits to creating a game this way including knowledge that won’t expire and that can give you relevant skills to get a job in the game industry. That being said it is a serious time commitment which is better for those who haven’t yet started their career or are just starting it. I wouldn’t recommend it for anyone without an abundance of time.

  • Gain knowledge that won’t expire
  • Gain skills that could get you a job in the AAA Game Industry
  • Have full knowledge into how your game works allowing for you to fix bugs more completely.
  • You’ll be able to write components that you can reuse in other games.
  • Provide the flexibility for new game types or mechanics that have never existed.
  • Be able to port your game to newer systems without waiting on others.
  • At least one starter tutorial with Handmade Hero.
  • Serious time commitment since not only will you need to learn and become good in the C/C++ language, you will also need to gain knowledge into specific areas of computing (such as sound, graphics, and cross platform exporting)

So as you look into how to create that great game idea you have, hopefully this will guide you into the path that makes the most sense for you.

When is the Best Date to Release Your Video Game in 2021-2022?

As we get ready to release Elements of Dreams, a big question came up on when would be the best time to release the game?

Doing a quick search on the web I was able to find an article on Games Radar of upcoming game releases for AAA studios. While this list doesn’t contain mobile or indie games, it at least gave me some information on major studios, who are likely to consume game media with their marketing prior to and during their releases.

After grabbing the list of release dates and names from the Games Radar website I threw it into a text file and refined it for data analysis. After molding the data into csv compatible format I re-saved the file and imported it into my favorite data visualization tool. In my case this was Tableau, but PowerBI could work here as well (note that Tableau Public is free to use if you don’t care about keeping the data public, which in my case I didn’t).

Looking at the initial information October looked to be the busiest month for game releases, followed by November and then it began to taper of in December and January before picking back up a little in February (I had some data for after February, but it seemed rather sparse as I’m assuming most companies aren’t going to commit to specific dates that far out).

This makes sense from a business perspective especially for the AAA studios, as many of their games cost upwards of $60. So scheduling the release prior to the holidays (and well before in the case of October) increases the likelihood that their games are purchased as part of presents for the Holidays. This also means that media is going to be saturated with their advertisement during this time and it will be hard for an indie game rise above the tide. Looking closer at the data by week, we can see that nearly every week up until the week of December 12th has at least one game being released. I also broke it down by platform type in this visualization so we can see that there are a lot of PC as well as console games planned to release prior to the holidays (which makes for a crowded market for any indie developers focusing on PC). Mysteriously absent are the dates after December 12th to before January 16th.

This appears to be a relatively quiet period (at least for AAA), and depending on the cost of your game may be the best time to release. Games that may cost something may be good before (but may still be competing with AAA studios for advertising) or after the holidays. Games for free are probably going to be best after the holidays when advertising has quieted down.

For Elements of Dreams we are planning on providing the first episode for free so this looks to be a good time for us to release if we want to utilize our advertising budget. I’ll leave it to others to assess their own right time.

For any of those looking to explorer the visualization more you can find it here with a preview below.

Games Released By Month

Note that many of the games mentioned on the Games Radar page either didn’t have a date or had a mysterious TBC (so that was excluded). If anyone knows of a better datasource I’m happy to update the visualization and post with it.

Happy Game Developing!

%d bloggers like this: