Project Overview
CoReSys is a combat simulator for tabletop RPGs that allows the user to create an intuitive and easy to use app to allow users who love tabletop games to create their own combat resolutions, mechanics and systems and test it out in a 3D environment.
​
The app was created in a custom engine over a period of 10 months as our project for GAM300/350.
​
Members:
Producer - Jean Lim
Technical Lead - Cantius Chew
UI Programmer - Huang Xu Rong
Graphics Lead - Linus Ng
Graphics Programmer - Jerome
Graphics Programmer - Darren Lim
Design/Art Lead - Michael Seah Jin Han
Designer - Woo Seik Yee
Designer - Denny Liong Yong An
Trailer
Design Process
In order to address the main problem statement of our app, which was to ease the learning curve of the of common tabletop RPGs, it was important to break down the common mechanics into sizeable chunks that is easier for the user to digest. The first step was to start by creating the overall design flow of the app and deciding what kind of pages we should have. Then we started fleshing out these pages and linking them to each other. We chose a hub-and-spoke design for our main menu.
Overall UI flow of the app
After finalizing the flow of the app, we then expanded on each page further by fleshing out their intended functions such as conflict resolution, simulation, unit creation, etc. It was important that even a first-time user would be able to understand the function of the page at first glance.
Functions of each page
Start Screen / Main Menu
When creating a new project, users can select from templates that contain the mechanics of existing tabletop RPGs such as GURPS or D&D as well as a tutorial project that teaches them the basic functions of the app. They can then select pre-built maps as well.
.png)
The overall main menu and start used used a hub-and-spoke as its navigation model between each screens.
Conflict Resolution Creation
The actions/sequence page, where the user would be able to create their own actions and sequences, proved to be the most challenging to create. Due to the flexibility and complexity of tabletop mechanics, this element was the point that drove people away from learning about table games because of its time consuming preparation as well as steep learning curve.
it was important that we were able to accommodate at least the most common combat and resolution mechanics such as Dice Rolls, Modifiers and Stats while making the whole process understandable and easy to use.
​
We broke down the page into its most basic components to simplify or to remove any unnecessary elements, and then reorganizing them into more coherent flow.
Early flow of actions and sequence pages
An example of an action and sequence flow
Actions and Sequences
The actions/sequence page, where the user would be able to create their own actions and sequences, proved to be the most challenging to create. Due to the flexibility and complexity of tabletop mechanics, this element was the point that drove people away from learning about table games because of its time consuming preparation as well as steep learning curve.
it was important that we were able to accommodate at least the most common combat and resolution mechanics such as Dice Rolls, Modifiers and Stats while making the whole process understandable and easy to use.
​
We broke down the page into its most basic components to simplify or to remove any unnecessary elements, and then reorganizing them into more coherent flow.
.png)
.png)
Conflict resolution prototype screens
After much testing and discussion, we decided that the best way to solve this problem would be a visual approach rather than text-based. Using examples of Unreal Engine's blueprint scripting, we created nodes that represented different functions that can be linked together in order to dynamically recreate the desired mechanics of the user.
​​
Example of an Unreal Blueprint
For example, to create a simple attack mechanic, the user simply needed to create an an attack node referencing its owner's attack(whoever that is using that attack) and link it to a dice node, followed by a modifier, leading to the following result:
​
​
Get Attack Stat(Owner) -> 6 Sided Die Roll -> Modifier -> Output
​
This allowed us to easily recreate from the simplest to even the most complex mechanics by combining these nodes together to form the end result.
​
The sequence, which is the flow of actions in a tabletop RPG, followed a similar process to the action, except that it used entirely different nodes. An example of a simple sequence would be to:
​
Resolve Attack -> Resolve Defense -> Compare both results -> Win if attack is higher or equal / Lose if attack is lower
Example of a simple attack action
Final Editing Sequence Screen
Simulate Screen
The simulate screen is the main screen in the conflict resolutions page. It allowed users to test their actions directly by producing a chance of success between different units, actions, weapons and a selected sequence. They can also adjust the frequency of the sample size, increasing accuracy of the results.
Prototype 1
Prototype 2
Prototype 3
This page was also challenging to design due to the number of elements in the screen. It was important to keep the page intuitive while performing its intended function correctly. The chance of success was the most important element in the screen as it was the feedback to let the user know if their actions were working as they intended or if it needed adjustment.
Final Simulate Screen
Editing Unit Screen
Editing Unit screen allowed players to create and edit units for their conflict resolution. Players can create and edit stats as well as assign weapons and skills to the units they create. They can also define their own stats according to their tabletop RPG.
Prototype Edit Unit Screen
The finalized screen displayed the the list of units that the user can easily access on the left side of the screen. The stats, weapons and actions have been split into tabs, allowing the user to quickly scroll through his characters or to create new ones easily.
Finalized Edit Unit Screen
Turn Order Screen
The turn order screen appears before the start of a game. Players can add their selected units into the game as well as customize their turn order randomly, according to stats or manually.
Prototype 1
Prototype 2
The finalized screen refined the UX flow of the page and required users less steps to accomplish the same goals by cutting down pages and merging their functions into a single page.
Finalized screen 1
Finalized screen 2
Post-Mortem
What have I learnt?
This was my first time leading a project as a design and art lead, and I had to make many decisions that I was unsure of, but I was still happy with the outcome in the end as we were able to achieve the goal of the project that we set out to do. I have also learned how to work together as a team with my project mates and the importance of the use of tools to communicate my ideas and concepts to the team.
​
​
What went right?
​
-
As both the art and design lead of a project for the first time, I was able to make decisions that I think led to a successful outcome of the project.
-
Despite being a small team and some of us being new to the team, we were able to communicate and work well together.
​
What went wrong?
​
-
As the only designer and artist during the first half of the project, the work and responsibilities were a bit too much to handle, leading to me not being able to properly design all the intended features.
-
Digitalizing a traditional pen-and-paper game proved to be more complex than I initially thought and I was not able to fully accommodate for all the mechanics.
-
A lack of any similar projects to use as an example or reference meant that we had to think of solutions to problems that have never been encountered before.
​
​
​