Saturated Outer Space is a game that combines space flights and tactical turn-based squad battles. The world exploration, search of alien artifacts, gathering and development of a unique team as well as battles in space and on the ground are waiting for you.

You are a squad leader, working for the galactic commercial rescue service. It’s up to you to decide where to go and whose distress signal to take: you can protect the colonists’ ships from the attack of space cannibals or defend merchants from pirate raids, save the settlers’ colony from biological threat or neutralize the AI gone out of control, dig out the asteroids or travel to the limits known space to discover new galaxy mysteries.

It depends on you how the story will develop, who will be your customer and how exactly will the open sector of galaxy change. SOS is a familiar fantasy in a new form, it combines freedom of actions, an extensive plot, interstellar flights as well as ground tactical operations.

The combat system consists of two turn-based types of fights, one takes place between spaceships on the star clusters background and the second suggest the sensitive guidance of each squad unit. During the game you will have to make difficult choices: to control several ships in battle or to slip quietly on one assault spaceboat, to get through the intricate corridors to silently disarm the enemy or launch an attack head-on right from the start of a level.

At this stage alpha-version* of project includes:

  • Three-dimensional environment in the Sci-Fi Style
  • Upgrading and development of squad members
  • Ability to assemble a fleet of spaceships
  • Turn-based tactical battles on ground and in space
  • Upgrading ships and customization of their appearance
  • Customization of team’s armor and weapons
  • Diverse factions with their own history, mission and features
  • Opponents combining different combat styles
  • Classes, skills, modules, properties, combinations, effects, ratings, and other elements of a tactical turn-based strategy!

“We ask the captain to come aboard, the cosmic adventures begin!”

* now we are working on the game internal logic and mechanics, but closer to the release will improve the graphics and effects.

  • View media
  • View media
  • View media
  • View media
  • View media
  • View media
Post article RSS Articles

Good day to you, People of the Earth!
The Rummy Games team is here, and this is another Developer Diary. Less than a week is left before the New Year, but we do not even think to rest: we continue to work on the project.

Igor Konyaev is back in touch with us again, this time he will talk about the main architecture of the game used for prototyping.
All further material will be presented on his behalf.

About myself
My role in the project is Technical Game Designer and Lead of the UE4 team of programmers.

About the project
Saturated Outer Space is a tactical turn-based strategy game with RPG elements. The game has 2 main gameplay modes: turn-based (like in XCOM) and real-time (like in Mutant Year Zero). I will speak about the game modes separately below. In addition to these two, the game also has a hub-mode between missions on a spaceship.

What I can share without claiming it to be an authoritative opinion
Experience in game prototyping using the basic "clean" architecture of the project. This is an approach when part of the game mechanics or game systems are prototyped in conjunction with the main architecture of the project. For example, programmers make a tile system of movement, lay down complex algorithms for finding a path and develop a system of abilities for characters, and a game designer, based on the interfaces available to him for low-level logics, can prototype new mechanics.

What is prototyping?
Prototyping is a broad concept, so in the context of this article I will divide it into 3 categories:

1. Environment prototyping.

Basically, it is the work with geometry in order to create the desired atmosphere at the level (level design);

2. Prototyping game mechanics.

This is the creation of those same attack or grenade throwing abilities for the purpose of testing them;

3. Prototyping game systems directly related to user experience (UX).

For example, the number of degrees of the camera spareness, its incline and height directly affect the user experience of the player.

These three categories are united by tight deadlines for completing the task and the goal of testing one or another game component directly in the engine in order to understand how viable the mechanics are on paper, and in real game conditions. Further I will describe 3 different cases that I had to face while working on a project, both from the programming and design points of view.

At the very beginning of the development of the main architecture of the game, which, according to the idea, should turn into a vertical slice, I was to describe the toolkit for creating level blockouts, relying on the fact that the game will have a step-by-step mode in which the rules of rigid binding of geometry objects to tiles must be observed. Looking ahead, I will say that we decided in the team to use a combined approach when creating blockouts. We combine geometry that is rigidly attached to the tile grid with geometry that does not affect tile navigation and the sight line (visibility) in turn-based combats:

Some self-test questions:

  1. What is the optimal tile size?
  2. What is the difference between "thin" and "thick" geometry?
  3. How to connect primitives on a tile grid and what kinds of geometry should there be?
  4. What is the optimal height for walls and doorways?

To find the answers, it took me a lot of time in various turn-based games, observing how the technical side of the game worked. This helped a lot to understand in which direction to go when creating the placement toolkit - adjusting the geometry on the levels. It was also important for me that some of the games in question were developed on Unreal Engine 4. If you have an understanding of how the engine works, it’s easy to catch common patterns and make sure that you are on the right path when developing, or not.

But let's get back to the questions. After studying several competing games, it was decided to create a tile with combined sizes and divide it into 2 areas:

Here the area circled in red (1m by 1m) available for placing units and geometry. Specifically for the unit, this zone is the maximum allowable size. This means that a unit can take cover only along the border highlighted in red, here you need to clearly understand what dimensions your characters will have. The open area between the blue squares (40 cm) is used to accommodate "thin" geometry. An example of placing "thin" geometry:

What is the difference between "thick" and "thin" geometry:

The good thing about "thick" geometry is that it can go beyond the blue tile and take up part of the unpainted area between tiles. In this case, you can avoid that the character sticks to the wall with a large gap, as here (the thin wall by default is devoid of these problems):

The conjunctions of geometry with each other now has a very simplified form, since the geometry toolbox uses primitives. Further, when using assets, a similar method of connecting objects will be applied:

A list of all possible geometry was also compiled: walls, columns, corners, doors, shelters, etc. General view of what was realized:

It is also useful to have a separate map on which all the same geometry objects will be located, but only in the form of a Box Brush. It helps a lot if you need to change the metrics of an existing geometry and create new static meshes.

The optimal height of the walls and doorways was the most difficult thing, since it was necessary to immediately take into account the height / width of the largest character in the game and the parameters of the camera (tilt angle and height). I will touch upon working with the camera separately. To measure the height, you can use different tools, some create special helper meshes that immediately have specific dimensions (1m, 2m, etc.). In this case, I used the tallest characters that were available, and an additional layer of a tile grid that can be raised to any height and get an overall picture of heights at all levels:

Let's summarize the level design tools. In our case, the tools were originally woven into the main architecture of the game, since it is very important to have a standardized level development system at the very initial stages so that level designers can immediately get used to the basic metrics. Almost all game logics are tied to the tile system; this is the foundation for the game. During the development of the tool we used only C ++, blueprints were used to quickly test some hypotheses, and after passing the Proof of concept stage, almost all low-level code was ported to C ++.

A short video demonstrating the work of the toolkit:

Prototyping game mechanics using the example of the ability to throw a grenade
Because the game is turn-based, it is difficult to separate the architecture from the prototype when prototyping. One should understand how this or that ability will work in a step-by-step environment, so the ability management system was originally built into the main architecture.

Let's look at an example where it is needed to prototype the grenade throwing ability. My approach is very similar to the one in the last paragraph. First, we look at the competitors and compare our understanding from the design document with how other developers solve a similar problem, after that we evaluate the possibility of rapid prototyping.
Questions for self-test:
1. What methods, events, variables or classes from the main architecture are available in the blueprints? How difficult would it be to build a small prototype into a large system? And does it make sense?

2. How will grenade targeting work? Usually this is a sphere, the targets of which are objects crossing it, or objects that are located on a conditional area with dimensions of 3 by 3 tiles;

3. Is physics of a grenade flight needed? What will be the behavior of the grenade when thrown? Will there be a collision with other objects?

The issue of embeddability is always individual, for this we try, whenever possible, to always open access to the logic that is written in C ++. In the case of the ability to throw a grenade, there are a number of methods that need to be redefined in blueprints, cause recognition of the target (an attack is possible or not), and apply the necessary modifiers (take away HP from the target and action points from the player's unit). It makes no sense to show the code, here the idea is only in the availability of low-level logics from blueprints. If prototyping mechanics takes an unreasonably large amount of time due to the fact that the programmer must be distracted from other matters by opening access to variables, then it makes sense:

  1. Prototype mechanics without touching the underlying architecture;
  2. Give the programmer the task to immediately build this mechanic into the code. Several times I heard from people that on their projects they have a team of cool programmers who write prototypes in C ++ even faster than a game designer can do on blueprints.

In my opinion, it is best to immediately write the code in such a way that in the future there will be as few places as possible where you need to put UPROPERTY or UFUNCTION.

In the current prototype, targeting works as follows. When a player levels the sphere of grenade throwing, then those targets that intersect with this sphere are highlighted, everything is simple here:

But there is an alternative way to select targets - tile highlighting, as it was in XCOM:

In the case of XCOM, only those targets that are on specific tiles will receive damage, but it will be visually clear that the grenade circle partially covers a few more tiles that are not taken into account by the system. Now we have made the first option, as it seems more understandable for the player, it does not contain empty spaces that are in the case of XCOM. But our option is poorly suited for weapons or tools that can apply or remove an effect from an area, or depend on the range of damage. For example, if a fire extinguisher partially cuts off fire tiles, it will look strange. On the contrary, a fire extinguisher that works like an XCOM grenade looks much more true.

Another step in the work on the ability of the grenade was to determine its behavior during flight. At the prototyping stage, it immediately became clear that the simulation of the physics of flight was not needed at all due to the fact that the battle was always turn-based. It was enough to calculate the flight trajectory for the grenade and make it off the hand at the moment of the throw. Then the animation of the flight through the timeline will do everything by itself. When the grenade reaches the end point of the trajectory, an explosion event is triggered:

The bottom line for prototyping game mechanics:

  1. Do not neglect the main architecture of the project, sometimes it is vital to test mechanics in real conditions, and not in an isolated environment;
  2. If possible, try to open access to as many game logics as possible if you use blueprints for prototyping;
  3. Estimate the real need for things like physics or realistic destructibility. This is expensive and the gameplay value can be zero.

Camera prototyping
I must say right away that today we have 2 cameras. Each camera is tied to its own game mode and has a top-down perspective:
Camera for turn-based combat. Flies around the map freely, is not attached to characters;
Camera for real-time mode. Attached to the selected character, limited in tilt, free rotation around the Z axis. The most relevant examples are Mutant Year Zero or Divinity Original Sin (playing with a gamepad).

Again, I'll start by seeing how the camera works for others. What is in the design document may run counter to the gameplay.

As a result, for real-time mode, almost the same angle and camera height was chosen as in MYZ, the camera was fixed above the selected character to increase immersiveness, and the tilt was completely limited to exclude flights through geometry and the desire to look at the ceiling. For battle mode, the camera is currently identical in parameters.


The results of the camera prototyping strongly affected the level metrics. The base geometry dropped from 5m to 3.6m. You can compare how different the geometry was before and after finishing the work on the camera.



Next, the work is planned on the multi-layered geometry, which will be hidden depending on where the player is looking.

From my own experience, I can say that you can successfully combine the main architecture with prototypes, the balance between the labor costs of a game designer and a programmer who will prepare the infrastructure in the form of tools and API is important. Once again, I repeat that in the case of our project, this is necessary, because gameplay mechanics are inextricably linked with step-by-step (the rounds system) and a tile grid, and it is inappropriate to let the game designer prototype such things separately due to their complexity.

That's all for now. Feel free to comment and rate this diary.
If you are interested in the project, subscribe on social networks and add the game to the Steam Wishlist.

See you next time!

Also, visit our website and subscribe for news and updates.

Don't forget to check out our Steam page and add the game to your wishlist!

Us on Twitter - @mvmvgames
Us on Reddit -
Us on VK -

Dev Blog - Sound Design For Characters

Dev Blog - Sound Design For Characters

News 1 comment

Greetings! This is Rummy Games with the new Dev's Diary. This time we are sharing the interview with our sound designer — Ruslan. He is going to tell...

S.O.S.: New Build Changelog — October 2020 & Trailer

S.O.S.: New Build Changelog — October 2020 & Trailer


This latest version of October 2020 includes major changes that we have been working on for the last summer.

SOS project

SOS project


Saturated Outer Space - turn based tactical Sci-Fi game.



Reply Good karma Bad karma+2 votes
Rummy_Games Creator

Thank you^^

Reply Good karma+1 vote

Thank you so much for telling us about the good rummy game software, this article is very useful for us.

Reply Good karma Bad karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.

Follow Profile
Saturated Outer Space
Developer & Publisher
Rummy Games
Send Message
Release date
Game watch
Single Player

Latest tweets from @mvmvgames

Special guest star of our Live-Show - Elliott Verbiest from a KING Art Games developing Iron Harvest. Watch on YouT…

Jun 29 2021

Steam Next Fest is about to end. Have you tried out our demo? If not then don't waste your time and download the ga…

Jun 19 2021

RT @mvmvgames: Всем привет! Рады сообщить о запуске нашей VR игры Dixotomia! Dixotomia - динамичный VR-шутер в Sсi-Fi сеттинге,…

Jun 3 2021

Всем привет! Рады сообщить о запуске нашей VR игры Dixotomia! Dixotomia - динамичный VR-шутер в Sсi-Fi сеттинге,…

Jun 3 2021

Don’t forget that today we have our live stream At 19:00 MSK (16:00 UTC) with our special guest Link:…

May 26 2021

Special guest star - Tobias Stolz-Zwilling from Warhorse Studios who created Kingdom Come: Deliverance. Watch on Yo…

May 19 2021

Embed Buttons
Link to Saturated Outer Space by selecting a button and using the embed code provided more...
Saturated Outer Space
Last Update
5 members
You may also like
Deadlock II: Shrine Wars
Deadlock II: Shrine Wars Turn Based Strategy
Armada 2526
Armada 2526 Turn Based Strategy
Lost Empire Immortals
Lost Empire Immortals Turn Based Strategy
DUAL GEAR Turn Based Strategy
Xenonauts Turn Based Strategy
Sword of the Stars
Sword of the Stars Turn Based Strategy