← Back to home

Project archive

Final Exodus chronicle

Development posts collected in one place. English translations are added after review; each entry links to its Facebook source.

Translated from Russian

We may be able to hire for the project

It's too early to say for certain, but our project may receive funding, which would let us hire several people for permanent work. For money. Real money. Cash. Dough. Moolah. The work would be in an office, with some opportunity to work remotely. So if any of you are 3D artists using any capable software, get in touch. We need models. Lots of models, varied and interesting ones. We're also looking for a programmer who works in C++ or understands Unreal Engine. Both would be better, of course. The expected start of work is autumn 2022. But we can begin the preparations now. So, is anyone here interested in working on game development?

Read post ↗
Translated from Russian

Should we move the project to Unreal Engine 5?

Well... Probably only someone very far removed from games hasn't heard of Unreal Engine 5. As someone who works in this field, I can tell you: this is a revolution. Nothing less. Unfortunately, the system requirements are rather specific too, but in a couple of years they'll be mainstream. A great deal has changed for developers. Things that were impossible or extremely difficult have suddenly become accessible. Why do you think so many games don't let you move the camera closer to a character than a preset distance? Because you'd see uneven geometry, blurry textures, and so on. Now that problem is gone. You can make a model as complex as you like, but only what can be seen, given the monitor's resolution, will be processed. That sharply reduces the amount of computation required. UE5 does it automatically and in real time. Textures are a similar story. You can even work without tessellation and related techniques. You can represent a rock's uneven surface directly in its geometry, and it will work. There's no longer a need to optimize an artist's high-polygon 3D model into a low-polygon one for the game. Additional details will appear naturally as you approach, while resources won't be wasted rendering invisible detail at a distance. There's a whole lot more about lighting, map size, and other important things, but that's not what I'm getting at...

Read post ↗
Translated from Russian

Aspect-dependent radar signatures and physical ship control

An interim update, since I worked over the weekend too. Radar cross-section now changes with viewing aspect. Roll isn't accounted for yet, but that's a detail; the foundation works, and works well and correctly. Handling roll is a matter of a couple of formulas with sines.

Read post ↗
Translated from Russian

Active radar detects another player's ship

What do these unremarkable pictures full of primitive shapes show? Three clients playing at the same time on one shared level without seeing one another. More importantly, though, the radar does see them! In the first image, at the top left, you can make out a pale greenish rectangle. In the lower image, you see a triangle, or rather a pyramid from the side. Both are the same thing: the active radar's scanning sector. In the first image, it seems to point into empty space with nothing there. But that isn't so. An enemy ship is hiding there, as confirmed by the pink message reporting one detected target.

Read post ↗
Translated from Russian

Showing players only the ships they have detected

What I accomplished this week. I spent a long time fighting with a task that seems simple but is difficult within a networked architecture: letting a player see their own ships without seeing anyone else's. The nuance is that every player has a separate list of ships, and that list can change dynamically during play. The hardest part, though, was that the ship data is generated in one part of the code, linked to another and transferred there, then moved to a third part, from which it interacts with elements in the first. After all that, it creates an individual view on each client without falling out of sync with the server or other clients. Why is this necessary? To simulate detecting an enemy and obtaining accurate data about them. Here's a counterexample from EVE Online. You can see enemy ships. SEE them. But your system has to lock them before you can fire. Without a lock, you're out of luck. Weak justifications for this don't survive contact with realism. If you can clearly see a target through an optical channel and have measured the range with a laser, you can fire. Moreover, if you see the enemy ship's type and know its dimensions, its angular size already lets you determine the range fairly accurately without any rangefinder. You have all the data needed for accurate fire. You can also see the target, understand its maneuvers and position, and anticipate how the situation may develop. In short, this is a major game convention, like aiming dispersion in World of Tanks. To avoid that problem, you'll see the enemy ship's complete model in its true position only when your ship's sensors have detected it conclusively, assuming those sensors exist and work. For most weapon systems, that already provides enough data to calculate a firing solution.

Read post ↗
Translated from Russian

Multiplayer finally works as intended

Important. Until now, many parts and elements of the game had been built in solo mode, so to speak. When I launched it in networked mode, everything was either bad or strange. Some things moved; on others, the model moved while its underlying object stayed put. Something would stand still on one screen and move, though only partly, on another, and so on. This came from my lack of understanding of the engine's networking, my hope that someone else would take responsibility for that part, and my knowledge that I'd eventually have to redo things. But I couldn't stand still just because a couple of important elements were beyond me, so I kept working.

Read post ↗
Translated from Russian

A correction to the first-flight timeline

In our slowly developing political game, we had stopped at the first flight and the formation of coalitions. There is an important change. I spoke with and brought a genuine specialist into the project: an engineer who has worked in the space industry for almost 20 years and still does. After consulting him, I realized that my estimates for the shuttles and Buran 2 were correct. But I had not accounted for the Soyuz spacecraft and how quickly they might be modified. So there is a small step back in the flight timeline. It is not certain that the Americans will fly first.

Read post ↗
Translated from Russian

Volunteers wanted to test the simplified mobile version

Right then. Who wants to help test? We are building a simplified version for mobile platforms—a very simplified one, by about 85%. Essentially, it contains only space combat and the economic elements needed for it. But it could bring in at least some money for developing the main version. Soon we will need to test the server connection, login, password, and the rest. Volunteers, please report in!

Read post ↗
Translated from Russian

Seven minutes of terror

Seven minutes of terror for our nerves during the rover landing. CONGRATULATIONS! It landed perfectly. There was a 25 percent fuel reserve when the sky crane separated. The speed of events and the precision were unimaginable. We have learned to build amazing things!

Read post ↗