TAB UNITY SDK VERSION 8.11
 All Classes Namespaces Functions Variables Properties Pages
Creating your game

During creation of your game you'll have to consider some things that are related to the F4F environment, that your game will run within. This section contains those topics. Please, if you did not do already, also read the sections Fun4Four Concept and Submitting a Game before starting your game development process.


Performance and Features

The typical Fun4Four device offers a multitouch touchscreen recognizing up to 40 touch points. However, please note that older Fun4Four devices use touchscreens that are only single touch. If you want to support the broadest range of devices, you need to also support that tables. This is not a requirement though.

Fun4Four devices have been released in different hardware configurations over time. Some configurations use older graphics cards, or less RAM. We'll test your game on those configurations and set compatibility settings as appropriate. In general, please consider that you're not on a dedicated gaming machine with endless power. Keep your resources in place and try to keep a minimum resource usage profile, especially if you're going into 3D.


Handling Videos

We ran into a lot of trouble when displaying videos using Unity premium on our table. Unfortunately Unity handles videos in the worst possible way, actually rendering it into a texture. If you want to display videos in high quality or big size on our table, you will not be able to use the Unity video texture feature, as it is simply to resource intensive and causes the video to lag. We recommend you to use the advanced AVPro video codec available in Unity asset store instead.


Recommended folder structure for Unity game assets

This is the way we recommend to you to structure the game assets within our Unity projects. It's not a must though.

FolderStructure.png
Unity assets folder structure
In most of our games we're using four scenes. So every folder shown above except Scenes and TABUnitySDK, contains again one folder for every scene and sometimes one for global assets which are used in more than one scene.

Example:



Localization of text

resources.png
Resource files
To make your games available in other languages than the default language, you'll have to use resource files to do so. By using resource files it's very simple to change all the texts in a game independently of end user language.

All pieces of used text in the game should be stored as key = value pairs in a .resx file within the media folder. For every language you need to define one resource file. You simply have to resolve all your text phrases using the GetText method and at runtime the PhoenixController class takes care to process and cache your resource files and to determine the right text to display.

To create/edit such a .resx file you can use one of the open source editors like the Simple ResX Editor.

If the currently selected language is not available, the SDK will automatically fall back to the default language (English) which has to be contained within the (mandatory) Resources.resx file.

Help Files

For every game on the F4F table it is required to provide game help, which is shown to the end users at the details screen of the game. These help pages should give the end users a short explanation of the selected game. The help must be available in English and German, and can be provided also for the four most common languages of the F4F table which are, at the very moment, German, French, Spanish and Turkish.

Text Storage

The help texts are stored in the resource files of the game (see Localization of text). Just store a key value pair in resource files, for every help page the resource file will then contain one sentence. Inside the game you can retrieve the texts by calling the GetText method with the specific key as an argument.

The keys of each help text key-value pair should be named as following (for game IDs, see Requesting your game IDs):

Image and Animation Storage

The following files have to be placed into the folder media\menu, and named like the following examples (for game IDs, see Requesting your game IDs):

For animation files use codec AVI XVID, resolution 640x360 pixels, at 30 FPS.

Visualization of Touches

Touch_Point.png
Touch visualization

When creating your help images or animations please use the visualization help files included in the SDK.

You can find them in the folder Developer\arrow_pointer:

The images in the folder arrow_pointer_final_512 can be used to create a touch animation using the image sequence.

The images in the folder arrow_pointer_slider_final_512 can be used to create a touch and hold animation using the image sequences in the sub folders.

In the sub-folder ending with _seq1 you'll find the touch-down sequence, in the sub-folder ending with _seq2 you'll find the image to be shown when the your is keeping pressed, while in the sub-folder ending with _seq3 you'll find the touch-up sequence.


Menu Sound

You F4F game has to contain a short sound file to be used within the main menu game details page. That sound file should contain some audio which is "typical" for the game. At TAB we usually take a nice part of our background music loop for use within the details page. This file has to be named Sound_[GameID].ogg (for game IDs, see Requesting your game IDs).

The sound needs to be placed in the media\menu folder.


Menu Icons

Icon_v2_UnitySDKDemo.png
Icon_v2_[GameID].png
Icon_v2_UnitySDKDemo_small.png
Icon_v2_[GameID]_small.png
The menu icons for the F4F menu must be stored in the media\menu folder. Please note that you must not perform any bevels or similar effects to the icons so that we can prepare the final icon for our recent design on our side before releasing the game on our side.

The size of the game icons must be 256 x 256 pixels and 128 x 128 pixels and the file names must follow this naming conventions (for game IDs, see Requesting your game IDs):

  • Icon_v2_[GameID].png for the 256 x 256 icon
  • Icon_v2_[GameID]_small.png for the 128 x 128 icon

The icons have both a visible part and an invisible part.

The 256 x 256 icon has a visible area of 240 x 240 pixels from the top-left corner. The remaining space shall be filled up with black canvas.

The 128 x 128 icon has a visible area of 120 x 120 pixels from the top-left corner. The remaining space shall be filled up with black canvas.


Game Preview Image

PlayerScreen_UnitySDKDemo.png
PlayerScreen_[GameID].png
Your F4F game also needs to provide a preview screen of an in-game scene to be used within the player place selection screen or at some other places.

To create this screen, capture a 1920 x 1080 pixels screen shot of your game and insert it into a 2048 x 2048 pixels canvas.

This file needs to be named PlayerScreen_[GameID].png, and needs to be placed in the media\menu folder (for game IDs, see Requesting your game IDs).



Splash Screen

It is mandatory to provide a splash screen to your F4F game. During display of the splash screen the game should load all game content. Once loading finished, the game should start. The splash screen must have the format of 1920 x 1080 pixels, and is required to switch the game to full screen mode immediately after launching.

The splash screen should be contained within the start scene of your Unity project, and does not need to be delivered to us separately.


Game duration

Games should be designed to an average duration of 5 minutes. Games must not exceed playing time of 10 minutes to keep total over-time-income of the F4F table on a good level. If games have a non-time termination condition, there should be a hard-coded time termination condition at 10 minutes. If you implement a hard-coded time termination condition make sure the user understands at the beginning of the game that the maximum time duration of the game will be 10 minutes.

Please note that it is perfectly fine to offer an Continue option to the user after the game time has passed, as the user will always have to buy new credits to continue playing.


Exiting a game

It is required to add some kind of exit mechanism to a game to allow the user to leave the game early. The game must, if an early exit is being triggered, ask the user to confirm the exit decision before actually quitting the game.


Multi - Touch input

Multi-touch refers to the capability of a touchscreen to recognize two or more points of contact on the surface concurrently. The constant tracking of the multiple points allows the multi-touch surface interface to recognize gestures, which enable advanced functionality such as pan or rotate gestures.

The typical Fun4Four device offers a multitouch touchscreen recognizing up to 40 touch points. However, please note that older Fun4Four devices use touchscreens that are only single touch. If you want to support the broadest range of devices, you need to also support that tables. This is not a requirement though.

In our project we're using the open source TouchScript library (http://interactivelab.github.io/TouchScript/) which is quite nice, but you can choose of course other libraries if you prefer.