Episode3 RPG game

Timeline:  2009

Team: Solange Molina / 1 Project coordinator / 2 Engineers

Role: UX/UI Designer, Interaction Designer, IA, Game Dev

Tools: Flash + AS3, Flash Server 3.5 , Visio, Photoshop

RPG based Flash Game


The flash game will be used to present and disseminate some of the results obtained by the WP4.3.3 validation exercise. The flash game will build on the main outputs of the WP4.3.3 role-based gaming sessions, related to SESAR concept validation and clarification.
The objective is twofold: to expose more people to the gaming techniques and to the specific outcomes found in the framework of WP4.3.3 validation exercise and to perform a comparative between paper-based games and flash-based games. Paper-based games have great flexibility, allow the exploration of concepts that are quite open and have different possibilities of implementation, but they also have limitations in the interface with the experts, meanwhile, the flash/web based games loose part of this flexibility but improves in the interface and presentation aspects.


The flash game will develop a single scenario. To describe this scenario the main input will be the interim report that summarises the outputs of the first cycle of role-based games. This scenario will be refined with the outputs of the second cycle.

The game will take place in the execution phase, in a “typical” busy en-route airspace. It will follow the evolution of a complex problem detection, since its detection by the subregional manager, till the execution of the solution proposed and refined by the different actors.

Phase 1: Gathering information & analysis

In this first phase, I was in charge to collect information among my colleagues, which ones were used to work with ATM language. Once I got an amount of knowledge, I began to read carefuly all the documentation related to the paper based game they perform at the beginning.

Getting the lay of the land

Due to this is a Role Playing Game, and to understand the scope of the game, it was necessary to know everything about each role: Permisions, tasks, tools available, and finally the kind of interaction with other roles. Therefore, as a first matter, it was necessary to isolate each of roles,  and then establish interactions between the other players.

Whole diagram of people & resources involved on the game execution.
Scenario preview

Phase 2: Flow charts

Once clearified the first requisites, a deep dive analysis was a must. To perform this step, I use Visio to create the flow charts.  

I spend more than one month to analyse, create and iterate on the flows, following this process:

Flow chart crteation process
Flow chart creation process
Roles involved on the game execution.

Flow charts final delivery

Flow chart of the whole Game made with Visio

Phase 3: Design + AS3 programming

Once flow charts were completed and accepted by the team, next step was the UI Design and ActionScript programming. For this purpose, Flash was the main tool used, likewise Photoshop for image retouching.

A fully "Class" and Object Oriented application, in which one I use some common library classes like Caurina in a quite extensively way.

Additionally, there is a txt file  which one contains the needed data: roles, flight name, speed, passengers, etc.

Login screen

Depending on the role, once the user is logged, a set of tools will be displayed. Likewise, the screen shown will be different of each role.

Login screen


The following screen is shown when a user is logged as MAN (Manager role).

The game manager is the responsible for starting and controlling the development of the game. If players have some problems during the development of the game or the have any question, the MAN has to help them advising about different possibilities they have or answering their questions. 
When he loads his personal screen the area of the game appears. His area is yellow and without limits of responsibility, because he is in charge of the development of the game, but not of analysing, proposing or implementing anything. The trajectories of the aircraft involved in the game appear as a green continuous line, except for aircraft in which an action can be performed; in this case the trajectory appears in red. Aircraft are represented by purple triangles, except the main one(s) which are red. Each aircraft has information about their parameters: flight code, FL and speed. Continue grey lines that are back of the map are the country boundaries of the territory.  

Manager role view

Interaction & tools: the core of the game

One of the most important issues in the game was the interaction between the players. Therefore, the tools were essential. 

Some tools such as Complexity Predictor, Swimm, Chat, among others were essential for detect possible problems and interact between roles.


The tools shown above, are related to Manager role.
Screen view of SRM role, with Complexity Predictor tool


The simulation Screen is where the roles can simulate different options in response to any problem related to capacity, complexity, safety, etc. 

Personally, this was the more complex part of the whole project due to simulation requires complex algorithms not only to change routes but to avoid collision. This was almost at the end of the project, and at this point an JAVA expert engineer joined the team, and he helped us to finish this complex part.

Login screen

Phase 4: Deployment on Flash Server 3.5

Finally the game was deployed by myself in Flash Server 3.5. Additionally 

The game of an open nature (Role), and considering that players were scattered across Europe, the game needed the doors open, but due to security internal network issues, this was a hard final. But finally, it was a success.