Reign of Guilds Windows game

Greetings, Friends!

We feel sorry for our previous report was in the depths of winter while the current one is in the middle of spring. This happened for a number of reasons and we talked about them several times.

Also, we would like to offer our apologies for leaving our social channels desolate, but we set the priorities differently right now.

We raised the issue of nominating emissaries from the community, who would get the rights of moderators in certain social networks and at the forum.

It is also worth noting that currently the reports no longer precede the patches and they even began to fall behind.

Now about the actual report. Here is its structure:

1. Mobs;
2. [AI 2.0] Technical novelties;
3. [AI 2.0] The principles of the model;
4. Landscape materials;
5. Models, icons, items;
6. Patch;

I Mobs. The deer

We have completed the works on coverage of the animal with fur, as well as a series of animations for it.

This is how the deer looks like with the fur:

This is how it gets up after rest:

And this is how it runs:

Next time there will be a new wolf, birds, and then animations for all the mobs of animal origin.

II [AI 2.0] Technical updates

2.1 Spawner

In its initial edition, the spawner could spawn and remove mobs at one distance between the player and a spawning point only. As a result, we needed to significantly increase this distance in order to make the appearance/disappearance of mobs go unnoticeable.

We decided that this was not acceptable and here is what we did:

There are 3 zones:

1. Zone #1 is where the mobs appear in;
2. Zone #2 is within a certain distance from the player (the first one who has entered it) at which the spawner gets triggered. At the same time, one won’t be able to carry the mobs away further than this distance from their spawner.
3. Zone #3 is where the mobs are removed (when the last player leaves it).

Zone #2 is always bigger than Zone #1 by approximately 50-100 m. Zone #3 is always bigger than Zone #2 by about 25-30 m.

This allows us to exclude the possibility of spamming when mobs appear or disappear in the spawner.

To illustrate the point:

2.2 Field of view

We added a parameter called “field of vision” to mobs that works according to intuitively clear principles (angle of view and distance).

Meanwhile, the distance doesn't always imply triggering a reaction. A mob may see you but it won't react if you are too far.

Currently, the angle of view for everybody is around 150 degrees.

This is how it works:

III [AI 2.0] The model principles

Initially, we planned to create several pre-made roles and characters for the AI in order to achieve diversity with the help of combining them. In the end, we made a system that works slightly differently:

• actions, triggers for the actions, and tags;
• it allows us to achieve more diversity;
• But it is more cumbersome for making since the templates must be made from zero;

This system received an internal title ATT (Actions, Triggers and Tags respectively). We will start in reverse order since the tags are characteristics of the triggers, and the triggers launch the actions.

Tags

To say it differently, a tag is an object that is traced by the AI. Such a characteristic can be either static or dynamical. This static type is set for all the time, and the dynamical type is required due to one or another action of the object.

Example:

Each character got a static tag "Player". A dynamical tag that can be either "aggressor" as one who has attacked another player, "PK" as an assassin attributed to karma, ''owner'' as an owner of a summoned mob, and so on and so forth.

Triggers

This is a certain rule, in essence, aimed at an object. Its execution triggers one or another action.

There are several categories of triggers:

• Within the field of vision (if the specified tag gets into the field of vision, and then the change of action occurs);
• Outside the field of vision (if the specified tag disappears from the field of vision, then the change of action occurs);
• Influence (here is no rigid attachment to a tag, but it is based on the influence on a mob. For instance, if it gets damaged by someone, then the change of action occurs)
• Deferred (there is no attachment to a tag either but it is for a change of action after timeout plus flexible value)
• Within an area ( the change of action occurs if the distance to a tag is less than N meters)
• Outside an area (the change of action occurs if the distance to a tag is more than N meters)

Actions

This is the most interesting part. We outlined the following main actions, that can be executed by the AI:

• Idle is static or dynamical action with periodic execution of other actions specified at specified points;
• Follow a tag;
• Flee from a tag;
• Patrol along specified waypoints in free order or along a strictly specified path;
• Attack a tag is for close-quarter combat or ranged combat, as well as rules of transition between them if the AI can use two types of weapons;
• Defend from a tag. It can be used automatically. However, initially, it was intended for the transition between the attack and the defense to form combat tactics (search for the middle ground between the attack and the defense-in-depth);
• Search for a tag within a specified area for an amount of time or a number of times if it has disappeared from the field of vision;

We call with technical actions those actions that won’t be used as-is:

• Receiving damage from a tag;
• Move towards some object on the map (don't confuse it with the tag that is attached to living things);

The most simple example:

We set the following parameters for the Stickman:

• Remain idle inside a specified area, choose places for rest;
• When it sees the player, it gets alert and returns to idle state;

• Attack if the player is within 5 meters;

We will continue providing examples in the upcoming reports. You may estimate by yourself the number of ATT combinations for a realization of this or another character and role.

IV Landscape material

This is a technical improvement aimed at minimization of falling of feet through the 2.5D material.

In essence, we added a function to offset the visual surface with respect to the surface used to calculate collisions:

After that, we fitted an individual offset for each surface on the technical level.

By the way, now you got an idea about what type of layers the landscape has:

V Models, icons, items

We completed the remaster of materials and textures for all existing by now models of armor, clothes, and accessories.

We would like to remind you what we imply under the remastered is the improvement of texture processing procedures with materials, as well as the introduction of new textures that help us make the parameter ''ragged'' working.

This is how it looks:

Basic variant / remastered / remastered + rags

During the remastering, we paid sufficient attention to the optimization by working with the main parent material and its ''child'' material instances. This procedure decreases the number of rendering calls by executing essentially the same function but plugging new parameters in it.

Further, we automized the procedure of rendering icons (for the inventory) for items. Also, we made the icons look cooler and less flashy by removing excess light sources. The main thing is that we don't have to do anything manually anymore apart from setting some parameters and launching the algorithms.

Icons “before” and “after”

In the end, these are all ready icons by now:

Almost all updated models and created icons are used by new items and were added to new vendors on the PTR server.

VI The Patch

On 10/02/2020, we uploaded the new version labeled as ''0.50.107'' on our server. This means that we got past half of the way towards the release of the finished project.

The main obstacle that separated us from 50% of completion is this AI 2.0 which we are talking about here and we'll be talking about in the next several reports.

Apart from the AI 2.0, the current update consists of:

1. The server time in connection with the TrueSky, updated to version 4.2;
2. We optimized the basic usage and leakage of RAM memory;

1. We added game items that we told you about in section 5 of the report;
2. We created LODs for all pieces of armor and clothes. The LOD system not only simplifies the model geometry, but it disables the clothes physics as well as makes materials drop unnecessary textures;
3. We expanded and actualized the graphical settings. At the moment, they not only help one with the optimization but are suitable for stylistic settings like disabling bloom and blur, etc.;
4. Numerous bug fixes;

VI Conclusion

First, we'll tell you about our plans. This means everything that you'll see in the future reports:

• As far as programming is concerned, we finalized the AI 2.0 and returned to SpatialOS. Essentially we're stuck in between
• The desire to move the Alpha version into scalable Google servers in the could (i.e. to the SpacialOS system)
• The heavy work-load of the transfer process, when we have already created the foundation for our own seamless solution
• About the game design
• Work on the AI 2.0: introduction of existing mobs and creation of their own DTT parameters for them;
• The actualization of items on the PTR server;
• About the technical design
• Continue working with the TrueSky within the framework of bug-fixing resulting in a crash on several devices;
• Implementation of HLOD for large locations;
• Setting and polishing of parameters for “level loading” in order to minimize encountered freezes
• About the level design:
• We plan to make a small arena with convenient places for respawn and introduce simple rules that will lay in the foundation of the advanced arena (like the school of gladiators);
• About the models and animations:
• Finish with mobs of animal origin (wolf 2.0 and birds);
• Move on to undead as the most lagging behind group of mobs;
• After that, we will return to the much-needed models of armor for the professional school

? Questions to readers ?

There is quite an interesting and urgent question about the core gameplay. The general outcry from new players newbies regarding the matter makes it a very relevant topic.

Although many from the ROG club and those who witnessed the prototype know that:

• The ROG is designed for the first-person experience in mind
• The existing game mode from the third person is limited in combat encounters, i.e. it's forbidden to use a weapon when switching to the third person view
• The vanishing hot-bar and buff-bar remind of mode’s limited functionality
• By the way, the behavior of the third-person camera was initially protected by us from the abuse when trying to sneak behind the walls;

So here's the question: what do you think about allowing one to play the game from the third person with full functionality, but one has to sacrifice something for it. For instance, it may work only as a buff, i.e. it will occupy one slot out of seven available ones?

Since we all know very well that a player in the third person gets a big advantage with FOV although he loses certain things when sensing the distance to the target (even if one uses a scope that gives hints by changing its shape).

This common for many players third-person view mode with the FOV advantage will occupy such a precious for PvP buff slot.

The zoom distance of the camera can be made dependent on the number of slots that the buff occupies.

This is all for now!