August is coming but we continue to work on Redemption The Third Era. We hope many this blog reader are going to enjoy their vacation. Consequently we suspend our publication until August 28.
To accompany your vacation time, or your summer work, we want to share a music playlist that include some songs inspiring us when we work on Redemption The Third Era.
Enjoy! See you on August 28.
Alessio, Andrea, David, Silvia and Stefano.
This week we will talk about the Graphic User Interface (GUI), namely about the graphics that players will have mainly to deal, about its evolutions and some of its characteristics.
In wider terms, for creating the GUI we are using a system that could result pleasing (to the eye), but always considering that “beauty and functionality” must be the two spirits whose GUI has to consist of.
Because of our pop and cultural references for the game realization, and with the post-apocalyptic setting of “Redemption – The Third Era” world that has a deviant technology if compared to contemporary historical course, we decided to think in these terms for the design and realization of our GUI.
Basically, the game graphics mean to do a representation, even if partial, of our Setting. Also for this reason the various game screenshots are a representation of some parts of it, such as the racial cities. Our goal is to allow the player to breathe the Setting through the common use of the graphical interface.
The frame and the backdrop, the latter consisting both of bricks and of various racial representations, are the basic scheme in which we decided to move for creating our GUI. While keeping the style set on these specifications, however we decided to give a more complex variety to the game trying to change the furnishings depending on the functional needs and making them instantly recognizable according to the scope.
Deck Builder Sample
Market Sample
Empty Home sample
The motion is one of the main aspects we focused on, because it’s the means needed for the graphical interface to achieve credibility. However, we soon realized how the continuous movement can, in the long run, become boring for the players, especially if the same animation is repeated too many times. This led us to show the scenes comprehensive of movement only in the first time they are called for each rendering. In further uses these scenes are shown in their final version, thus avoiding excessive redundancies. On the other hand, other movements are necessary to space out the various aspects of the game, such as the overall view of a group of cards and the view of a single of these cards. Also these animations are thought to have a graphic impact resulting at once both pleasant and fast. The existing structures were instead designed to be adherent to the art of the possible: each structure is something that has been obtained by recovering waste material. The necessary parts were then subtracted or added to the main structure in order to achieve the desired effects.
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:
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:
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:
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.
Needs Identification
Concept Art
Final Result