Something that comes up a lot when I’m coding is the replication of existing features. Or more accurately, taking something that I did a while ago for a one-off instance of something and trying to replace it with a better, cleaner version for reuse in something else. The most recent example of that is the Blitz’s main cannon.
The Juggernaut already has a tank-style cannon mounted on its trailer that can rotate toward its target independently of the vehicle itself, so I had the basics to build from when making the Blitz. However, I wanted to write the new version in a neater and simpler way to hopefully replace the Juggernaut cannon when it was done. Of course testing new ways of doing something inevitably leads to new problems.
Well, new versions of old problems in this case that brought back memories of making the Juggernaut for the first time. I’ve been dealing with the mildly entertaining (but still frustrating) issue of “helicopter tanks”. That is to say when the turret attempts to turn toward the target it just continues to turn in one direction regardless of which direction is the quickest way to turn. Worse still they keep spinning even after they find and point towards their target, letting off the occasional shot when briefly pointing the right way.
I finally fixed the issue (I accidentally added a full rotation somewhere instead of subtracting half a rotation) so they’re not spinning out of control anymore. I’m kind of disappointed in myself for not recording any of my tests to show you, so I’ll try to remind myself to do so for any future entertaining glitches.
That’s all for now. Sorry for the wall of text, but hopefully it gave you a little insight into the kind of things I’ve been working on. Thanks for reading! –David
This week we have a quick peek at the work-in-progress model of JRC’s light vehicle, the Tenders. Whilst it is stylish, it may not look too impressive just yet but it’ll soon have it’s orange and white branding and be ready to shake those tail feathers on the streets of New Bedlam.
And speaking of JRC, I’ve been continuing to squash bugs and fix issues with the new faction vehicles. Still got a few big problems with the heavies, but those are fairly clear and identifiable so I know roughly what needs doing to resolve them. For example, JRC’s Giant Combo needs to keep better track of its target and know when to stop firing its seemingly limitless supply of seeking chickens. It’s a mildly entertaining sight, but a little frustrating for me.
Anyway, that’s all for now. Thanks for reading! –David
Lately I’ve been fixing a lot of issues with adding the new faction vehicles and I’m glad to say that a lot of them are now resolved. Still dealing with a couple of odd, unreliable bugs (by which I mean they happen inconsistently) which is making them a little harder to track down and fix, but I’m getting close to wrapping them up.
The other thing I’ve been working on is implementing and fixing a couple of new weapons. Most recently I’ve focused on the Boom Box, which is a rear-mounted weapon that has a huge knockback effect to help you escape pursuers. My initial tests with the knockback effect were… more entertaining than helpful, but I learned a thing or two in the process. Not the least of which being that it’s possible to push other vehicles up and over buildings and walls if you really set your mind to it. I think I’ll try to exclude that possibility in the future though.
I’ve also been trying to resolve some issues with the Acid Cloud mines. I figure a single cloud probably shouldn’t instantly get you to full notoriety with the Fuzz because that just seems a little unfair.
That’s all for now. Thanks for reading! –David
Recently I’ve been spending a lot of time on Collateral trying to fix some issues with weird vehicle behaviour. I’ve fixed a few things, however among the remaining issues the Big Larry El Grande will still occasionally refuse to mount their giant burrito weapons. Not quite sure what’s causing that one yet (Who wouldn’t want to carry around a giant burrito?) but I’m looking into it. On the plus side I did manage to fix the JRC Roast Fillet from spawning so that, for some bizarre reason, it looked like it was made of chrome. So there’s progress.
For something more visually interesting, here’s another look at the passenger faces that Mark has been working on. As you can see, there’s plenty of oddity and diversity in the residents of New Bedlam.
That’s all for now, thanks for reading! –David
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