Hitnoodle Blog

Audience Driven Design

So a few months ago I went to Unity 2015 in Bangkok, Thailand. It’s basically a conference for Unity3D users and everyone who are interested in it to learn more about the tools, best practices, and such. It’s also a good place to network around other South East Asia game studios and shatter your confidence, something like “You’re not as good as you think”.

By the way, I still want to compile all those things I learned into one single open documentation,, but that’s for later discussion.

One lesson that resonates to my mind is a concept called Audience Driven Design. It’s very obvious, true, but somehow that simple concept eludes my mind for so long. Too long.

Simple Definition

As the name shows, Audience Driven Design is a concept where you, as a game designer, create a game based on what your specific audience wants/prefers.

If you want to create a game where everybody can play it, scratch that, there is no such things.

If you want to create a game for 40 years old moms in Asia, also scratch that. There is no (or too few) common ground. Country, how they raised, what they buy, income, and whole other things is different.

Be as Specific as Possible with your Audience

Let’s say you want to make a JRPG, choose which kind, and who for. Final Fantasy, Tales, Star Ocean, and Suikoden is different, which for example Tales is more of a niche anime RPG, and people playing it are searching for different things.

Let’s say you want to make a JRPG like Final Fantasy, choose which Final Fantasy. There are more than fourteen iteration of it, every entry have their own strength and weakness.

If you want to make FPS, Halo, Half Life, Unreal, Doom, Prey, Call of Duty, and Battlefield is different. If you want to make a platformer, Braid, Trine, Megaman, Ori, and Shank is different.

Each game have their unique characteristics and audiences. Even when they overlap each other, your game strong suit should appeal to your most specific audience.

Again, Know your Audience

For example, I want to create a murder mystery visual novels that is thrilling, something like Virtue’s Last Reward:

  • Some of the audience also play 999 and Ever17. Which elements do they like from each game? Do I want to make it more mystery, or more thriller? Do I want puzzles in it? Do the audience I want to appeal even like puzzles?
  • Some of the audience also like Umineko (game), but hate the anime. Why? Do I like to create a thorough descriptions? Do I focus on the character interactions?
  • The audience like to hang out on r/visualnovel, who are the ones like mystery the most? Also on NeoGAF? mystery threads on /a/? AnimeSuki Umineko threads? Be specific, and interact with them elegantly.

Another example, I have an imaginary client who wants to make a game for her event:

  • She doesn’t really care about technical difficulties and game balance. She wants it fun.
  • She wants the game plastered with advertising of the events and the products.

So then screw balance, screw artificial-coolness, create the perfect game for her. Instant gratification rewards, flashy animation, simple gameplay, plastered advertising on everywhere (I mean everywhere). She is after all, your audience who pays you money.


And for those idealist indie developers like me who wants to create a game for himself, do you even know you?

  • For last example, I know I recently acknowledged that I like high-level raiding on FFXIV.
  • Specifically, I like scripted reaction fight like Titan and Shiva Extreme and Turn 9. On the other side, I don’t like Ramuh, Moggle, and Bismarck Extreme.
    • Why? Because I like thrill with upbeat fast music.
  • I like Coil of Bahamut but not Alexander. I also usually stop playing when there is no more quest to do.
    • Why? Because I care more of the story than shiny gear treadmill.

So when I create a boss fights for myself, in a game I want to play, I’ll take those specific things I know I love, twist it, and make it better. And I know for a serious game I want to make, I’ll make it to always have a great story that I will enjoy.


I believe by knowing your audience, you’re going to make a more personal game to them. It will appeal more, remembered more, and they will have fun more.

Commercial “get rich buy a house on a beach” success? Not likely.

Touched them indirectly, making them your devoted players and fans, spawned conspiracy theorist, youtuber having fun, word-of-mouth niche success? I hopefully believe so.

Unity3D Single Scene Architecture

One of my eureka moment when I learned Unity3D was when Brett Bibby introduced the concept of Single Scene Architecture at one of his talks. As the name said, it means that you only worked with one scene at your release builds. By optimizing into only one scene, we can handle resource loading better and faster. Asynchronous loading, less overhead, and less memory needed.

Disclaimer: All of the development examples comes from Tinker Games’ INheritage BoE. I only speaks from my experience and I’m sure there are better ways, so take this (hell, all of the information in this blog) with a grain of salts again. Yes, I can’t create a reusable tutorial/framework yet.


When I’m developing a game on Unity3D, usually I will create and design scenes according to the flow and functionality I want to achieve. For example: SplashScene, StartScene, StageSelectScene, GameScene, and HighScoreScene to name a few. I will then create a script using Application.LoadLevel() to navigate through them.

On the opposite, on a single scene world, we will only work with one scene (I usually name my scene MainScene) and one object at that scene hierarchy, which is the MainCamera. There are no other objects at first, because it will be created from resource files (XML, json, prefab, what have you) later when needed. Of course, because we’re not using Unity3D scene management, we have to handle that ourselves.

By that, we have to mind (minimum) three things when implementing a single scene architecture. How we serialize and deserialize our object, how we manage our scenes, and how we manage our projects.

The concept of single scene architecture is to minimize all the object at the application starting point and to load all resources on the fly only when needed.


Serialization itself is quite a simple topics. It’s how we save an information or an object into a physical resource file and how to load that back to the original. For example, simple cases of serialization are saving progress data and loading level data.

We want to minimize the objects down to one, so we have to serialize all of other objects. In INheritage, we basically have two kinds of scenes, Menu and Game. Menu scene is where the buttons and images and scrolls take actions whereas Game scene is where the magic happens. The key thing to notice is, all of the Unity3D scene besides Game scene are Menu scenes. And so, we can treat them all the same in serialization-wise!


MenuScene design example in Unity3D.

I began by creating a model from all the elements in the menu. What kind of information needed to make the menu? Sprite, text, actions, glows, etc? I then create a class to hold all of the information and that class can serialize all of the scene data to/from a XML file. That class is also can create game objects according it’s data.

To sum up, I will have a MenuData class (singleton for easy access):

  • Holds all menu data information in arrays.
  • Initialize() and Clear() for basic data handling.
  • Save() and Load() for serialization.
  • CreateMenu() for creating game objects.

For serializing, I will have another game object that will save all current scene menu data to MenuData class and use that to save to the XML file. Deserializing just takes a method to load that XML file and another to generate the game objects.

The usual flow for my menu serialization is:

  • Design the menu as usual in Unity3D.
  • Serialize: Save all menu game objects to MenuData class (using script) and save that to XML.
  • Deserialize: Call MenuData.Load() to the XML file and MenuData.CreateMenu() from an empty scene.

The example is for menu, but the basic is all the same for Game scene and whatever specific scene/object you need to serialize.

Managing Scenes

So we can serialize all of the game objects in one scene, how can we make the transition and interact with each other? We handle this the usual non-Unity3D way: SceneManager / ScreenManager / StateManager. There are a lot of excellent tutorials about managing scene states, so please check others out and implement how you think it best.

For me, I start by creating how a scene is supposed to behave in it’s life. It will have the default behavior to be implemented when awaked, enabled, and destroyed. Load the XML and other resources in Awake(), start the menu transition in OnEnable(), and delete the resources in OnDestroy(). This SceneController script was created as a template and will be used to implement the scenes.

In my menu design, the interaction/transition was implemented on one script per scene. This script will handle how the object transitioning between scenes (which object fade in/out, when to glow, etc.), implement the buttons delegates (what to do when this button is pressed), and other things. All of this functionality will also be copied and used in the SceneController class.

SceneManager is the usual singleton manager that manages the scene transition. My implementation is simple and only changed a little from the initial Brett’s version. Here is the basic flow:

  • When we need to change scene, we call SwitchScene in code. For example: SceneManager.SwitchScene(Scene.AboutScene).
  • It will then search AboutSceneController script and attach it to the main camera, but NOT enabled yet. it will then load the scene resources.
  • When the loading is finished, it will enable the current scene script (AboutSceneController). The game then will transition to that loaded new scene. Also, it will destroy the previous SceneController script that is attached before.


SceneManager in action.

Multiple Projects

Because the minimal nature of single scene architecture, it will be difficult to debug or changing something. The straightforward solution is use two projects, one (or more) for designing the game and one other single scene project for building the release version.

Unity3D have a great editor capabilities, and it’s on the developer hands to extend the functionalities. Development projects is where you want to go crazy implementing editor that is easy to use and a scene that is polished and usable. Serialize that into XML and use that XML in the single scene project for best use of both worlds.


Using single scene architecture on Unity3D release project will optimize your game more. In your workflow, you will have a minimum of two projects, one design and one build.

  • Your design project is the usual development project. All of your scenes objects should be serialized into each own XML or whatever format you prefer.
  •  Your build project will consist of a single scene, with a MainCamera object and a SceneManager script attached. Maybe others too, but it should be minimal. This SceneManager will handle all of the scene management and attach the corresponding SceneController script according the current scene.
  • This SceneController will then load the XML and use that to create the scene objects. It will also manages it scene interaction and transition according to the implementation in the design project by copying it partially and manually.

SGA: A Cross-Platform Story Part I (Introduction)

A long time since the last post, and even now I tried to escape writing more important things *cough* final project *cough* by writing this.

This is my subjective experience from developing Soccer Girl Adventure, a game that been in development since February 2012 until now. You know, the usual of writing code, refactor, change mechanics, rewrite things, rewrite features, and on and on and on. Thankfully, I can say that now it’s already on release version for four mobile platforms.

Status: We’re still discussing things with our publisher for iOS and Android, released on our own on Windows 8 store, and currently on QA at Blackberry Appworld for BB10.

I plan to divide the story by the platform, the exception being this part about the game introduction. This is because it’s more or less the same timeline when I develop the game. Next part is iOS, and then Android, Windows 8, and finally Blackberry 10 (also back to Android).

What, What, What


Soccer Girl Adventure is an adventure runner game. Our heroine, Sora, love to play soccer all day. The Soccer Boys on the other hand, don’t like it when Sora play soccer. Why? Because she is a girl!

Angry, Sora then went on a journey. She want to pass all of the boys and play in the soccer stadium. From that, she will finally prove that a girl can play soccer too!

Interesting. Corny. Well, it’s quite cool and it works for a theme.


We already decided that iOS will be our first platform to develop on. I used Objective-C a bit, and to be honest, I’m not a fan. Someone then gave me a recommendation that you can’t go wrong using C++ for game development. It’s more familiar, performance is great, and if in the future I want to make it cross-platform (which I did, hence this post), I can do it easily.

Cocos2d-X is the one I put faith from then on. It’s open, meaning I can go to the source if I want to know how certain things work and don’t. Also, they have a great community and support at the forum.

At First, It Was Rhythm

Let’s talk mechanics. First iteration comes with DDR-like gameplay. Simply put, the player will have to swipe certain directions according to the rhythm direction that comes up. If succesfull, then our heroine Sora will pass the enemy by tricking him.


After a few plays, it’s decided that it totally sucks. Player will be too focused on the bottom part on the screen to enjoy the great illustration of the player and the backgrounds.

Then, Someone Invented Buttons

The challenge will be remembering which button does what. With buttons, player can enjoy the art while still immersed in playing.


Of course, It doesn’t comes easily. When facing multiple enemies, a majority of player messed up and press the wrong button. One of the important fact we realized is, why the fuck it need buttons? We don’t have platforms and Sora will always run in a straight line. Why force the player to remember and use the buttons? Also, it seems very counter-intuitive to use virtual buttons on a touch-device.

Gestures Saves the Day

Remove all the buttons and other ideas, go with simple things. Swipe for tricks, tap to get items and buy lemons, and touch the bar for using special trick.


Testing and testing, we got good responses and went through the gesture mechanics. So, the challenges remaining now is the actual game implementation from the beginning until the end on iOS platform.

To be continued on the next part!

Pig Rider

This post is about Tinker Games’ latest release, Pig Rider. Our site is not finished yet so I’ll just post about it here.

Pig Rider is a drag racing game. You will help the Rider by changing the gear perfectly, make him accelerate faster and jumping to avoid all the obstacles.

YouTube Trailer

The inspiration comes from the Android/iOS hit Drag Racing. Simple mechanics, addictive with its upgrades and races. We have a gameplay addition, jumping, to make it not-so-simple and have more variety.

Pig Rider have a twist. In a world of endless game, you can actually finish this race. By doing the quests and collecting money from doing various cool things, you can make your ride more powerful. Hence, your chance to finish will be higher. 500 meters is quite a long journey though, and is quite impossible to achieve without upgrading the rider’s armor (or so we plan it to be). You will get a special screen if you win the race.

Oh, you also can ask any questions about it here.