You must be registered to see the links
You must be registered to see the links
You must be registered to see the links
Hello, after almost six months of silence HoneyBadger again out on bond. I don't really like to write texts, because what I'm doing is not fully clear to the average user. The common goals that I pursue as a programmer in this project are to make our game running quickly and conveniently available on any device and to prepare a platform for easy implementation of all our crazy ideas. Below is a boring description of all the things I do.
Current task:
Create a proper online application.
Completely get rid of outdated and unnecessary code.
Optimization game events for easy future development.
Refactoring:
We are at the stage when the graphical interface of the "designer", which we chose at the beginning of our way turns from a good assistant to a novice game developer, into a limitation. "Underside" - the framework can be arbitrarily long to change to suit your needs, but the graphical interface through which files are created game maps and events can not be changed. And the methods of creating game logic that he offers are no longer suitable for us. After a year and a half of development, the game was filled with a huge number of duplicate code, excessive complexity and high connectivity of fragments. I tried a lot of methods of code structuring, but in the end I came to something similar to "normal" programming. From the basic system remains one "skeleton". Event lists have been turned into independent "functions" that support the transmission of arguments, the built-in system of variables has faded into the background and is replaced by a new one that supports multiple scopes, event lists are cleared of unnecessary data, become well readable, there is a certain "standard" of development. According to my estimates, after the final refactoring of all game events, the number of game script code will decrease by 30-40%. All this is necessary for quick changes in the future and easy debugging. At the same time, it became possible to design "memories" taking into account arbitrary branches of history.
Naturally, in the process of changing game events, the code of the framework is also constantly modified. Every day the missing functionality is created and the code of old solutions is reprocessed.
Debugging:
In parallel, we are working with the extension of the logging system, each action will generate a record in the log with all the necessary data. Users will be able to back up their problem descriptions with a detailed log file. In the end, all bug reports will be sent to a centralized server and we will know where, when and under what conditions the error occurred. All this reduces the time for troubleshooting several times.
Resource optimization:
Imagine a server where hundreds or even thousands of people receive files every day during their own gameplay. The size and number of these files directly affects the loading of channel and server resources, and hence the smoothness of the gameplay of each player. The first priority is to reduce the size of the game assets as much as possible. This will help us such things:
Already announced system of "collages".
Localized delivery of resources within a single loader. The ability to intelligently start downloading the necessary resources before they need the user to wait for the download in key places, and so on.
A new sound system that allows you to pack sounds in "sprites", that is, having a dozen short sounds, we can easily add up to one file and the number of requests to the server will drop sharply.
Something about the sound:
The new system has in its core pixi-sound library, with a rather complex wrapper. I think I added so much possibilities that all of them have no place to use at the moment. Each sound has tags that can be used to manipulate arbitrary groups of active sounds. It is possible to save and restore the current map of sounds with all related parameters. There is a system of additional modifiers, for example, you can "mute" any group of sounds for any time. There is a system of sound range, which is widely used now, no sound porridge on the cards will no longer be, the sound volume gradually increases with the approach of the player to the source. The sounds will be divided into several main groups: "background", "music", "voices", "current event", "steps". The users will be able to adjust their volume at their discretion.
You must be registered to see the links
The system of "memories":
In fact, "memory" is no different from an ordinary map with standard game events, the problem is that the early approach to their creation was catastrophically excessive. Each branch of the development of the plot had to be created from the original by collecting commands from the main script and creating a separate list manually. What if there are three or six branches? A huge number of duplicate and sometimes even not the same code, many copies of the original maps. This approach is simply unacceptable. Fortunately, the current development model allows with just a few commands to reproduce any past event with all the variations. If we have to correct the original - then all of its variations in the memories will also change. So all the necessary game challenges are isolated in the memory scenes and do not affect the main gameplay. Now make a replay was a matter of thirty minutes.
As you know what the user sees in the course of the game depends on his actions and talent class. If the player wants to get all the erotic content in the game he will have to go through the game several times. The progress indicator will cover the current player's experience and all the past saved games, it will be possible to easily "playback" all the variations of events, regardless of where the player is at the moment.
Conclusion:
Experience appears in the process and many solutions created earlier do not stand the test of time. But without mistakes unfortunately no development is possible and I am very grateful to you for the opportunity to move forward. All the best to you.
And a few words from HandlessGhoul.
Being distracted from the main events development, thoughts about different things come to mind. One of these ideas is personal transport. In the F2 was a Highwayman, so adding a car would be unoriginal. Our choice was stopped on a sidecar motorcycle. This is quite unusual and suitable for our restriction of the group to two companions. For a basis we took the motorcycle "Ural", below you can see an example of appearance, with tuning and without.
We also add more interactivity to the game. Now most of the consumable items can finally be used, and each of them will have its own unique picture, in addition to the inventory icons. Similar to the use of a stimpak.
Continuing the theme of thoughts about the future. Working on the sprites for Dogmeat, initially there was a mistake in size, because of what he turned out just huge. But since we do not throw anything away, the idea arose that at some point, having high enough...ahem, relationship with the Dogmeat, it will be possible to change him, with the magic of friendship and a pinch of FEV. This "super" Dogmeat will be much stronger, as well as it will be possible to ride, moving rapidly on the global map, if the group you do not have other companions. These are ideas.
One last, I would like to show you something very old. When the game was just beginning to be developed, for it was supposed to have a completely different visual style. Initially, it was assumed that all objects and characters will occupy only one cell, similar to the default RPGM style.
Yep, it is perceived completely different. But who knows, maybe we can use this somewhere too. Hehe~.
