Hello all, it’s Cassel, developer of <Ratopia>
On the last time, I’ve talked about the title screen.
Continue with it, I’d like to talk about how the UI designs changed.
When we were developing <Ratropolis>, our previous project,
we were struggling to find out which of the UI styles is the best to use.
Back then. we had to go through many cycles of trials and errors.
For this time, we knew already that we would go through such process again,
So instead of debating about the better style, we’ve just began to design the UIs.
Changes of leader selection page in <Ratropolis>
UI concept arts and mockup
In <Ratopia>, UIs were needed to be designed casual enough to match with the game characters.
So we tried bitten-up cheese-like shapes were used to give cartoonish impressions.
The concept looked fine, until we realized that even the UI functions were not designed yet.
We were unsure what kind of function would be put in the later game, so we’ve decided to make a concept design,
following the game we were inspired of: <Oxygen not included>.
Conceptual UI are to check broad direction for the designs
Soon we realized that the cheese designs which looked great was not usable.
Readability was not good enough, UI resources’ sizes varied too much,
we would even say that the functions were eaten up by the concepts.
In addition to that, though they were too much time-taking works,
they were not versatile to be used on the other parts of the game at all.
Realizing the difficulty of designing what we imagined,
we’ve decided to postpone the work until the actual functions installed.
More we develop the game, additional problems got revealed.
Before, <Oxygen not included> and <Rim world> could be a possible option we thought.
But those two are designed to play with mouse, but ours is not.
Since our intention was to make the game fully workable with gamepads or with keyboard only,
so their designs were not applicable in many cases.
We had to check the other games at this moment.
<Dragon Quest Builders 2> for instance, is a game with a lot of similarities.
They both are sandbox genre game with a playable character, and casually styled.
So we could learn a lot from it.
In addition to that, we could find some samples on the website, "https://www.gameuidatabase.com"
With those, we could make a new mockup UIs in various functions.
Early mockup designs based on learnings
Optimizing UI design process
With mockup and dummy images, we could speed up the development.
But with no decorations and effects, they were certainly looked crude.
Thus we’ve began to make UI resources based on the mockup designs.
Changes in sizes of the UIs happens a lot as we all know.
So we thought, if we cannot prevent it from happening, at least make it easy to be modified.
We agree that using various designs would surely make the game visually satisfying.
However, this will take quite a lot of data memories,
and has high possibility to take time to be redesigned when the layout changes.
Thus we’ve united the image styles of buttons and slots, used nine-patch, patterns,
and shader to make the basic UI resources that can be used in many situations.
Cut and stitch a large image to use in various UIs!
This was efficient for sure, but was a bit monotonous.
To solve this, we’ve tried to put lively UI animations.
Bouncy animations!
This looked great but when to apply, all of the UIs were modified so often.
If we were to add animations on the A screen, then B had to be changed too.
But when we were applying those on B after A, then A’s format changed,
and animations had to be applied again on A, the infinite cycle!
Simple changes could result a huge time-taking work.
And It was also uncertain whether the change would improve the UIs functionality for sure.
Thus we’ve decided to postpone the implication of changes until when there is showcase, or demo release kind of activities,
in a measure that then the testers would play with UIs with same rules,
and we can save time for the changes.
This decision also lessened the stress because no more repetitive applying and fixation were required.
It was sure easier, I believe, but it was not that easy.
It does is a lessening the waste method, but the changes will wave like tsunami in the end.
So it was important to set rules step by step to be prepared for the changes.
The rules are mostly about setting the standards, or effects, icons, highlight, and animations.
They would work as tetrapods later.
Specification of the rules on designing UIs
Even we’ve made the rules and tried to keep, we could not 100% follow the rules.
The main reason was quite humane;
the artists, programmers, and designers had differences in needs and priorities.
Because of that differences, dummies out of the rules were added way too much,
And as we get used to those dummies, we were losing the needs of improvements.
This was resulted from the minds that ‘It will be changed later so let’s just put in in’,
and in some cases the rules were not set yet so had no choices than improvising.
The rules had to be renewed and we all had to get a habit of following it,
and this process is still on-going.
Still there is a long way to go on developing <Ratopia>.
Unlike the previous topics on DevDiaries,
this time we do not have a specific solution that we can proudly present.
And this is a still an ongoing issue we are figuring out.
But I saw many great changes happened in the other games.
So I am hoping that our game changes drastically for a better performance.
The UI renewal of the game <Foundation>, making the game brand new.
DevDiary 12 is done here.
For the next time, I'll write about research system of the game.
Thank you so much for reading this long article again.
Hope you have a great month!
Hello all, it’s Cassel, developer of <Ratopia>
On the last time, I’ve talked about the title screen.
Continue with it, I’d like to talk about how the UI designs changed.
When we were developing <Ratropolis>, our previous project,
we were struggling to find out which of the UI styles is the best to use.
Back then. we had to go through many cycles of trials and errors.
For this time, we knew already that we would go through such process again,
So instead of debating about the better style, we’ve just began to design the UIs.
Changes of leader selection page in <Ratropolis>
UI concept arts and mockup
In <Ratopia>, UIs were needed to be designed casual enough to match with the game characters.
So we tried bitten-up cheese-like shapes were used to give cartoonish impressions.
The concept looked fine, until we realized that even the UI functions were not designed yet.
We were unsure what kind of function would be put in the later game, so we’ve decided to make a concept design,
following the game we were inspired of: <Oxygen not included>.
Conceptual UI are to check broad direction for the designs
Soon we realized that the cheese designs which looked great was not usable.
Readability was not good enough, UI resources’ sizes varied too much,
we would even say that the functions were eaten up by the concepts.
In addition to that, though they were too much time-taking works,
they were not versatile to be used on the other parts of the game at all.
Realizing the difficulty of designing what we imagined,
we’ve decided to postpone the work until the actual functions installed.
More we develop the game, additional problems got revealed.
Before, <Oxygen not included> and <Rim world> could be a possible option we thought.
But those two are designed to play with mouse, but ours is not.
Since our intention was to make the game fully workable with gamepads or with keyboard only,
so their designs were not applicable in many cases.
We had to check the other games at this moment.
<Dragon Quest Builders 2> for instance, is a game with a lot of similarities.
They both are sandbox genre game with a playable character, and casually styled.
So we could learn a lot from it.
In addition to that, we could find some samples on the website, "https://www.gameuidatabase.com"
With those, we could make a new mockup UIs in various functions.
Early mockup designs based on learnings
Optimizing UI design process
With mockup and dummy images, we could speed up the development.
But with no decorations and effects, they were certainly looked crude.
Thus we’ve began to make UI resources based on the mockup designs.
Changes in sizes of the UIs happens a lot as we all know.
So we thought, if we cannot prevent it from happening, at least make it easy to be modified.
We agree that using various designs would surely make the game visually satisfying.
However, this will take quite a lot of data memories,
and has high possibility to take time to be redesigned when the layout changes.
Thus we’ve united the image styles of buttons and slots, used nine-patch, patterns,
and shader to make the basic UI resources that can be used in many situations.
Cut and stitch a large image to use in various UIs!
This was efficient for sure, but was a bit monotonous.
To solve this, we’ve tried to put lively UI animations.
Bouncy animations!
This looked great but when to apply, all of the UIs were modified so often.
If we were to add animations on the A screen, then B had to be changed too.
But when we were applying those on B after A, then A’s format changed,
and animations had to be applied again on A, the infinite cycle!
Simple changes could result a huge time-taking work.
And It was also uncertain whether the change would improve the UIs functionality for sure.
Thus we’ve decided to postpone the implication of changes until when there is showcase, or demo release kind of activities,
in a measure that then the testers would play with UIs with same rules,
and we can save time for the changes.
This decision also lessened the stress because no more repetitive applying and fixation were required.
It was sure easier, I believe, but it was not that easy.
It does is a lessening the waste method, but the changes will wave like tsunami in the end.
So it was important to set rules step by step to be prepared for the changes.
The rules are mostly about setting the standards, or effects, icons, highlight, and animations.
They would work as tetrapods later.
Specification of the rules on designing UIs
Even we’ve made the rules and tried to keep, we could not 100% follow the rules.
The main reason was quite humane;
the artists, programmers, and designers had differences in needs and priorities.
Because of that differences, dummies out of the rules were added way too much,
And as we get used to those dummies, we were losing the needs of improvements.
This was resulted from the minds that ‘It will be changed later so let’s just put in in’,
and in some cases the rules were not set yet so had no choices than improvising.
The rules had to be renewed and we all had to get a habit of following it,
and this process is still on-going.
Still there is a long way to go on developing <Ratopia>.
Unlike the previous topics on DevDiaries,
this time we do not have a specific solution that we can proudly present.
And this is a still an ongoing issue we are figuring out.
But I saw many great changes happened in the other games.
So I am hoping that our game changes drastically for a better performance.
The UI renewal of the game <Foundation>, making the game brand new.
DevDiary 12 is done here.
For the next time, I'll write about research system of the game.
Thank you so much for reading this long article again.
Hope you have a great month!