We presented our alpha-version of Fairy King 2 for AirConsole at Basel Fantasy in May 2016. Now the time has passed on and we are already in February 2017. So what happened? We discussed the feedback for Fairy King 2 and one of the main problems was the stuttering movement of Fairy King. Well, there is a technical reason behind: We want to publish it for AirConsole. This is some kind of service where your game is hosted on a website. You can open this page on your computer screen or with the browser of your TV screen. The page will show you a session ID and everybody in the room can join the game on a smartphone (via website or app). The smartphone will work as 'controller' and the website will work as 'screen'. All actions from the users will then go over the internet to the AirConsole server network and the result is sent to the screen in your room. Even though all devices are connected via the same local network, all messages have to take the way through the internet. This results in a high latency. The engineers at AirConsole did a lot of work to reduce this latency. Some details they explaned on their website (direct link: https://docs.google.com/presentation/d/1t40cmrv7NT45rRwsJUXqZC2uOmZBS0Cbs9jG1J_Jdzc/edit#slide=id.gd83ddb292_1_17). Ok, but then we have the next limitation: You cannot send more than 10 messages per second per device (https://developers.airconsole.com/#!/help). This can be assured by a rate-limiter developed by AirConsole. We wanted to use the same kind of control as we did it for Fairy King 2: The movement with the finger on the smartphone screen directly moves the player over the screen. For this we just calculate the relative coordinates of the smartphone screen and send it to the server where it is adjusted for the TV screen. This menas that our updates of the position on the screen will be updated only 10 times per second. This gives you a feeling as if you would play a game with 10 fps. That's not what players like... Now there are different approaches to solve this problem: If you record the path of the movement of the finger on the smartphone screen, you can create nice and smooth movements on the TV screen. No more stuttering, but a large delay. That's not the right way for an arcade game... Another solution would be to interpolate between the position updates. This also leads to smooth movements, but you still have the delay. You can only interpolate a path between already sent positions. What we really need is a prediction or extrapolation, where the next position update will be. This allows continuous movements of the Fairy King without stuttering. But extrapolation is always just a guess which can go extremely wrong. This makes you feel as if Fairy King would not follow your movements on the smartphone screen, and this is very frustrating. We like the idea of AirConsole and the multiplayer possibilites it would give for Fairy King 2. And this is the reason why we could not publish Fairy King 2, yet.

...how to get a game ready for exhibition in only three weeks

After our successful release of Sam the Sumbot in february we came to the realization that Sam wasn`t well suited to showcase at big exhibitions. At Grafik16, the people digged the graphics a lot but it was very exhausting for them to do maths and concentrate with so many people around.
Sam the Sumbot
So, what to do? Fantasy Basel was only couple of weeks ahead.

We were already working on a sequel to Fairy King, but we had lots of technical issues due to targeting AirConsole instead of mobile platforms. We hadn`t even really started implementing new features because of this. But like in the movies, just in time we received the awesome news that Tobias succeeded in managing the latency of the controller (aka the smartphone), so we finally had a GO.
Heureka!

We had a lot of code from Fairy King 1, which we only needed to adjust for multiplayer, the new platform and add new content. To get all of this done, one of the most important things is a good management of the tasks to do. With the help of Producteev, we had a very good grasp. It`s a platform to create workspaces, assign tasks and mark them as started/paused/finished. To discuss code, we used slack.
A short overview of what we had to do:

- Implement multiplayer (includes: shared lifepool, different shots, death on logout, and so on)
- Implement end of game screen with individual scores
- Implement countdown at the beginning
- Implement item drop system and balance loot drop
- Implement endboss
- Implement minions and their logic
- Create more levelcontent
- Final balancing
- and so on...

As you can see, there was much to do and very little time. All four coders invested their whole spare time into these tasks. We also met twice to develop together, which was very fruitful and good for our motivation. Also, 4 brains think smarter than just one.

We actually built the final version of our game on the morning of the exhibition without being able to really test it for new bugs. DO NOT DO THAT ^^. Fortunately almost everything went fine, we still had to adjust certain things for the second day (easier level design, fixes on multiplayer issues,...) but all in all it was very much playable and apparently lots of fun according to the testers.
couch developers Stand Fantasy Basel

I also spent lots of time getting the decorations for our booth ready. Our goal was to stick out of the mass, since there`s so much going on and so much to see at the biggest Games- and Comic Con in Switzerland! Michi got us a huge poster, I myself cut out lots and lots of Fairy King figures to put around the screen. Also, I prepared a booklet in which people could write us feedback and I created a newsletter list to subscribe.

Our biggest feature I`d say was our awesome cosplay, which Alexander and his brother created for Fairy King 1. No better way to get attention than to walk around in a huge pink box:
Fairy King Cosplay
Everyone digged the mighty Fairy Cosplay lots. They took pictures next to him and some even came to our booth to see what`s it all about.

All in all we had much fun and were rather successful in showcasing our new demo version of Fairy King 2: Rise of the minions. We will definitely keep going on this road (after a well-earned break).

Greets Béatrice


Oliver, Béatrice und Eva

Hey there,
After troublesome months (personal problems, broken servers and all the things that happen in the critical phase...) we are finally back in business. Sam the Sumbot takes form. All the game mechanics are implemented, artwork is done, Leaderboard and Achievements work, what's left are the final steps before releasing the game: Testing and enhancing the user experience.

Testing is important. No one knowns the game better than you: the developer. So you know how things run, how the controls have to be used, what buttons do and so on. But guess what, people who play your game don't! Let's look at a nice example from our first testsurvey.

Sam wants to get back to his homeplanet, his people need him (sounds familiar? :D ). So he has to do some calibrations to get his spaceship started. This is done by catching the right numbers to solve the given equation.

Ingame

So far the theory. Look at the image. What do you see? An equation on top, some numbers which are falling down and a cute looking robot. But what do you have to do? For most people it was clear that you move the robot to catch the numbers. But not for all of them. Oh no. It can also be understood that you have to press on the numbers to collect them (a lot of games have that kind of control). And if the controls can be misinterpreted they will be misinterpreted (remember Murphy's law?). So we had people who just pressed on the numbers and became frustrated that nothing happened. And that's no fun. And if the game is no fun, it will be faster deinstalled than you can say "E.T. phone home".

The problem is that you have the eyes of the developer. You would never guess that people will just try to touch the numbers. That's not how it's supposed to work, that's not how any of this is supposed to work! Okay enough of the memes now!

How to solve this issue? You can't just call every user stupid (okay I did it, but it won't solve the problem). You have to make the instructions clear!

instructions

We did that with a little intro animation which is shown before every level. The level starts when the player moves the robot. Only after that the numbers fall down. This way it becomes clear that you are in charge of moving the robot, that you have to take care for the robot. You see for him that he catches the right numbers to do the calibrations to get back home. And it's your job that the job gets done!

Cheers from the Master Engineer
@VoltarCH

There are tons of articles on how to get your game out there and reach the biggest spread possible, so I`m gonna keep this short and walk you through our process. We`re starting at the moment, where you and your team have selected a release day. This is very important, but keep it realistic. I`m in the lucky position that at this particular moment, I can draw back from coding and let the others finish up. My focus now is on Marketing. The main question always remains the same, no matter how many games you`ve already published: How do we reach the highest download numbers possible?

So, how to start? Preparation is key, sketch out a marketing plan. This consists of a lot of aspects:

It may not sound like the most important thing, but at this point you should ask your graphic designer to get you some „Coming Soon“ banners for your website, twitter, facebook, youtube and so on. Share them, ask your friends to share them and keep pushing them.
Another great thing to do if you already have a polished apk, would be to send them to bloggers, newspapers, to get some pre-published reviews. I mean, how awesome would that be, if people were actually looking forward to finally being able to download your app? Just never give up, I myself had to write tons of mails, just to get a couple of answers and a handfull of yes`es. You might have to start small, ask your blogger friends to write an article or go to websites, where they will feature your game no matter how good or bad it is. You might not get tons of downloads, but it`s a good start. With Fairy King, we had a couple of smaller interviews before getting some attention from the big local newspaper. Once we got there though, people started to mail ME to ask for a TV interview, when previously they wouldn`t even answer my mails. But now, we`re talking about the time when your game is already out there. Let`s stay a moment longer in the pre-published phase:

So, we`re digging out our list of contacts with the goal to get them excited for our game. Prepare a nice mail, link your website, let them beta test if possible and attach a pdf with information about you and your team. Be professional and they just might take you more seriously. Don`t limit yourself to your nation, I can`t stress enough how important it is to think big.

It`s always nice to establish a second network of game developers and alpha testers apart from your press contacts. There are tons of possibilites to get one via Twitter or Reddit. There are even niet lists of people willing to alpha test your app, so you`ll get a nice bug report. Don`t underestimate this, you need to test your game throughly, not just by you and your team. Let fresh people take a look at it, watch them and adjust your balancing. Get the best product ready you possibly can.

What else? Well, it might sound like a little trouble, but it really helps to print some flyers and distribute them in your work place, in universities and –if allowed- public places. Give them to your friends to help spread them as wide as possible. Of course this is does cost a bit, but it gets you started with your first 100+ installs. So for now, ask your designer to create some nice art work in the correct(!) sizes. Get them printed and ready for distribution on release date.

When you`re in charge of marketing, don`t forget to get some translations of your store description. Do NOT use google translate, that`s just really bad. I`m sure you know what I`m talking about. Ask your friends to get some decent french, german, russian, chinese, spanish, … versions of your app. This is not to be underestimated! We`ve had lots of downloads from french speakers, because we really focused on making it easy for them to understand what our game is about.

Also, don`t limit yourselves to the android / windows / iOs Store. There`s so much more out there. Imagine just how many more people live in Asia. Get a good translation and really take some time in your schedule to register on those websites. I never said this would be easy, but definitely worth your effort.

Release Party
Another thing we did, was throwing a release party. At first, we were just gonna invite some friends and clink glasses. On second thought, we decided to invite the press too. I mean, why not? Even though none of them came, they all wished us a great party and success with our game. The fact that they answered was pretty awesome, it made things a lot easier to get in contact with them again afterwards for some reviews.

This is all about learning. Try some things just for the heck of it. Think big, because it might get you somewhere you would never have dreamed of.
These are only a couple of important aspects, if I forgot something really important, throw me a mail. I`ll be excited to hear from you and your experience.

Have fun, Béatrice

You have finished your (hopefully awesome) smartphone game and don't know how to publish it in the different stores? Let us give you a little overview from our experiences with the release of or first game Fairy King for Android, iOS and Windows Phone.

First of all, you need time and quite some nerves. If it's already 11 o'clock in the evening, don't start! Your sleep will thank you (this sleepless night I had on the publish day is not one of my favorite memories)!

We make our games with Unity. This game engine creates an apk for Android, an XCode project for iOS and a Solution for Windows Phone which is nice. For the following I assume that you have either of these (apk or project).

Google Play - Easy Mode

So, let's start with Android, because it's the most easiest thing to publish to. You need an Android Developer Account. This will cost you around 25$ (one time). With that you have access to the Android Developer Console where there's a nice wizard guiding you through the publishing when clicking on the button "Add new App". You need a signed apk to upload or else it won't work. If you first want to beta (or alpha) test your app you can do that in the tab APK (still need a signed apk). Just upload it there and a few hours later it will apear in the store for all invited testers. This is one of the best things, the app only takes some hours to appear in the store even for the first release and updates.
So all in all, what you need is:

  • - around 25$
  • - the signed apk
  • - an icon with 512x512
  • - The graphic which appears on top in the store with 1024x500
  • - Screenshots with at least 320 px in height and maximal 3840 px in lenght.
  • - Some hours until publication

iTunes - Hell Mode

First of all, you need a Mac. If you don't have a Mac or a friend with a Mac, forget it. You can't do it whithout because all commits to the iTunes store are made via XCode. If you have a Mac you need an Apple Developer Account. To set that up, have a look at this wonderful tutorial. The fee for this account is 99$ per year. Is it worth it? Think about that before making the account. For a hobbist this is quite expensive.
For the different devices you need different sizes for your screenshots. For landscape apps its 960 x 640, 1136 x 640, 1334 x 750, 2208 x 1242, 1024 x 768, 2048 x 1536 and vice versa for portraits. For the app icon in the App Store you need a 1024 x 1024 image.
The time it takes for your app to appear in the store ranges from one week to two, even for the updates. So take this into account if you want to release on Android and iOS on the same date.
So the details (again):

  • - around 100$ every year
  • - a Mac.
  • - an icon with 1024 x 1024
  • - Screenshots in 960 x 640, 1136 x 640, 1334 x 750, 2208 x 1242, 1024 x 768, 2048 x 1536
  • - 1-2 weeks until publication

I can't go into the detail for Windows Phone because they changed the publishing pipeline.

Hopefully this short overview gives you an impression what it takes to publish an app. If you have any question or feedback to this overview, contact me directly on Twitter @VoltarCH.

Cheers!
@VoltarCH

Oh no! Now, of all times - that's what we were thinking a few days ago, when a local newspaper published an article about text adventure games and emphasized that they are currently become 'in' again. Why, do you ask? Well, we are planning to create text adventures since a while. There is still a lot of work to do, and right now the newspaper is telling everybody to create text adventures! Hopefully we won't be too late....

The blog entry you're currently reading was written by Tobias. It is my task to implement a game editor where our writers could easily create and manage a story for a text adventure game. I got some descriptions what to do and approximately how to do it. We planned to use SQLite (https://sqlite.org/) as database for the game story. We did not want to use the Entity Framework (https://msdn.microsoft.com/en-us/data/ef.aspx) because of its size. This framework would automatically implement the 'transformation' from the given source code to the necessary SQL scripts. As a consequence we have to do it 'by hand'. A few years ago I've learned how to do this, so it was time to get my notes and reread the steps how to go from a list of features over an entity relationship model (http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model) up to a schema in SQL.

I was looking for an example code how to use SQLite via C# and made some tests. You can read more about this on these pages (https://www.sqlite.org/lang.html, http://www.codeproject.com/Articles/22165/Using-SQLite-in-your-C-Application). I've tried to setup the schema and the SQL scripts to read and write from the database. With the help of a short test text-adventure it was a long work of trial and error, but the error messages from SQLite (it throws nice exceptions) are very useful and with their help it was easy to find the corresponding peace of code. Another helpful tool was the Firefox-Addon named SQLite Manager (https://addons.mozilla.org/de/firefox/addon/sqlite-manager/). It will open a separate window out of Firefox where you can choose the sqlite-file and watch the structure and make queries for tests. At the moment we are able to create a database for a game with some hard-coded statements and read from it. This enables us to work on the editor and on the game app in parallel.

Lessons learned

  • - You can draw a very nice-looking diagram for the ER schema for you database which looks perfect and finalized, but during the implementation you will find some new problems you didn't take into account before. It is thus important to discuss necessary changes on the database model with your team on the go.
  • - You need to clearly define the task of the database: We want to use it only as a data source, this means there is no game logic implemented in the models and the database. In our case, the game application checks whether conditions are fulfilled and takes care of the current status of the user (how much life points, how much cold coins, etc.) and the dealing of load and save of game sessions.