Design

In this post we will talk about the choices we are making to realize the game Client and about some consequences deriving from them.

Creating a game Client is something really complicated. Especially if you plan to have important basic features, such as:

• The chance to having a multiplatform application without writing new code for each platform where you intend to publish the game;
• Final product high maintainability that permit to easily resolve bugs and to manage additional game functionalities development;
• A little budget for tools and authoring suites.

Haxe, by now together with the inseparable OpenFL is definetly the answer to the previous questions. Haxe is an extremely versatile programming language that allow deployment to different platforms.

Haxe has a syntax very similar to Action Script language. Its strengths are:

• Supportto the formalism needed to produce code being easily modified during time;
• Support to the implementation of advanced scripts that, if properly nested in the code, can shorten the production time;
• The ability to have different targets during deployment and so the availability of sharing code to create different applications that can be executed in different environments: Flash, Java, C++, C#, …
• The availability, thanks to the use of OpenFL library, to have as target the main mobile platforms, such as Android, Apple and Microsoft.

Furthermore, both Haxe and OpenFL can count on communities of users and developers, allowing continuous improvement of the versions that are released. Just think that Haxe, born in 2005, is today at 3.1.3 version, while OpenFL, born about two years ago by NME, is today to 3.0.3 version.

So we have choose this language because it largely reflected our needs, but also because we considered creation from scratch of an engine capable to manage a game client out of our capability. For this reason we started to look around in order to see what the world of the tools can offer. At this point we identified Stencyl.

Stencyl is an authoring tool that allows games creation without too much worrying about the source code, indeed it lies beneath and it takes over all that is needed for the most common actions that are present in the games. At the same time, however, it allows to go deep into the code and it provides a constantly evolving Haxe/OpenFL engine. For all these reasons it proved to be the most appropriate choice under different points of view. Now we are studying how to adapt it to our needs, mainly in the following directions:

• Ease code writing: Stencyl over time has become a very interesting and useful product but it hasn’t the ambition to replace an IDE in its main features, such as code autocomplete and other similar features;
• Create a system to planning and executing default tasks, needed to create animations following our style;
• Look for a way to make Stencyl fully usable through revision control tools.

Stencyl also has another great factor to count on: it allows a totally free access to all its features and it let you publish the SWF file. At the same time, with a small annual fee, you can publish all your hard work on many different platforms including Android, Apple and Microsoft (both in the mobile and not mobile version), Linux.

Passing to the client GUI, today we are designing a system that can be well integrated with the post-atomic setting which is the cornerstone of Redemption – The Third Era. Our design system is defined by functions: depending on the functionalities we need to give the user, we design and create various graphics with a unique and suitable background. At the same time we try to apply the User Centered Design methodology, always remembering that what we produce is to be enjoyed by people, in the easiest way.

Among the different environments we are designing, there is the one providing for the opportunity to sell the own cards in the market. In order to doing this, there is the need to select the card, to insert its price and give the go ahead to the sale. Below you can find an example of how we are developing this requirement by creating the need, through the drafting of a sketch and then creating the necessary part for the graphical interface in order to cover the requirements.

Because our needs to have a multi-platform system, what we are trying to do in the GUI production scope, is to create components that are suitable for both Flash/Desktop and mobile sector, or at least we try to make them easily adaptable. Here is shown a particularly explanatory component, as it will be usable both via keyboard or mouse for the Flash/Desktop sector and through the tapping of any mobile device.