Good day to you, People of the Earth!
The Rummy Games team is here, and this is another Developer Diary. Less than a month 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.
Metrics
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:
- What is the optimal tile size?
- What is the difference between "thin" and "thick" geometry?
- How to connect primitives on a tile grid and what kinds of geometry should there be?
- 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:
https://youtu.be/b13vls81NeI
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:
- Prototype mechanics without touching the underlying architecture;
- 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:
https://youtu.be/YHo3zt3OYB8
The bottom line for prototyping game mechanics:
- 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;
- If possible, try to open access to as many game logics as possible if you use blueprints for prototyping;
- 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.
Before:
After:
Next, the work is planned on the multi-layered geometry, which will be hidden depending on where the player is looking.
Outcome
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!
Us on Twitter - https://twitter.com/mvmvgames
Us on Reddit - https://www.reddit.com/user/mvmvgames
Us on VK - https://vk.com/saturatedouterspace