MattScott

Hi all, The team did a great job of plowing through tickets and bringing the numbers down overall compared to last week. We continuing to explore new CS resources. As of today we have: 469 new tickets 672 total tickets We are 2 away from responding to tickets submitted on 4/23, so we're slightly over 2 weeks to respond. Thanks, Matt

Hi everyone, First, I want to acknowledge that I have been absolutely terrible about providing updates on Fallen Earth. Certainly COVID-19 has had an impact on the studio's ability to work on multiple titles at once, but this mostly rests on me. I kept scheduling an update for you guys, and then by the end of a 10-12 work day, I just couldn't seem to find the time. Second, I want to set expectations (again) for where we are and where we aren't. This project is #3 on our priority list right now. As a company we can only do so many concurrent projects with the staff we have. 1) We need to get the APB Engine Upgrade out the door. Internally, we have been forced to keep shifting the date out due to performance issues, but we have reached the "all hands on deck" point. This needs to ship, so we can free up developers to focus on other priorities. 2) After that, we have also committed to a Live stream of Unsung Story for those backers who have waited 5 years to get a glimpse of the game they funded. So the rest of the studio is working overtime to prepare for the June 1st stream. I want to be clear that Fallen Earth isn't loved any less in the studio. Temporary circumstances have forced us to be very specific where we are putting our resources. The team is excited to get back into the Wastelands, so we can get you guys the game you deserve too. We are still very much in the early, exploratory phase of development where we were testing various solutions to each system that needs to be ported. But here is a description of the short term roadmap to get to our first internal milestone: - Recreating the terrain This effort got fairly far along, but there is still work to do. While the basic shape of the terrain is in, there are 2 subsystems that haven't been ported. The first system uses image "stamps" to deform terrain based on where the original designers placed them. These stamps create more interesting geometry and help break up the height mapped look of what we have now. The second system uses nodes that form lines and areas to deform terrain for roads, hills, lakes, and other areas where geometry has been "carved" away by the remnants of humanity to build their structures. - Terrain texture layers This technology has gotten quite a bit better since Fallen Earth was written. The team was starting to identify the strategy for "splatting" or compositing textures on the terrain to create more variation and interest as the player moves through different ecosystems or biomes. - Foliage rendering This is likely one of the biggest areas where I think we can make the world of Fallen Earth feel more realistic. Foilage systems have become so much more powerful and now contain more realistic looking plants and trees. The team was exploring how to adapt the game's foliage data so it could be applied into Unity's systems. This combined with the above terrain enhancements should be impressive in the final product. - Streaming the terrain and objects The original code was very good at rendering chunks of terrain with only the nearest objects to you. In the new code, we've gone with an entirely new way of chunking up the map that will require us to stream in pieces as you run around. We had just started experimenting with a couple techniques, before the devs got pulled onto other projects. NOTE: We have a basic demo for the terrain that I took screenshots from, and this runs extremely slow because all of the terrain and objects across the entire world of FE are rendered. - Fixes to imported assets We also found some bugs in our importer that created inverted normal maps, didn't assign textures properly, or created rigs wrong. We were in the process of fixing these bugs, so we could delete the imported assets and reimport everything from scratch. Then we can re-run the process that builds the various layers to the map, so we can prep streaming. - Character assembly With all the pieces for characters imported, the team had started work on the code that assembles the player with the proper body proportions, head, tattoos, clothes and items. We hit an immediate snag on supporting "selection sets". These are lists of faces on the model that can be shown or hidden by name. The original code used them to hide the areas that are covered up by clothes. - Basic movement prototype This is our first milestone for the project. With all of the above tasks completed, the plan is to (1) assemble a character (2) load into the world and (3) run around the environment with active collisions preventing you from walking through objects. This wont be connected to any servers or running any multiplayer code. It's just a milestone to test everything all together and see how it looks. With all of that in mind, I thought it would be fun to post some WIP screenshots for classic Fallen Earth locations, so you could see how some of this is coming along. The shots below show the assembled terrain, buildings, objects and props for the entire world. You'll notice in the upper right hand corner, that we're sticking with the game's original coordinate system. This allows us to hop around the map to inspect things. There are no terrain textures yet because the layering system hasn't been implemented. Just imagine this is Fallen Earth in winter . Oddly, that effect is enhanced by a good number of the objects that are embedded too low into the ground. This is because we're still missing those two subsystems that I mentioned above that deform the terrain in smaller areas. You'll also see some texturing artifacts on the buildings and objects. Everything looked good as we inspected a couple buildings at a time during the import process. But when we assembled the whole map we found areas that still needed work in the importer. Clinton F.A.R.M. Embry Crossroads Los Alamos Haven Watchtower Odenville And a bit of a fail with Boneclaw… Apparently the ramps for this area are heavily carved out from the terrain, so much of it is buried. I appreciate your patience. Stay safe. Thanks, Matt

Hi all, Sorry for the late post today. I try to get these out a bit earlier, so they can be read by our European player base. We had another big push this week to try and clean up remaining items for the Beta. We completed a lot of the audio re-work late on Friday, but I had an SPCT member go in, and we saw many of the issues were fixed. Still a couple stragglers, but with the limited testing, it looks like we got about 80-85% of these bugs. Next, let's deep dive frame rate issues. Last week, I walked through our work on optimizing the UI during missions in Asylum. Today, I thought I would post some of the performance statistics from several builds. These all came off the same machine with the following specs: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz with 16GB of ram and an NVIDIA GeForce RTX 2080 SUPER The test is based on the average frame rate running around for 10 minutes in Asylum while actively doing objectives and missions. I should make the disclaimer that we always accept these benchmarks with a grain of salt, because with an online game it is impossible to recreate the same exact testing conditions. But we use them as a general feedback mechanism to let us know if we're on the right track. I'll apologize in advance for not having any of Skay's pretty charts. We started with the performance on Live with ~18-19 players in the district: Mean Frame time = 8.08ms Mean Frame rate = 123.75 FPS Average Frame time = 8.125ms Average Frame rate = 123.07 FPS Maximum 1% Frame time = 6.95ms Maximum 1% Frame rate = 143.8 FPS Minimum 1% Frame time = 11.12ms (ignoring hitches) Minimum 1% Frame rate = 89.87 FPS UI accounted for 1.41ms on average We actually pulled two logs from two different sessions during the 4/17 Beta. I'm going to share them both, because it illustrates the variance in benchmarking. Session #1 during the Beta stream with ~19-24 players in the district: Mean Frame time = 12.02ms Mean Frame rate = 83 FPS Average Frame time = 12.19ms Average Frame rate = 82 FPS Maximum 1% Frame time = 6.62ms Maximum 1% Frame rate = 151 FPS Minimum 1% Frame time = 18.16ms (no hitches) Minimum 1% Frame rate = 55 FPS UI accounted for 4.43ms on average (more than 3ms higher than Live) Session #2 during the Beta stream with ~19-24 players in the district (but only half that for the last couple minutes): Mean Frame time = 10.98ms Mean Frame rate = 91 FPS Average Frame time = 11.21ms Average Frame rate = 89 FPS Maximum 1% Frame time = 5.55ms Maximum 1% Frame rate = 180 FPS Minimum 1% Frame time = 16.94ms (no hitches) Minimum 1% Frame rate = 59 FPS UI accounted for 3.49ms on average (only 2ms higher than Live) You can see that just dropping some opponents during the stream for the last couple minutes made a significant difference in the frame rate between Session #1 and Session #2. All three of these tests had real players running around firing and jumping a lot more often in concentrated areas with customizations. The bots don't do that. There is literally no AI at all. They randomly path around the district, fire and interact with things. They are great for us to trace code and diagnose issues, because we can start up missions in Asylum without gathering a bunch of real people. In retrospect, I wish we had a bot run from the 4/17 Beta build. We got an original benchmark today, and I had to throw it out because we didn't have enough bots running and the bots that were in the district were super far from each other. So the stats were clearly skewed and too good. We fired up more (although couldn't get 19-24 to compare), and this time they clustered up a bit near the Criminal spawn point. But even this next benchmark wont represent an apples to apples test with the first three. Here are the results from today's session in the new Beta build with 15 bots: Mean Frame time = 6.03ms Mean Frame rate = 165.78 FPS Average Frame time = 6.07ms Average Frame rate = 164.8 FPS Maximum 1% Frame time = 4.82ms Maximum 1% Frame rate = 207.4 FPS Minimum 1% Frame time = 7.80ms (no hitches) Minimum 1% Frame rate = 128.2 FPS UI accounted for 2.56ms on average (we are still running both Unreal UI and Scaleform for now during game play in APB 2.1) Based on this test, the next step will be to organize another large playtest between SPCT, the streamers, and LO staff so we can get a better benchmark. I'll let you guys know when that will happen. FOOTNOTE: Also for those that are interested, we started work on the unfinished DAM (District Allocation Management) system that was designed by Reloaded. This system dynamically collapses and expands threat by spinning down and spinning up new districts during the day. This is the first major system we will launch directly aimed at solving match making in a new way. It requires APB 2.1 to work, but I wont hold back the Beta for it. I wanted to make sure we get that feature pushed out as soon as possible. Thanks, Matt

Interesting format and questions. I'd be curious to see the results. Thanks, Matt

Hi all, We worked hard to make up ground this week despite the rising tide of tickets. We also brought on a new CS person. As of today we have: 493 new tickets 685 total tickets We are responding to tickets submitted on 4/17, so we're at 2 weeks to respond. Thanks, Matt

Hi all, I’m definitely interested in seeing the results once enough people have weighed in. Thanks, Matt

Ahh. Thanks. I wasn’t.

Hi there, We had to turn on this feature recently when our registration / login pages were getting hit by bots. This isn’t a DDoS attack, but it’s similar in that attackers direct lot of traffic to fill out specific page to make them unavailable. Thanks, Matt

Hi all, This week started a bit unorganized. I think the team was a bit burnt out having worked long hours to prep the streams last week, so some staff took Monday off. The rest of us took the day to digest all the data from the streamed playtest of APB 2.1, so we could create a new dev plan to finish the Beta. Problem #1: Poor frame rate Initially we thought the slowdown was from all the characters in the district. In order to test that, we needed to revive some old code that allows us to run Bots in districts that can emulate players for missions. Don't get excited. These Bots are horrible. They literally move around the district firing and interacting with things randomly. SPCT has been fascinated by seeing these AI abominations running around and trying to determine where they are going. After some testing, we determined the major part of the slowdown isn't tied to the number of players in the district. However, the Bots did allow us to spend some time identifying game loop areas in missions that were underperforming. We got a build out to testers by Wednesday and there was some improvement. We also found that Scaleform continues to drag our framerate down, so we have decided to remove it entirely from the game play HUD. That will free us from having to constantly update that system for the couple screens that use it. We optimized the Scoreboard HUD, Actionmessage HUD, and Taskmarker HUD. Problem #2: Audio issues This is the last part of the code that we haven't touched. I'm sure many players noticed how bad it was in the streams. Right before the playtest we pulled down a new version of Wwise, so this week we dove into that part of the code where we found... a mess. It looks like during the port to console (and possibly even in Live) the dev team didn't really implement sound to utilize all of the proper features. We did make progress, and we're hoping to get a build to testers soon so they can verify some of the worst sound issues are corrected. We rebuilt the PS4 and XB1 sound banks, fixed a threading issue with audio memory, and reduced some info calls to improve performance. Ongoing work: We carried over a task from last week to implement a new SSAO shader to get rid of the flicker when you run. The flicker is caused by changing the Field of View which breaks the math in the shader. It's a known issue in Unreal. Thanks, Matt

Hi all, This week was brutal. We got hammered with tickets, and many of the active tickets they started were very difficult to solve. That means we lost significant ground. Hoping to make it up next week. As of today we have: 563 new tickets 700 total tickets We are responding to tickets submitted on 4/8, so we are at 16 days to respond. Thanks, Matt

Hi all, Missed the post yesterday here. Instead we uploaded the highlights from our Beta stream on Friday. Here is the thread: Thanks, Matt

I definitely want to do more of these. This is only our 3rd Q&A in almost 2 years. Thanks, Matt

Hi everyone, For those that missed the streams, the Q&A or my bad posture yesterday, we decided to edit down the demo and Q&A on Little Orbit's channel. You can see the highlights here: A full transcript of the Q&A section of the video was made by @Kevkof and is posted further in this thread. Thanks, Matt

Hi all, The team is getting through tickets as fast as they can. As of today we have: 409 new tickets 553 total tickets We are 2 tickets away from responding to tickets submitted on 4/5, so we're were at 12 days to respond. We have started interviewing for more CS. Thanks, Matt

Hi there, For clarity, we didn’t invite anyone except the previously approved streamers in our program (which isn’t very large). From there we announced the streams, and then evaluated everyone who applied. I think one of the names you mentioned contacted us after we posted the list, and the other didnt contact us. This wasn’t intended to be exclusionary at all. There were very few we had to say ‘no’ to for one reason or another. Thanks, Matt

Hi Alisha, Your criticism is fair. But I think you're making massive assumptions about our content management tools. The CMS used to administrate ARMAS and those items was home grown. It is ridiculously clunky and slow based on ancient tech. Back in November we had a plan to clean everything up by importing newly formatted descriptions directly from exported game data. However that effort turned out to be a bust because some of the items on ARMAS were hand edited with flavor text in addition to the stats. We then backed up to start looking at a rewrite of the CMS (or entirely scrapping ARMAS and moving to a new store platform), but that effort quickly got put on hold when everyone was put on the Engine Upgrade. At this point there can only be a single #1 priority. Thanks, Matt

Those improvements have already been made. We are hoping the PC Beta will help us work out all the bugs first. Then we can submit to Sony for approval so we can launch the PS4 version.

Hi everyone, I hope you are enjoying your respective holidays this weekend and connecting with family and friends either virtually or in real life. Several players reached out to me asking if/how we managed to fix the problems I discussed in the last update, and one even sent some ideas on how to fix the issues. After responding to them individually, I realized that I had nearly written a blog. So I thought I would share those answers here, since I didn't post an Engine Update yesterday. First, a little bit of history. When the upgrade to Unreal 3.5 was started at Reloaded Productions, they were faced with the difficult task of exporting all the geometry for the districts from Unreal 3 to Unreal 3.5. You might think this is easy, but Unreal 3 has very limited export formats. The final solution was to write a commandlet in Unreal 3 that exported meshes through the OBJ format as pieces along with some extra data. Then they wrote a commandlet in Unreal 3.5 that reconstructed all those individual files and imported everything, and when they were done, they exported a single FBX file for each mesh. This is a pretty impressive bit of code, because now we have a decent starting place for all the basic buildings (like that lighthouse entrance from last week). It's important to know that APB was the result of a different project at RTW which was focused on procedural world building. As good as that tech was, it was also somewhat messy. So a lot of manual 3D art work had to be done to clean things up. Since the RTW days everything has been done in 3DS Max. So that's what we used. When we hit issues like last week for a specific building, we often have to fix it in the original FBX and then re-import it back into Unreal. But that leads to 5 basic problems: 1) There are unwelded verts all over the place that leave stray polygons (polygon soup) detached from each other. The easy fix for this is to select all the verts in 3DS Max and then weld everything within a specific tolerance back together. But you have to find the right weld tolerance. APB is modeled in centimeters. When we welded verts within 1cm of each other, we ended up welding verts that needed to remain distinct, and some texturing got ruined. The best tolerance ended up being 0.5cm. Here is an example of what unwelded verts look like when the lightmapping tools try to bake lighting. 2) Since these FBX files were programmatically exported, they have no smoothing group data. Bad smoothing groups is another place where lighting will bake extra seams and edges that you don’t want. There are thousands of building pieces in APB and many of them have LOD variants, so we needed an approach that could be run automatically across a number of files. We tried automating "autosmooth" in 3DS Max and generated disastrous results. In the end, since the majority of buildings have squared off edges, we wrote a maxscript that was able to sample faces for 30 different vectors (angles) to rebuild the smoothing group data. From there everything else had to be hand tweaked. Here is an example of a more complex dock building after we applied autosmoothing. I have selected the faces from a specific smoothing group. You can see how some faces on the same side of that building are not highlighted. This means they aren't in the same smoothing group and can cause problems when we bake lighting. Here is the same smoothing group after using our custom script. All of the faces on the side facing the camera are in the same smoothing group. This will insure they will all be lit more uniformly together. 3) After those two issues, then we get to the uvs. In many cases, the original set of lightmap UVs can simply be repacked to use the texture space better. But if you had stray polygons to begin with, then chances are those will still be messed up in the UV channels. So in about 20-30% of cases, we had to create all new unique UVs required for lightmapping to work. Again, the automated uvmapping tools failed us because they all use a single angle to determine where to unwrap the mesh. So this had to be hand tweaked by artists mostly selecting chunks of contiguous walls where we wanted uniform lighting, then planar mapping those selections as a single set of uv faces, and then repacking the whole uv channel to fit 0,0 to 1,1 with no overlapping faces. For those who are unfamiliar with what uvs are, they are best described with a picture. UVs are a 2D coordinate system for mapping textures onto a 3D object. Each face (triangle) of an object is defined by 3 vertices in 3D x,y,z coordinates. In order to texture those faces, we have to map each vertex into 2D space with just x,y which are renamed to u and v so we don't confuse them with the 3D coordinates. Each object can have multiple uv channels. For lightmapping, we need a channel where none of the faces are overlapping. The building above looks like this: And here is an example of the lighthouse itself when we tried to use Flatten uvmapping to generate a set of unique UVs and then tried to bake lighting. Since the lighthouse tower is round, you can't apply a technique that unwraps faces based on angle. 4) Sometimes we simply needed to increase the lightmap resolution. When the districts were rebuilt in Unreal 3.5, part of that commandlet tried to guess the surface area and set the appropriate lightmap texture size. In some cases that estimate was way too small. Increasing the size fixed a lot of lighting artifacts. The problem with APB is that texture memory is already stretched pretty thin. So we have to be careful when increasing these. Fortunately we have tools in Unreal that allow us to view the entire district with lightmapping resolution grids turned on. Larger / darker will be worse with chunky shadows or visual artifacts. Smaller / lighter is better and more defined. Here is what that looks like on the same dock building. Some of the areas that appear solid colored actually have a grid so small you can't see it in this shot. 5) Lastly, for hyper detailed meshes, there is an option in Unreal to use high precision UVs. I’m guessing by default they use traditional floating point values, which lose accuracy for small numbers with a lot of decimal places. Checking this option probably switches to double precision which preserves better accuracy. In any case, this also cleared up some lighting artifacts. Hopefully some of this information will help you understand why the Engine Upgrade has taken so long - even from the point that we took over. It's also one of the reasons we decided to launch the Beta with only Asylum and Social, since those districts are farther along in being cleaned up. Thanks, Matt

The streamers this Friday will be showing off the APB 2.1 Beta. It will only include Asylum and Social for the time being. The next version of the Beta will have all districts, and then we'll launch the full APB 2.1. Console will be running the same code, so once that gets approved by Sony and Microsoft, those players will get all the new content from the last 2 years + new content as it arrives on PC.

The 2 new contacts featuring the EMP will be added when APB 2.1 launches.

It's not really possible for us to run a Beta like this on console. However, it's the same code base, so there has been progress. In the meantime, we are hoping the PC players can help us work out the bugs before we submit to Microsoft and Sony.

Hi everyone, There isn't an Engine Update this week. Instead we are announcing the first Live stream of the Beta on Friday, April 17, 2020 at 11am PST. You can get more details here: Thanks, Matt

Hi everyone, 6 months ago I decided that the community had been kept in the dark too long about the Engine Upgrade. In development all kinds of things can and do happen, and even the best teams run into issues and blockers. So to help pull back the curtain, I started posting a dev diary of sorts focusing on our weekly progress. If you haven't been following it, you can check it out here: This week there is no update - at least not on the engine itself. Instead we are going to try something different with the community. On Friday, April 17, 2020 at 11am PST we have invited a number of APB streamers to show off the new Beta live. Over the coming week, we'll be posting a list of Twitch channels that will be participating so you can support your favorite. Each streamer will start with some quick benchmarks on their system from APB 1.20 (Live). Then they will load up the Beta and do another quick series of benchmarks before jumping into a couple Fight Club matches on Asylum with our dev team. Everyone will have codes and goodies to give away, and they will be gathering your questions and comments to give me for later. After about an hour all of the feeds will hand everyone off to the Little Orbit Twitch channel (https://www.twitch.tv/littleorbit), where I'll do my best to answer your questions and talk a bit more in-depth about the upgrade and the upcoming timeline. EDIT: Below are the names of the streamers that will be showing off the Beta on Friday. This was a bit difficult to manage, because many of these are controversial figures in the community, but I didn't want to get into the politics of approving or denying streamers. The idea behind this is to allow the community to take a good look at the game with your favorite streamer. You can choose to watch any of these, so let's not flame this thread with criticism. This is a big milestone for the game. Let's enjoy it! Here is the list: WitchQueen https://twitch.tv/witchqueen Frosi https://twitch.tv/frosi Lie https://twitch.tv/liee Rich https://twitch.tv/cuve RuschGaming http://twitch.tv/ruschgaming Kempington https://twitch.tv/kempington Flaws https://twitch.tv/Flvws Gordo https://twitch.tv/gordoismyname CombatMedic02 https://twitch.tv/0utbreakgaming Exo https://twitch.tv/exoticzlol Zeal https://twitch.tv/zeal PoundOfFlesh https://twitch.tv/thepoundofflesh Shini https://twitch.tv/shini Jam https://twitch.tv/amsterjam Ntec https://twitch.tv/ntec Sadira https://www.twitch.tv/sadira SKay will be joining Matt Scott on twitch.tv/littleorbit for a Q&A at 12pm PDT / 7pm UTC. Thanks, Matt

Hi all, Still trying to keep the response time low, but there has been a massive surge of new tickets. The team is working hard to keep pace. As of today we have: 318 new tickets 490 total tickets We are responding to tickets submitted on 4/2, so we're were at 8 days to respond. EDIT: Sometimes a picture is worth a thousand words... Here is a report showing how many new tickets we have been getting since the beginning of 2020 through last week. We went from ~200 new tickets per day in late February up to nearly 400 tickets on a single day last week. In order to stay current with tickets right now, we have to close ~1500 tickets per week. Here is a report showing our average response time since January 2019. At the beginning of 2019 it was taking between 30-36 days to response on average. For the most recent 12 weeks we have been responding between 6.8 days and 4.9 days. Thanks, Matt

Servers were back online at the time of my original post.