Search the Community

So I thought I might start sharing some of the development work that happens between patches. For those people who are interested in the actual development side of things, this could be interesting, but big wizbang news and changes will still be left for actual releases. Most of this stuff will be from videos and info that gets shared to the team, with a slight touch up to put into a forum post. This is far from formal news. Now that's been said, lets get on with it. One of the known issues has been with the softlevelbounds volumes that are put on edges of maps to set off the out of bounds warning. As such I've been working on making an alternative volume to achieve the same effect, just with a different approach, the video explains most of it, so ill let that do the talking.

For the last couple weeks, the team has been looking into the packaging of Renegade X. Specifically, the size and how the content is stored and downloaded. In general the team does actively try to avoid large patch sizes, (looking at you AAA games). We have a custom downloading solution, custom patching solution, our own collection of mirrors, etc. That being said, the game has been under development for a good number of years, and over time unused assets have crept into the hundreds of different packages that make up Renegade X. For the last couple of weeks, we have been looking into 3 different things related to the game package as a whole. Which I will break down and explain. 1. The amount of assets we have. 2. The "compile" type of packages. 3. The download process. The first one, the amount of assets. We grabbed all our assets, and also the list of 3rd party maps on our level download section and asked a simple question, how many assets are not referenced by any of these other assets or anything else? Well after touching 489 files, turns out about 3.13GB's worth! So we pulled out unused assets from each package and stored them in a separate folder, that is not for inclusion in the public release. These files will be included in the sdk release, so that content creators can use them if needed. But in general, that should reduce the file size of the game by a large percentage. Now this wont translate into a direct saving of 3.13gb, due to a number of reasons, but its still going to be a shrinkage overall. The second point, the "compile" of packages. We are a UDK based game, which means we use a fairly open version of the unreal 3 engine. The unreal engine works on a variety of platforms. PC being one of them of course, but there's also xbox, playstation, wii, ios, android, etc. In understanding that nearly all of these platforms run differently and are limited compared to PC, you can understand that the engine has mechanisms to deal with packaging the game for more resource limited environments. Over time, as these consoles are pushed to their limits, it meant that more optimizations are made to the engine to deal with these limitations. Eventually the guys at unreal worked out that some of these optimizations can be brought back over to PC. So what does this actually entail? We'll traditionally, if you wanted to run your unreal engine game on a console, you would have to "Cook" the packages to work on that platform. Cooking does a good number of things, including, but not limited to: 1. compress content 2. convert the format to be native to the target platform 3. serialize the objects to be loaded from disk faster 4. compile everything related to the assets 5. update cross package dependency import/export/name tables 6. reduce disk seeking 7. create a startup package with dev specified common used packages, to save level loading time 8. other stuff Some of these improvements can help PC as well, so we have been experimenting with cooking the packages for the PC platform. We have actually tried cooking before, a very long time ago, and packages that haven't been touched since then should still be cooked, which is why the game release currently stores its data in the cookedpc folder. That being said, our devs have noticed improvements when cooking the rest of the game, but it will be the more hard drive/cpu limited machines that should see the most benefit. For this coming patch, we are aiming to cook all of the content, except map files. The following patch should have the map files cooked as well. This is still being looked at, so we may decide not to use it, if problems arise. Our 3rd item, is downloading. As mentioned before, our downloading system is a custom setup, and that is from the need to have a better downloading experience then what was available to us and you from stock setups. Recently, we have been looking into improving this system. Our biggest change looking forward, is to implement torrent style downloading, which is used in a variety of different games in this day and age. Torrenting is more resilient and natively supports multiple download sources, compared to traditional http downloading. Even if we implement torrent based downloading, there will still be a fail back option to http downloading, and as such, we are also looking into what can be done to improve the http download experience as well. Now with these changes, even tho they are made to reduce the size of the game, and the speed of which it loads and downloads, and we generally try to keep patches from being bloated; because many files had to be touched, the actual size of the patch will be larger then typical, as even a slight change to a file means that the whole file needs to be updated. This larger then normal patch size should be a once off, or possibly twice off, as the maps will hopefully be cooked as well, in the following patch. Overall, result of these changes should be a smaller sized, quicker to load and download Renegade X. Which I think most people would agree, is worth the investment.

Bugs, unless they are funny, we all hate them. They get in the way of our gaming experience, and can range from unnoticeable, to annoyances, to outright fatal. As a dev and a server owner, I end up looking at the logs a lot, seeing bugs get pumped out. Now there are different types of bugs, logic bugs, gameplay bugs etc, that wont show up in logs generally, and they are usually the more noticeable ones. That being said, you would be surprised how many errors and warnings get pumped out when your playing a match of Renegade X. How many you ask? Well I played a skirmish match, on Canyon, with 40 bots for a typical 35 minutes. I then went to the logs to get the count of how many bug instances showed up, divided into different categories. The results were: Errors: 900 Warnings: 6159 Could not: 1765 For a grand total of: 8824 This number doesn't include the 16 compile time warnings, netplay related bugs, missing text errors and even texture/material compiling bugs. None of those bugs are repeated in other categories, so no double dipping here. I've attached the log for those interested. Now, some of these will have little actual impact, some will manifest themselves is unpredictable ways, but all mean something is wrong somewhere. For this patch, I've spent weeks making a strong effort to deal with as many of these bugs as possible. All the compile time warnings are now gone, nearly all the startup bugs are gone, and the gameplay bug count has been reduced dramatically. We also had some of the mappers fix some of the material bugs as well! Running the same test using today's internal build, the numbers look like this: Errors: 29 Warnings: 1369 Could not: 1073 For a grand total of: 2471 As you can see, the numbers are a lot lower then they were during the last release, but there are still quiet a few left. I will be continuing to attack these bugs in force, until these numbers are as close to 0 as possible. For you, I'm hoping that Renegade X is a bug free experience, allowing you to enjoy the awesome game the team has made, and that our community continues to help it grow. Launch-current_-_Copy.log