An update. We plow, sow, and harvest, even on weekends.
An important achievement:
I managed to establish a persistent two-way connection between client and server, exchange data, and, above all, process it! The connection existed before, but it didn't always do what was needed, and the implementation was awkward. Now it is stable. Every 20 seconds, client and server exchange heartbeat packets to check that both sides are alive. If things go well, I'll add database access today, and login and registration will actually work, for real. The forms and client-side logic are already ready.
I've begun assembling the final project from prototypes built in previous years. It will certainly be rather rough, but it will work. The video shows the star map needed for interstellar navigation. Look at the scale. If the hardware can handle it, I may expand it to 200,000 stars. Before optimization, it could barely handle 20,000, and the frame rate was about 5 fps. After optimization, 45,000 run smoothly. That is my entire previous catalog.
By the way, if anyone wants to help with the code, there's an easy way. Install Unreal Engine from the Epic Games Store, make an empty project, create a new Blueprint, and select a function library. You can then make all kinds of functions with input and output pins. It's all visual, using graphs. You don't need to write a single line of code.
News. During the previous off-season I worked on ship combat. Now I'm returning to the economic, strategic, and logistical side. Until now, I knew that the server interactions needed for the economy could somehow be built in the engine, but I didn't know exactly how. The problem is that the engine is essentially designed for session-based connections: a group of players has a game room, everyone runs around in it, and one computer acts as the server. There was physically no complete, or even rudimentary, interaction with a server capable of keeping every player connected and serving them information from a database. Some workarounds were possible, but the result would have been poor.
So where are we? I had to devote November and December to our company's work. We do have to earn a living. Right now I'm quickly building a platform game and will put it on Google Play, again hoping to bring in some money. We'll see.
In about a month or two, we'll finish our current writing project and start work in earnest on the main book in the Exodus series.
Since a game called Exodus was recently released, a science-fiction story-driven shooter, by the way, we'll rename our project Last Exodus or something similar.
I moved to engine version 5.3. What does that give us? Size. With 32-bit coordinates, we had roughly 2,000,000,000 units. If one unit is one centimeter, the map spans 20,000 meters, or 20 kilometers. If one unit is a meter, that's 2,000 kilometers. That can work for a local space battle, but accuracy is then only one meter, which is too coarse. In version 5.3, among other things such as support for the database we need, coordinates have moved fully to 64 bits without any awkward workarounds. That's 9,000,000,000,000,000,000 coordinate units. We can position a bullet or fragment precisely and have a map spanning 90,000,000,000,000 kilometers. Yes, 90 trillion kilometers. Divide that by 150,000,000 kilometers, or one AU, and you get 600,000 astronomical units. We can simulate a bullet flying through a triple star system, easily and without special tricks. Roughly 300 AU is enough to model the Solar System; with the Oort clouds and other trans-Neptunian features, 1,500.
Previously, using strained workarounds and unable to model a star system larger than our own, our smallest step was 10,000 kilometers. Ships closer than that were considered to occupy the same point. Now we can calculate to the centimeter.
There is almost no news because I've been ill. When I'm ill, my thinking slows down badly and I don't sit down to code. Besides, I'm now working on how the server interacts with the database and how servers communicate with the client. The foundation is there, and the game already works with a server and clients, but now it needs to support several distributed servers. It's a difficult but solvable task. Some parts are already working. As a bonus, here is an avatar of one of the ship's crew officers.
What has been added? Switching ammunition through a menu; weapon and engineering menus with buttons and various data; gun firing modes; tracking different types of ammunition. I've started working on the thermal behavior of modules and the ship as a whole. After that I'll add missile weapons, then drones, then electronic-warfare systems. Next come improvements to the detected-target menu, including corrections and uncertainties that depend on sensors and other circumstances; polishing radar and other sensors; a start menu with an interface for ship setup and modifications; and then the difficult part, tuning the damage model. After that, I can start testing with friends!
Yesterday I built an important component. More precisely, a whole set of mechanics: accounting for a ship's energy resources; shutting down modules in order of priority when power is scarce; connecting, charging, and discharging batteries; and timing transitions between different module activity states while accounting for possible damage and the experience of officers and crew.
What's especially pleasing is that this isn't built for just one little ship. It's a system that can process any number of modules, in any configuration, on any ship.
A progress report. Besides bugs and the usual other things, scanner sectors and complex engine functions are now working properly. We can now fire at a moving target with lead, accounting for both our own speed and the target's. Projectile behavior now depends on quality, so muzzle velocity varies. The barrel has dispersion, too; you can see it in the rather uneven trail of shots. For a break, and to get a better sense of scale, I temporarily put a model from Star Trek into the scene. Our little ship is docked right next to it.
After the summer and all that work, it was time for a break. Then it was time to code again, and I've already been doing that for quite a few days, with some success. Today, for example, I finished and debugged the ship's automatic stop function. I added firing at a target, both from a moving platform and at a moving target, and introduced variation in projectile speed according to ammunition quality. Next up is matching speed with a target and flying right up to it for docking or boarding. I struggled with stopping for a long time. I had to calculate how long each engine would need to run, and in which mode, to bring the ship to a complete stop. Given that the ship can be upside down or pointing in a completely different direction, and that there are six engines, the task isn't as simple as it may seem. Especially when it comes to actually programming it. I made a menu that appears when you click another ship, with a few choices in it, though I think doing this through the interface will be more convenient and more appropriate. In this case, one doesn't prevent the other.
