Developing Pin The Tail

1. About Pin The Tail

PTT Icon

Pin The Tail (PTT) is a fun and addictive version of the analogue game "Pin the tail on the donkey". It's a side scrolling 2D platform game. There are multiple layers of backgrounds with randomly placed animals that you can pin their tail on. We have 9 animals that represent the majority of the farm animals. The scenery is a farm like landscape with lots of other 'assets'.

Most of us have young children that is one of the reasons we chose this type of game (see: Tests chapter). Another reason is that we used this game as a proof of concept for our technology choice. Therefore we didn't want (and need) a very large complex game that would take us months to complete. We just wanted a simple game that would give us an idea of the possibilities of the chosen technology.

We have written some games before; Rollin' Pirates and Ghost Mind. Both XNA projects targeting Windows Phone (7 and 7.5). Our background is C# we have many years of experience in building business line applications with ASP.NET/WPF/Silverlight/Win forms. Our technology choice should be as near as our roots as possible. And it should be platform independent. The latter was our main goal, so we chose HTML5. There are lots of frameworks for creating games with HTML5 but we chose ImpactJS.

 

1.2 Impact JS

At first we did make some good progression. In about a day or two we had an initial version of our POC. There was a parallaxing background with animals moving in front of it. You could hit the animal and, depending on the location within the target, get some score. All was looking quite ‘impressive’ (for the total time spent). With this first version we could perform some more tests. This is where things got bad. With three layers of background and 10 animals in view the performance dropped dramatically. We got a frame rate of about 10FPS, even after doing some performance improvements we noticed inconsistent framerates across different platforms. This stopped us from giving each gamer the same experience when playing our game. We could not find any other examples that matches our specifications. All HTML games are very small, or have small assets.

PTT HTML 5 First Draft

Figure 1: This is what the game looked like in JS/HTML5.

 

1.3 Unity 3D

Ok, so HTML/JavaScript was out of the picture. We needed something else, more powerful and closer to our roots. My business partner dove into this and came up with Unity3D. This was more like it! They support C# (script) and target almost every platform imaginable. Well at least the platforms we wanted to target (iOS/Web/Windows/Windows Phone/Android). I told you about the games for WP we wrote? Off course all of our games were fantastic, incredible, fun, etc. But with the WP having only 3% of the market this wasn't going to bring the big audience to our doorsteps. Besides that, tablets are the better platform for games, in our opinion. At this moment Unity has support for Windows 8 and Windows Phone 8.

So Unity3D also met our demands. But, as we would soon find out, the designer itself is something different than Visual Studio. Our experience is coding-coding-coding, not visual development. And there we were 'drawing' our game. We both made the mistake of bypassing the designer all together and focus on scripts. Our first version of the game was therefore nearly based on scripts. Later on we learned more and more of the power of Unity, like prefabs, animations, colliders etc.

We started off with the free version of unity and only bought the iOS add-on. If PTT is successful on apple's platform then we could always easily port it to Android and Windows8.

 

1.4 2D Toolkit

Another challenge with Unity3D is: 3D. The environment is meant for developing 3D games, not 2D. There are a few examples of 2D in Unity but the most make use of a third party toolkit. There is actually only one issue with 2D versus 3D; the fixed resolution. 2D games are pixel perfect. That means that we design the textures exactly as large as we want them to be. We, obviously, could implement this ourselves but it would be time consuming. Besides that there are some good frameworks that take this out of hand and add more features that could speed up our game design. Based on a quick analysis we chose toolkit 2D (TK2D). The reasons that we chose this was that it's available in the asset store, the price was right and we read some good reviews about it. While reading the reviews we ignored the fact that the majority of the games created with TK2D were retro games with very low texture quality. This would hit us in the face later on as we would find out.

 

2. Approach

So there we were. We had chosen a technology, a game design document and a target platform. The only thing we needed to get going were assets. We designed the animals, background and all other small assets to make the scene livelier.

 

2.1 Parallaxing backgrounds 1.0

The basics of PTT is a moving background from right to left with animals in front of that also moving from right to left. Both at the same speed so it looks like the camera is scrolling from left to right. The full scenery graphic of the game was layered so we broke this apart into three images. One for the clouds, one for the hills, and one for the grassland. Each of these images are used as layers in the game. At the far most back there is an image with a gradient from blue (top) to white (bottom) to represent the blue, blue sky. Just in front of that there is a, non-moving, sun. This technique gives the game depth and is called parallaxing. We only had a scenery of 1024 x 768 pixels. For parallaxing we need a background of 2048 width (2 x 1024px). Since the far most left of the background was different than the far most right, we could not stitch them together. But by flipping the background over the Y-axis we did have a background that we could stitch together. Basically all background layers start at x=0, y=0. They are moved in the update method by the current spreed to x=-2048. When this position is reached the background is moved back to x=0, y=0 and the loop starts again. This all works but after a while the user notices that there is not much variation. Every 2048 pixels he sees the same layer passing by.

 

To avoid this we added assets like a tree and a barn to the first two layers. Those assets were placed randomly on the background. When this asset went out of sight it was replaced on a random position in its layer. This way it seemed there was more variation. All those assets need to be moved with the speed of the layer they belong to. At first this was no problem but later on we added about 30 different assets that all must be moved and repositioned. As we didn’t have a proper game design document this needed some investigation since the assets must not overlap the animals.

 

2.2 Parallaxing backgrounds 2.0

For the reasons mentioned above we tried a different approach. We created a prefab for the grass layer. This contains all the assets we wanted to show. Runtime, every time when the background is repositioned at the beginning, all those assets are randomly turned on or off. This way it did look like we had a different grass background but we didn’t need much script or processing power.

 

2.3 Animal prefab

For the animals we used only a single prefab. We only have images of the animals without their tails. We also have an image of the target to click on. This target is placed over the animal at runtime. We have positioned all animals in a certain way that the center of the target is always at x=128 and y=128 (halfway). This makes the score calculation easier. Finally we have a single image of the tail of each animal. When the user clicks the target this target is replaced by its tail. All animals have two animations. One to make it more alive, each animal has its own animation which is played once randomly between enter and exit. The other one is an animation for when the target is hit. These are all the same for all animals. To make the animals all center at 128, 128 we needed to make the sprite 256x256. And since we have 34 frames of animations per animal this gives us a very large spritesheet. At first this didn’t seem a problem, we developed on our super-laptops and the performance was excelent. Later on this would give us some headaches as you can read in the “performance issues” chapter.

 

3 Performance issues

While developing on our laptops the performance was, of course, no issue. To test the game we deployed our game to a website. While doing this we noticed that the textures were very blurry. But, since this was about testing the gameplay, we ignored it for now.

It was only when we deployed it to our ancient iPad 1 we noticed that the performance was not as we expected. The quality was fair, better than the webplayer, but still not perfect. The performance was so poor that it seemed that the user input was ‘delayed’ for 10 pixels. So to hit a target you must hit 10px in front of it. It was time to ask google for advice. Soon we discovered the quality settings of Unity. With all setting to max the webplayer output was perfect. But the iOS output was unplayable. The game didn’t even start half of the times. Obviously setting the quality to poor would make the game playable but ugly. A bit higher than poor the performance drop was irritating. We have searched the internet for many, many hours to find a solution for this. In our minds it did have something to do with the large sprites that we had. But it also would take a lot of effort to refactor the textures for this. And, there are many games on iOS that perform perfectly on my iPad 1! A lot of them have far more textures than we do. So what is the real issue here?

 

3.1 Upgrade of TK2D

While asking Google for advice I noticed that we were using an old version of TK2D (version 1.72). Unikron had built 2 new versions since that. And even a patch for the latest version. They had added a lot of features and performance improvements. After downloading the latest version (1.91 + patch 1) the game performance behaved correctly. Still we could not run the game on best quality on the iPad 1 but it looked and performed like we expected it to. We didn’t look into it that precisely but we guess that the performance drop was caused by using mipmaps. This feature we didn’t use but was turned on by default. Unikron, you saved our day!

 

3.2 Startup

Another performance issue was the startup time our game took. Since we didn’t want to get the Pro version of Unity we are stuck with their splash screen. This is fine, but not when it stays on for about 10 seconds. Our start scene was the menu, we didn’t have a splash of our own, yet. This menu uses the animal prefab of the game to give an overview of all animals that you would see while playing. The idea of this was that at first all animals were grayed-out and once you have played the game and reached a certain level than that animal would be drawn full-color in the menu. So while starting the menu scene we instantiated 9 prefabs, and off course some buttons etc. We changed this by removing the prefabs and drawn a static image as a background. This improved the startup of the game by about 2 seconds. Still not enough! My 1 year old daughter (one of our first testers) didn’t even had the patience to wait for the game to start. After a few seconds she pressed the close button on the iPad and clicked another icon. Still the Unity logo is about 4 - 5 seconds displayed but this is acceptable, for now.

 

3.3 Borders around textures

We had some very annoying borders around our textures. This was only noticeable with the parallaxing backgrounds. We needed so stich these seamlessly together for the never ending scrolling experience. But now we saw a thick border between the two textures. We solved this by setting the Premultiplied Alpha option of the sprite collection to true.

 

3.4 Blurry textures

Another issue that is still not solved until today is blurry textures. While this was a problem on the webplayer at first we now only have this issue on the iPad. The animals that are moving from right to left are displayed in three rows. The front most row is displayed at 100% of the texture size (256x256). The middle row is scaled down by 15% and the last row is scaled down by 30% (from the first row). Strangely the middle and last row are displayed perfectly. The animals on the first row are still a bit blurry. After a while we came to realize that iOS supports only textures of 2048 max. We had one atlas of 2048x4096. However this did work, the resizing of the atlas made the images blurry. After all we came to the conclusion that our spritesheets were too large. We dropped about 60% of the sprites to reduce the amount of “out of memory exceptions” on iOS. Luckily this still gave a nice animation in our sprite.

 

4 Tests

So with most of the performance issues out of the way we could show the game to our test audience. In this period my wife gave birth to our second child so we had a lot of visitors. Some of them brought children of various ages so we had a variety of testers. At first we thought that the game would be played by children of 2 to 6 years of age. Unfortunately these children didn’t like the game that much. They were too quickly bored with the gameplay. All adults, on the other hand, were enthusiastic.

We thought that children would play the game a lot and therefore we wanted to use an adrotator. But now, seeing that children aren’t going to play it for hours and hours we decide to sell the game. We think we have created a trigger for adults to keep playing by our Facebook integration. But what about the children that the game was intended for? We added two modes to the game, one for adults one for children. The children mode lacks the tail button selection. So they can just keep on clicking the animals.

Since we had a lot of useful assets, we decided to integrate more games. The first one was memory, the classic card game. This took about 4 hours to implement. After this we created a puzzle game, this took about 8 hours to implement. Then we added Tail it Quick, a game where all animals and all tails are shown. The user must click first the tail then the correct animal. The quickest user is presented in the high score. Finally we added “Guess the animal”. There are three animals shown and the sound of one is played. The user wins by pressing the correct animal. This way PTT is also fun for children.

 

5 Conclusion

At the end I think it is safe to say that we are never going to make up the time and money spend on this proof of concept. But we are convinced that the knowledge we gained will help us improving our future games even more.

Hope to see you again on our next game development blog, and we hope you enjoy “Pin the Tail”.

PTT Final