We’ve had a little time off and we’re easing back into things again, and naturally taking some time away from things has its ups and downs. It’s often handy to step away from a problem and come back to it with fresh eyes to help you see a solution you couldn’t see before. I’ve done this many times with problems I’ve had in programming, and after coming back from our break I quickly figured out why a number of new vehicles weren’t spawning with the correct materials. As it turns out it was a simple typo. Whoops.
However, time away can also make you lose track of a train of thought you’d had while working on something. Frustratingly that seems to have happened, despite my notes, with regard to vehicle navigation and now I’ve noticed a handful of AI vehicles have taken to slowly wandering off into infinity. It’s rather annoying, especially since these vehicle issues are some of the last things that need fixing before we can test a stable update.
I’m sure I’ll figure out what I was doing quickly enough, and perhaps even the weekend will be enough to give me a fresh perspective next week. But for now, thanks for reading! –David
While writing AI code there are two main areas to cover. There’s basic functionality, like how things move and shoot and explode, and then there’s behaviour, like when and why things should move and shoot and explode. Today I want to talk a little about some changes I’m planning to make specifically to the Fuzz’s behaviour in the revised AI system.
Firstly, I’ll give a little run down on the way they currently behave. There are always a few Fuzz vehicles patrolling about in the city with a tendency to spawn close to the player. They are managed by an entity that holds records of any vehicle, player or NPC, that attacks another vehicle without provocation. Each of these records also maintains a very simple “heat” level that depletes over time when not in range of a Fuzz vehicle. Heat is added for any additional violence performed with an active record. When the heat runs out, the record is removed and the Fuzz stop pursuing that vehicle.
That basically sums up the current state of things, and being honest it was kind of a slapped together system for law enforcement when I implemented it. I’ve taken time to look at how other open world games tend to handle similar behaviours and decided on some basic plans for my next attempt.
I’m planning to cut back a little on the randomly patrolling Fuzz vehicles. You’ll be a lot less likely to be in line of site to them immediately whenever you start causing mayhem. Instead I’ll make it so that new Fuzz vehicles are spawned at a distance from the criminal (most likely you, the player) if and when they increase their heat level. Speaking of heat levels, I also intend to revise that by having the heat level remain constant when out of range of the Fuzz. However, much like in GTA, after a short amount of time it will completely reset.
Those are just a few things that I’m hoping to implement to make New Bedlam’s police force a little less annoying to deal with, yet at the same time keep them feeling threatening when you create some chaos.
That’s all for this week. Thanks for reading! –David
This week I’m going to talk about the programming stuff I’ve been working on. As I said a little while ago, my main focus lately has been rewriting the NPC vehicle code. It’s been a long journey, and I’m far from done, but I’ll give you an update on what I’ve been trying thus far.
So I started by just throwing a bunch of Actors with a vehicle mesh into a level with a network of paths to see if I could get them to follow said paths. That worked, but obviously wasn’t the most impressive thing since the meshes didn’t turn or anything, they just shifted around.
After that I tried some tests of physics-based movement to try to harness rigid body movement and physical interactions. There weren’t any hilarious incidents, and sadly I didn’t capture any footage of it anyway. In the end I decided to abandon the physics-based movement because of the additional physics tick overhead that was causing me problems.
So for now I’ve gone with much more basic movement mechanics. It took a little tweaking to stop over-turning and swerving, but eventually the vehicles settled into a much nicer pattern. Now I have some basic driving mechanics for a few hundred vehicles populating the scene.
The downside to all of this? Well unfortunately with the lack of physics-based movement I’m having trouble with collisions and physical reactions. The vehicles don’t currently collide with the player or each other, so now I’m focusing on collision issues to try to fix that.
That’s all for now. Hopefully that helps explain the programming stuff I’ve been up to. –David
So lately I’ve been working on rewriting the entire traffic AI system. Essentially the old version of the NPC vehicles were inefficient and kind of hacked together in places. Now that I have a better idea of what’s needed from all of that I’m trying to redesign with clearer goals in mind. I’m also trying to find and use more efficient existing systems within the engine that could help make things run smoother.
This has been met with some…unusual test results. I had some floating static vehicle models with their physics assets independently flipping out. Literally flipping, mind you. I’ve also had so many things fall through the testing environment ground, and that one time when I had about 50 test vehicles spawn inside one another but only collide with the player and not each other. Nothing quite as entertaining as when we got a whole bunch of whales stuck in the wall of a building, but I’ll try to capture any hilarious accidents for you all as my testing goes on.
This testing and redesigning process isn’t going to be quick, but the intention is to improve overall performance by reducing and removing a lot of inefficient code. One of the biggest problems with performance right now is the overhead for all of the AI vehicles, so hopefully I’ll come across the right solution soon.
That’s all for this week. Thanks for reading! –David
We’ve noticed an issue that has also been brought to our attention by players regarding saved games. Some people have accidentally clicked New Game and lost all of their progress when the new game starts and writes over the only save file. This, we thought, is a problem. Our solution? We’re implementing multiple save files.
Essentially you’ll be able to select either to start or load one of 4 game files, meaning it will require more than 1 click to clear a whole game’s progress. It’ll also mean that you can play through the game multiple times without having to delete your previous progress first.
We’re still tinkering with the implementation so sadly no screenshots of this just yet, but it should be working pretty soon.
That’s all for this week. Thanks for reading. –David