MattScott

Hi all, I'm going to keep the weekly updates going as best I can. Last week, I walked through our four part plan to get APB 2.1 optimized properly. This week we finished troubleshooting the scripts and got those compiling. For those that aren't familiar with Unreal, script files are written in Unrealscript. It's sort of a janky language that Epic has since done away with in Unreal 4. Devs in Unreal 3 used it as glue between the engine and C++ files to expose variables and functions for non-programmers to build off of in the Editor. Now we're working on #1: Getting the Unreal Editor working. I'll admit upfront, I shouldn't have tempted fate when I said "In theory, this part shouldn't take a lot of effort." Turns out all of the shaders for the game have to be compiled and working before we can open the Editor. All modern day engines use vertex shaders and pixel shaders to render geometry and perform calculations on the Graphics Processing Unit (GPU). Vertex shaders handle data that relevant to geometry you're rendering. Triangles. Normals. Vertices. Pixel shaders handle data at the pixel level which can output textures or entire screens. I'm going to make some sweeping generalizations for illustration sake, but during each frame, the game grabs batches of geometry it needs to render or process. It runs that geometry through a vertex shader and then it pumps those results into a pixel shader which results in.. wait for it: a color for a single pixel. Unreal has a modular design that allows the behavior of both vertex shaders and pixel shaders to modified and then compiled over and over with different features. In fact, vertex shader and pixel shaders are reusable. They can be mix and matched to produce different effects. APB has hundreds of shader files that each have inputs and outputs with a bunch of logic in between. That logic is written in yet another language. High-level Shader Language (HLSL). Original, right? Fortunately it reads very similar to C. Right now we're going line by line through all of those shaders to diagnose areas where code was merged from 1.20 into 2.1. There are two categories of issue here: The first is that the shader is simply invalid and doesn't compile. The second is that the shader compiles but the results are broken based on data that is missing or not processed properly. For Getting the Unreal Editor working, we are only focused on the first category of shader issues. Once we get into the editor, then we'll start sifting through maps and characters to find shaders that fall into the second category. This week we made steady progress, but until every shader compiles 100%, I wont be able to show any screenshots. Thanks, Matt

Hi all, This week I'm going to try and make up for all the missed updates. Bear with me, this is a bit lengthy. I've seen the "Where is Matt" thread, and I appreciate the concern. I'm fine. Just busy. I figured I would start this update with a bit of context for what is happing in the studio before I jump into APB. At the beginning of January, we started a very large project alongside a longtime partner of ours. These are important projects for the health of the studio because they augment our cashflow and ability to continue investing in projects like APB. This first period of any game is a ton of work. The team is organizing milestones, delivery dates, the checklist for how to evaluate those milestones, and then the detailed overall schedule that has resource allocations for every staff member on the project. We are also working through wireframes for the user experience (UX) flow, doing mockups for the User Interface (UI), polishing up the Game Design Document (GDD), and writing the Technical Design Document (TDD). This project was based on some older tech that was written back in 2013/2014, so there has also been a technology upgrade effort to bring everything up to current standards. Per usual, I've been knee deep in all of that reviewing, asking for changes here and there, and generally building the momentum we need to finish pre-production and get into production. We're submitting the deliverables for Month #2 today, so now I can step back and let my production team take over the reins to manage the staff and continue progress. Now before I start seeing posts and panic, the team working on APB are separate from this new project. Alongside all of that, we have a second new project that we have finished organizing and reached terms on. Just waiting for paperwork and then we'll start that one too. Yep. You guessed it, I've been handling the more complex parts of business development and scope on that title as well. Some of the work will be done in-house, but most of development will be with an external group we have used before. Little Orbit's main focus is the publishing and launch for the game later this year. I've done the majority of my part already, so this is getting handed off to a producer for the next steps. We also have a big round of changes being completed for Unsung Story to get back out to our Early Access backers. And lastly, I saw mention of Descent on the forums. It's been a long hard road. I appreciate the patience of all the Kickstarter backers and Early Access fans who supported that title. I want to get the game in their hands as much as they want to play it. I promise we will share news as soon as humanly possible when we are legally able to. We are nearly there. TL;DR - 2021 has been insane for me so far, but I'm getting caught up. So that brings me to APB. Even with those various other projects happening in the background, my primary role right now has been managing the major overhaul to APB 2.1. As I mentioned in my last update, there are two main systems that were dropped during the initial console work. These systems were replaced with standard graphics techniques and removed, so it wasn't obvious to us they were ever missing. The team managed to uncover these missing systems during a line by line comparison with APB 1.20. The systems are: #1: Night lights / AO shadowing #2: Building Feature rendering We're focused on System #1 right now. As of today, we believe all of the missing code has been merged into 2.1, and it finally compiles again. Imagine spending a month moving code into a project and only now getting it all to compile. That's how much was missing. I seriously doubt that all of the logic is perfect, so there are going to be bugs littered throughout. Regardless, this is a big first milestone. Now we're recompiling the game's Unreal scripts, which isn't quite working due to some custom classes that can't be autogenerated. Once that is resolved, then here is the rest of the steps to get this part of the project completed: 1. Get the Unreal Editor working with no crashes. Let's cross our fingers. In theory, this part shouldn't take a lot of effort. There is some Day/Night Weather data that needs to be reimported from APB 1.20 through the Editor, and then this step is done. 2. Test in a very small Unreal test scene for both APB 2.1 and APB 1.20 that only has part of a street, a main directional light and a "night light" such as the street lamps. We need to generate lighting for this small scene and then compare the results side by side. Not just the visual results - but stepping through both sets of code during the process and comparing the actual data. Night lights generate individual custom shadow maps that can be turned on and off depending on the time of day. Those maps light all the static geometry they effect, but it's virtually free to render at runtime. Right now, every night light in APB 2.1 was altered during the console conversion to be a dynamic light. There's a double whammy here. First, dynamic lights themselves are super expensive. But second, the shadows for night lights are being calculated all the time. They are just set to 100% transparent during the day! 3. Do the same test to work on the missing "ambient occlusion" map data. In APB 2.1, they decided to go with Screen Space Ambient Occlusion (SSAO) which is done in GPU shaders and rendered at runtime. But even after selecting that system and getting it working, the console devs disabled it when APB was launched on console. We found out why when we turned it back on. It doesn't work. During the Open Beta tests, you guys all saw the flicker that happens when running or entering a car. This is because the camera's field of view changes which in turn causes the flicker as an artifact. We spent quite a bit of time looking for how to fix this, and nearly everything we found said it couldn't be solved. The math just doesn't work. Back in APB 1.20 they cheated and baked out AO to a different style map that could be overlaid on the scene. Not only is this much faster to render, but it doesn't flicker. It also solves another problem - small shadows. In Step 2, I talked about all those dynamic night lights. Each of those casts shadows on everything includes foliage/grass. You can imagine how expensive it gets during portions of the map that have lots of foliage. The AO map takes care of those small shadows without all the overhead we have today. 4. Merge Unreal 3 and Unreal 3.5 render techniques. With all the data in place, then we can actually bake lights for a simple test district and run around. This is the trickiest part. We want to preserve the dynamic lighting from Lightmass, the new lighting engine in Unreal 3.5. Lightmass has a very slick pre-calculated grid of light samples that are used to cheaply light moving or animating objects in the scene without having to resort to expensive dynamic lights. But for static objects, we want to use the older shadow map / AO data combined with our newer multithreaded techniques. That's a bit of a jigsaw puzzle to work out, but there's already been some work being done to try and identify all the shaders that need to operate together. As soon as step 4 is done, we'll benchmark everything again. It's possible we may be able to launch APB 2.1 based on this single system, and then we can work on System #2 in the background for more improved performance. Additionally, for all those players who felt the districts were too dark or the lighting was odd, my hope is that we'll capture the color corrections from APB 1.20 but with slightly better looking techniques. I know this sounds like a lot, and it is. Unfortunately there aren't a lot of small milestones that I can talk about in between each step, which makes these updates more difficult to write. I'll do my best moving forward. I'm hoping once we get to Step 2, I can start posting screenshots. But right now I can't commit to the same weekly updates like before. That's it for now. Again, sorry about the lack of updates or responses to my inbox or discord. My schedule is nonstop right now. We want to get this completed for you guys as soon as possible. Thanks, Matt

Hi all, It's been far too long since I posted an update. I'm actually working on the Engine Upgrade project as a dev, so my free time has become pretty heavily impacted. At this point we are focused on two systems that got removed during the initial console project. One involves a custom lighting solution that eliminates the overhead of dynamically lighting and shadowing thousands of objects in the scene. We found just enough hints of it to have the guys find the rest of it in APB 1.20. It's a lot of code to port in, and it touches the editor, tools, and the runtime game. Work is well underway, but I won't have a sense of how long it will take for another couple weeks. It's not as simple as copying code in and hitting compile. Unfortunately there are extensive differences between the rendering pipelines. I'm sure this is why it wasn't brought over in the original console work. Alongside that, there is another custom solution that Real Time Worlds created to batch render and efficiently handle building features and interiors. Again, there is a lot of code that was removed, but this part will be slightly more difficult. We are also missing all the data that drives the proxy system. That will have to be gathered from APB 1.20 and then imported into 2.1 once we are done. Work continues. Thanks, Matt

Hi all, It's been a while since I have had to address this, but recently we have had some significant network issues. First, a couple days ago, our provider had an emergency maintenance to replace and move equipment around for our game. It's unfortunate we didn't get more warning, but sometimes we are at the mercy of other companies and their schedules. Second, and more important, we have had some bad network latency in the game. This is NOT our servers or a performance issue. This is due to an extended series of DDoS attacks that began when we announced the Open Beta for today. From the network graph below, you can see that we are consistently getting attacked for between 150 gigabits and 200 gigabits with the occasional spike up to 250 or 300 gigabits. These are big attacks. They take special rules to mitigate, and the attackers keep shifting the form of attack to make things more difficult. It's a shame. We're just trying to ship this new engine. Hopefully we will keep things smooth today, because these sorts of attacks skew our results and make it nearly impossible to finish the network optimization. Sorry, Matt

Hi all, It's been a little while since my last update. We ran our 4th Open Beta test on the 21st/22nd, and last weekend was a holiday for me, so I'm just getting caught up. I will admit that our 4th Open Beta was very frustrating. The team worked hard to clear up the issues from the 3rd Open Beta (or so we thought), but yet once we started testing many of those same issues popped up again. Fortunately this time we had a lot of extended data logging and devs online capturing specific moments to narrow down items. More than 250 players submitted feedback and logs. We've still got a lead developer out on holiday, but here is where we stand: SSAO caused client slowdowns (this was supposed to be disabled in this build) Shadows and time of day lighting not finalized Server spikes in both the world server and hosting code (world server has been fixed) Character baking issue (we believe this is an alternate UI flow to the previous issue that we already fixed) Scaleform/UI tearing (mostly on the opening screens like login) Audio problems (very clear what the issues are with the Vegas) Chrome showing up on cars (we think this is a settings issue where anyone running below a certain graphic setting will see the chrome) Keybinds not being able to be rebound (reported but not confirmed) To be clear, there were many other issues reported, but these were the largest that we felt we needed to fix before diving deeper to start addressing collisions or other gameplay issues. I'll keep you posted at the end of this week on our progress. Thanks, Matt

Hi all, This will be a shorter update this week, and I think it will be obvious why in the next couple days. At this point, we have run 3 Open Betas, and we need more information related to the player hardware along side the performance data. We have a lot of players who say they have had good experiences, but we also have many players who have given negative feedback. We took the time this week to significantly improve our stat collection technique. It will now also include any latency tests. So if you're experiencing what appear to be server lag, then please run /latencytest once before you exit the game. The new data collection will run and upload a dxdiag as well. Before the data had nothing identifiable, and while it is still anonymous, it does contain added hardware specs and other info. With that in mind, we have added a popup when you exit the game that asks whether you want to contribute data. We don't want to violate anyone's privacy, but we hope that as many players as possible submit data on this next test. Aside from APB 2.1 work, we also continued work on console. The build is edging right up to the memory limits on PS4, which is creating some issues debugging. But we're making good progress. Lastly, there will be more info soon on the next Open Beta, but this time we're going to do things in 2 parts. The first part will be a shorter more concentrated stress test, and the second part will be another normal play period. I would love to see as many players join for both tests, and as a little incentive we have added something fun to check out in Social. Thanks, Matt

Hi all, Backtracking a bit. In all the election run up, you may have missed the severe fires that hit Orange County during the week of Oct 26. Half our team had to be evacuated from their homes, and many spent 2-3 days in hotels or with relatives. It didn't make sense to try and conduct business with everyone's focus elsewhere, so we got a very slow start after the Beta weekend. Fortunately, our amazing fire fighters in Southern California kept all the buildings and homes safe, and no property was lost. This last week was much more productive. Here are a list of the major Beta issues that were reported (or picked up from stats), and what items have already been addressed: Graphical glitches in the UI made worse by turning on VSync. These primarily showed up during the login/character/district select flow. "Skinny" characters or loss of character customizations in faces and body proportions. (FIXED) Lots of audio issues. Missing audio. Directional audio not correct. This included left and right sounds or 3D positioned sounds. (FIXED) Graphic/chrome issue on player vehicles caused by spawning a second vehicle from the same spawner. Periodic lag / latency in districts. (POSSIBLE FIX THAT NEEDS TESTING) Stutters on the loading screen. Game crash on accepting a clan invite. (FIXED) Frame rate loss when moving the mouse around very fast. Input delay in the new Fullscreen Windowed mode. For the console players, we also jumped back into those builds to merge over all the recent work on PC. Both PS4 and XB1 are now compiling again with all the new content. We'll be looking at console crashes next week. Thanks, Matt

Hi all, Just a quick update before the Halloween festivities start. I want to thank everyone who jumped into the Open Beta 3 weekend. We collected lots of good data from the test. While there was some engine work this week, we are still collecting and digesting all the logs and player feedback. Next week, we will be putting together the next sprint based on what we prioritize. I hope everyone has a safe holiday. Thanks, Matt

Servers have been restarted. Let's see if players start getting opposed missions and the dev gun should be gone from everyone's inventory. Thanks, Matt

Hi everyone, Rough start on Open Beta #3. We're looking at mission problems and removing some guns that shouldn't have been available. Bear with us. Thanks, Matt

Hi everyone, I thought I would give the Community Events Team a shout today today. This is an entirely player run group that recently organized a fun APB Tournament that they just finished. These guys put in a lot of work behind the scenes, and you can join them on their Discord here: https://discord.gg/ZzefFfm Little Orbit has put up all the matches through the Semi Finals. We're still working on editing down the final matches. If you missed them, here's a link to the new CET Sept-Oct 2020 video playlist with the matches in order on our YouTube channel. I want to pass along a personal note of thanks to everyone who participated, the commentators, and to Blank for all the great graphics, Great job. Thanks, Matt

Hi everyone, Here is a quick update: If you don't want to read the details, so far we are still on track to run the next Open Beta - but work isn't complete yet. So there could still be hiccups. As I mentioned last week, the big remaining task is to migrate new or changed code and content from 1.20 to 2.1 so that new players that have their characters copied don't crash. We still have to do a couple other minor things like removing the AVX requirement from the installer, now that we have removed it from the build. Our internal goal is to get a candidate build to start testing by Monday EOD. That will need to be approved by our QA by Tuesday EOD for our schedule to hold. So far we have finished the code migrations from 1.20 into 2.1. That leaves data and content. For those two, we have a couple options: We can try and automatic merge We can accept the newly migrated content from 1.20 We can ignore the 1.20 content and keep the 2.1 content because it's already modified properly Or we can hand merge I believe everything left right now falls into that last category. There are 9 Unreal packages to fix Some audio work and rebuilding the sound banks Some minor map changes And data changes We have divided all of the remaining items across the team, and everyone is working in parallel to finish. More in a couple days. Thanks, Matt

Yep. Missed it. We'll get that pulled down too. Anyone who previously purchased it can keep them. We aren't removing them from inventory - just not selling them any more.

For the OP, Our predecessors made the Trump mask, and after some analysis I made the call to remove it a while back. This was not done for political reasons. Like many other mafia style games, APB is set in an alternate reality where San Paro represents a hybrid of cities in the US. While the world of APB does have politicians, none of them are real figures like Trump. Thanks, Matt

Hi everyone, I knew aiming for the Open Beta this weekend was aggressive, and unfortunately we have hit a minor setback yesterday. As we were testing the new build, we found that new players joining the Open Beta might crash if they have any of the new Joker Store items. This is because we haven't migrated content from 1.20 into 2.1 since Open Beta #2. That process is now started, but it means we won't be able to run the test this weekend. I'll keep you posted. Thanks, Matt

Hi everyone, Small Monday update: We haven't done extensive testing, but here are the early results comparing a build with AVX support to a build without AVX. This was done on a fairly high end PC. The first test was Financial: The second test was Waterfront: NOTE: There is a margin of variance for running these kinds of tests based on pedestrians and cars that go by which means essentially the results are the same. This is just one of the cases where APB does the opposite of what you would expect. In light of this, we are dropping the AVX requirement moving forward. Thanks, Matt

Hi everyone, I'll start with the good news: We're ready for Open Beta #3 and this time we will have all districts online for testing. PROGRESS WITH THE ENGINE UPDATE: The team is pushing hard to do the Open Beta this next weekend so we don't interfere with the Halloween event. There is only 1 blocker left, and it's a last minute item I wanted to try for the community: Removing AVX During development of APB 2.1, we decided to require support for AVX. After the initial Open Beta, we learned that this decision prevented a significant number of players from joining. So as an experiment I am having the team remove AVX from the client to make sure everyone can still play once we migrate over. It's about 3 days of work to recompile all of the supporting libraries without AVX, check them all in, and then recompile a new 2.1 build without AVX. If there is little to no difference, then we'll test without it. But if there is a big enough impact, then we'll have to move forward with it in. Assuming that work gets done by EOD Monday, then I would feel comfortable that we have enough QA time to identify and fix any last minute problems. For this test, we are also leaving a series of Advanced multithreading options visible for you guys to play with. None of these options require restarting the game or even getting out of the district. They dynamically enable and disable multithreading features. I would love to collect some feedback on which options worked best overall for your configuration (CPU, GPU, Memory, Hard drive) so we can set those on by default once we roll out. In terms of bugs, the team has mostly cleared the things we knew about: Vivox should now work. Customizations shouldn't look wonky (after making some larger changes, we couldn't reproduce the skinny character issues) Doors shouldn't get out of sync over the network I am hoping we fixed the character baking hitch that was occurring when new players joined the district. This is a very difficult thing to test in a lab, so the engineers will be capturing performance stats during the test. MOVING FORWARD WITH THE TEST: I want to finish this update by talking a little about expectations. This has been an incredible difficult project to finish. Obviously we are massively off the timeline I originally set. There are still bugs, and we are still not done optimizing the renderer, but weighing the pros and cons, I have decided we are hopefully "good enough" to launch. There are simply too many other more important tasks that are blocked by not releasing APB 2.1. I want to get into better district management, better matchmaking, and cross district play between worlds. Post the 2.1 launch, the team is committed to continuing to optimize performance. There are definitely places where the 2.1 FPS significantly under performs Live. We have some larger changes that we would like to make to the renderer, but they will require much more time to engineer. However, we have asked the internal testing group how the game "feels". And for those that have given feedback and been involved in daily testing, they say that 2.1 "feels" better than Live. So this is where I need the community's help. For this test, let's put away the FPS counter. There will be plenty of time for that down the road. Here is what I would like to see from testers for Open Beta #3: First, ahead of the test, get on Live. Try a mission or Fight Club. Try raising or lowering the graphics settings on Live to zero in some of the visual elements that make or break the game for you. Focus on the feel of Live. The hitches. The mouse input latency. etc. Next, get into the Open Beta and try to do the same things in the same districts. Play around with the graphics settings to try and see if you can get to a similar visual quality. Then try to compare the feel of Live versus the feel of 2.1 and give us some feedback. If we can pull off next weekend for Open Beta #3, then we'll get an announcement up in a couple days. WHAT IS LEFT IF THIS OPEN BETA GOES WELL: During the test you'll see that some things are not up to date with Live. So the only major task that we need to complete before launching is to migrate the most recent changes from Live into APB 2.1. (That in addition to any big blocker bugs we encounter with the test) Thanks, Matt

Hi everyone, This week's update is frustrating, because we are so close to new benchmarks. Unfortunately 2 specific areas were a bit more complicated and couldn't be completed on Friday. I may post mid next week once I get a chance to see where we are at. Thanks, Matt

Hi everyone, I'm long overdue for a more comprehensive update on the Engine Upgrade, so here is a recap of the last couple of weeks. Back on September 6th, I outlined a list of things we were working on. Here is where we stand with those items. Progress with the Engine Upgrade: There is still a lot of thread safety work left to do, but this was a big source of the errors. This work has been completed. We *believe* we have re-architected the mulithreaded code so that all the previous errors have been eliminated. There is still one issue related to Occlusion Query multithreading on RTX cards that causes a bizarre slowdown, so we have that code disabled till we can fix it. We want to allow secondary render threads to use the cache and then track down the specific case where we are setting the per material/mesh state and making sure those invalidate the cache properly so everything gets updated. This work has also been completed. I'm pretty excited about how we fixed this, because after we started testing the new code, we found another issue where the game was destroying the shader cache multiple times per frame. That has also been addressed. We are investigating an issue where specific items are forced to update every frame when they shouldn't. This last item is fixed. We started test driving the new code this week, and while there is some improvement, we're still not seeing anywhere near the kind of performance gains we were expecting. SIDE NOTE: The team has affectionately adopted the phrase "As expected, APB code does the unexpected". For the later half of this week, the team went back and refreshed some older code that integrates with 3rd party tools that allow us to better analyze multithreaded performance. In the past, we have been relying on Visual Studio and 3rd party tools that were working when we took over. These existing tools measure where the most CPU time is being spent. Overall, that technique has been invaluable in finding brute force code doing large tasks in a single loop that could benefit from being multithreaded. However, these tools do not measure things on the GPU, the time spent waiting on a lock or when a process is blocked. On Friday, we finished integrating some new tools that enabled us to stage a full test, capture results, and generate more comprehensive reports. As suspected, we found a significantly larger problem related to how the engine renders Meshes overall. To give an example, our previous efforts to multithread code lower down in the pipeline only account for a fraction of the processing time. The higher level system for actually rendering everything that was processed accounts for the majority of processing time - but it's mostly spent waiting or being blocked which is why these areas never showed up in the previous analysis. The overall rendering is effectively drawing elements on only 1 or 2 threads. It's incredibly inefficient, and we already have a good idea on how to fix this. The team will be moving onto this new issue next week. Alongside these 3 areas listed above, the rest of the team has been fixing VOIP, desync, and other more minor areas. We need those out of the way so we can launch once the renderer is finished. As always, I'm providing these updates in real time with the best information I have at hand. I am (again) hopeful we'll see good progress this coming week, and that I can finally get some better mission district benchmarks. The plan is to spin up Open Beta #3 with mission districts as fast as we can after that. NOTE: After I posted this, I thought I would provide some nerdy details. Rendering in a 3D engine mostly happens in 3 stages. Stage 1 processes the scene. This involves lots of complex routines that gather up and process all the things we need to draw. Some of things we do in this stage are: Identify only the things that are in view of the player's camera. This happens in multiple ways: bounding checks on the field of view, eliminating things too far in the distance, testing to see if an object is occluded (covered) by another object, etc. We want to eliminate everything not in view to avoid drawing far too many things. Recalculate lighting receivers on each object that we are going to render. Process objects for extra data that we need to pass into the next 2 stages. Stage 2 actually draws the big list of things to the scene, which also involves its own set of stages to properly sort objects back to front and render transparency correctly. Stage 3 handles post processing of the final frame buffer (effectively a composited image of the scene once the objects are drawn). This handles a variety of effects including shadow rendering, bloom, iris response, motion blur and more. Stage 3 requires a lot of extra information that was captured in Stages 1 and 2. TL;DR: The majority of our multithreaded work has been in Stage 1. Now we've identified big areas in Stage 2 that are affecting the overall speed of rendering a single frame. Thanks, Matt

Hey everyone, My schedule has been incredibly busy - busy enough that I completely missed last week's update and only realized it today. Sorry about that. Part of the problem is that in addition to daytime meetings here in Europe, I am also leading a massive project in the evenings with the US that keeps me up till 2-3am every night. Big deadline today, so that should free up some of my time to resume these updates tomorrow. Apologies, Matt

Hi all, Time zones are messing with my updates. I got a brief update on where the Engine Upgrade was at Friday morning Pacific time. Progress continues to be good. It's a rat's nest of old code, but we've nearly unraveled it all and put most of it back together better. Internally the big test will be this upcoming week, when we can take everything for a test drive. At this point I am hopeful we will have some benchmarks by next week's update. Thanks, Matt

Hi all, I have reviewed this thread and responded here: Thanks, Matt

Hi everyone, Sorry I missed Friday. I'm currently traveling in Europe, and my schedule is a bit off. This week I'm going to talk about progress first, and then I'm going to talk about the overall state of the player base and what the plan is for rebuilding the player base. Progress with the Engine Upgrade: We had another solid week of working on complex code buried deep in the render system. A significant portion of rendering involves caching material shader parameters, and we were able to clean that code up so it is now thread safe. This greatly reduced the amount of locks. Still to do: There is still a lot of thread safety work left to do, but this was a big source of the errors. Still to do: We are investigating an issue where specific items are forced to update every frame when they shouldn't. Still to do: We want to allow secondary render threads to use the cache and then track down the specific case where we are setting the per material/mesh state and making sure those invalidate the cache properly so everything gets updated. At that point, we'll be testing the new changes against our old benchmark to see if we can run the next phase of Open Beta with mission districts. State of the player base: I've seen a couple threads mentioning the decline in players, and I want to take a moment to comment on that. I think there are macro issues related to games in general right now, and there are certainly micro issues related to APB specifically. If you look at the industry as a whole, there are declining CCUs in most games right now. This is because in many places coronavirus restrictions have been lifted so players who are sick of being cooped up all summer are doing something different. On top of that, students are going back to school, which takes away free time for games. I'm not saying every game out there has dropped players, but in general we are seeing that trend right now. For APB, we find ourselves in a weird transitional place. APB 1.20 (Live) has some systemic issues that can create a pretty bad play experience - mostly centering on matchmaking, new player experience, and various forms of griefing/dethreating. We have a lot of things in the works for 2.1 that will address these issues which have either been completed or are nearly done. But work on the engine has taken light years longer than I anticipated. While we have done 2 Open Betas now, I can understand the frustration in waiting for the rest of the districts and the actual launch. Hopefully everyone has seen our hard work on Asylum and Social, and they know we are committed to getting this finished as soon as possible. I believe we have made good use of this delay by overhauling the game's entire monetization system. You'll be seeing more of this in September. And I think once APB 2.1 does launch, new players will find the game much more attractive because of our changes. Rebuilding the player base: With the current state of the game in mind, I have been faced with the pretty tough decision of whether to start spending lots of money now on advertising and promoting 1.20 or continuing to wait for the launch of 2.1. That money has been set aside, but timing is everything. I believe we will only get one shot to bring back players and show them the new APB experience. For that reason, I have intentionally held off promoting 1.20 because that would largely be a short term gain and a long term loss as new players enter 1.20 and then bounce for the same reasons we are upgrading everything. Waiting does have its consequences. Just know that advertising and promoting this game is not a question of IF. It's a question of WHEN. APB 2.1 has a lot of features under the hood that will either address or start to fix the remaining core issues in the game. It has much improved console experiences which at one point during their launch added significant amounts of players, who then left when the performance was so bad. With server cross play, we can bring the entire community together in a much better way. It also has integration with Anzu for in-game ads that will take more pressure off players to spend money. Anzu has also committed to helping us with a large Twitch campaign for awareness at launch. Hang in there. I want to end this week's update with a note to those of you who have continued to support us both in words and with purchases. Thank you. We wouldn't be able to do this without you. Thanks, Matt

Hi everyone, I'm going to sneak this update in under-the-wire for today. I want to start by acknowledging that this part of the Engine work is frustrating. It's noodley and tedious, because we have to run the game over and over under certain conditions to find bottlenecks or crashes. I know sometimes these updates seem endless. I'm sure it appears that I talk about the same stuff or the same goals (like speed optimization) all the time. However, this is necessary to get Action Districts up to speed. I feel very good about this week's progress. We have started work to address the stalls. Over the last two updates, I talked about how much we are throwing at the Graphics card (GPU) and the problems that causes. This week we hand inspected logs for all the calls per frame, and found that a large percentage of them are executing the same command over and over. Each of these instructions is wasteful and costly if we don't need it. So we have started work on a State Caching system that saves values every time we pass them to the GPU across a wide number of different types of variables like Shaders, Samplers (textures), Parameters, and Buffers. Then when we go to run that command again, we check the value against the new value, and if its the same, we can skip that instruction. I am honestly shocked there wasn't a system like this in Unreal already (I am 99% that Unreal 4 has a system like this). Some early work was done on this system, but based on my math, we should see a significant speed improvement. We also finally figured out the source of the D3D crashes. This was super hard to reproduce, but we finally found that deep in the multi-threaded rendering code it was saving copies of how Meshes attach to Shaders. But other threads can actually overwrite the Shader, which then means drawing the Mesh is now invalid (wrong Shader). This sort of code is not "thread safe". We did a temporary fix for the issue, but it involves locking all the threads when a mesh is drawn. That's incredibly bad, because it slows things down. But we now have a benchmark build that doesn't crash. Starting on Monday, we will be re-working all those bad places where values are stored, so we can remove the lock and make drawing Meshes thread safe. Since we have a benchmark, we will see the speed improvements as we go. We added optimizations for 2 types of Shadow rendering. We are focusing on the Central Park area in Financial, which is one of the slowest areas in the game. There are a number of issues that make this area bad, and they are related to how we handle shadows from foliage. These two optimizations went in fairly smoothly, and they are the "pattern" for what we want to do throughout other parts of the code. Early tests indicated a 10% improved FPS. We have other areas that are very similar which we can now easily apply this new pattern to in order to gain more speed. Thanks, Matt

Hi everyone, I'm going to be moving my Engine Updates to Friday, now that I don't post CS stats. That means I don't have to interrupt my weekend to get the the updates out. We got back in on Monday and spent the first part of the week digging through nVidia driver documentation and then trying various code paths/options for getting a better sense of how much we can throw at the card before it stalls. It appears the problem is a bit more nuanced that we thought, and may take a bit longer to address. So we're splitting efforts. Part of the team will move onto the other optimizations that we had planned, while another part of the team continues to look at this issue. As of this afternoon, I don't have a status on the stalls. But yesterday, I got into Asylum and Financial to run my own tests, and much to my dismay I found that the game ran slightly slower than before. Classic APB, I thought. After sharing logs and performance data with the team, I was asked what setting did I run the test at... and of course I had forgotten and left everything at Very High expecting the benchmark to line up with our previous Very High settings. I shared last week that we fixed a number of bad issues related to Settings, and that Very High is now not comparable to Maximum. So I went back and tried a test at High, and then at Medium. For the most part, Medium looks as good as Maximum on Live - with one exception related to how far away dynamic lights render. So in theory, the proper benchmark is between High and Medium with some custom values. With that new setup, I was relieved to find that performance had improved for both Asylum and Financial. Once this goes out, I will reiterate - don't jump to Very High and expect it to match Maximum on Live. You guys will need to play with the settings and find what works best for your systems. NOTE: I might add to this later tonight as the devs submit end of week work. Thanks, Matt