GUNS - Reloaded

[NecroDOME]

War of the worlds good movie!

That would be a lot of particles

[WILL]

Hey cool idea Jason.

You should be fine with the Death Ray type effect, I don't think that you can get sued for what half of Hollywood does these days anyhow.

Maybe you can combine the heat distortion and the ray together... Esp. for the colder climate maps. Add extra 'smoke' or steam from the firing turret.

Hmm... as for the military. Probably best to make the very weak. I mean... there are only just puny 'hunams' after all. [size=9px](Btw I stole that from Star Control 3 because it was just hilarious. Yeah I'm one of those guys who likes the 3rd one best despite it's obvious continuity explosion. )[/size]

Oh and don't worry about being a post whore. We need more of them like both you and I. [size=9px](I guess that makes me the Post Whore King :lol[/size]

[NecroDOME]

Offtopic: Pimp my post

[jasonf]

It's been ages since my last post about this.. partly because I've been a lazy arse and not done any work..
things have been.. difficult.. of late for reasons I won't go into here.

But also because the next task to complete was going to be a complete sod to do. Basically, I had to revisit my entire design for my weapon system. The version so far was based on a very similar system to my old game (i.e. crap), in fact it was pretty much ripped from it and converted to use SDL as opposed to DelphiX.

I wanted to make a generic weapon class which I could inherit from to make specialisations for each weapon. This meant I had to do a LOT of work refactoring my original class structure and more importantly, Unit structure..

Delphi isn't very good at handling circular references so it boiled down to two options.

1, Put all of my classes in the same unit...
or 2, put each class in a seperate unit.

I've actually opted for 1.8 which is put most of the classes in seperate units but keep some very very similar things together with the option of splitting them out later..

It's been a headache to say the least. I've had to add additional classes to get around the circular reference issue, But now it's done.

I've pretty much got my plasma cannon working the way it was before using the new system and I've probably got one more day on getting things tidied up then I can get to work on the other weapons.

They should be a breeze to do with the new class structure now as the main weapon class handles all aspects of weapon simulation. Everything from battery levels, power levels, ammunition, even gyroscopic forces.

Now I can write my minigun weapon which..
a) generates ammo over time
b) has a spin up time
c) once up to speed is really hard to turn due to gyroscopic forces of the barrel
d) can overheat

Now I've got to re-teach the AI how to aim using the new class structure 'cos at the moment, it's really, really confused

[WILL]

Wow sounds really sophisticated man. All that work indeed must be worth it.

I'd hate to have you have a revelation at this point, but do you know about this trick?

[pascal]type
TSecondObject = class;

TFirstObject = class(TObject)
OddballRef: TSecondObject;
end;

TSecondObject = class(TObject)
Bob: Integer;
end;[/pascal]

The TSecondObject = class; allows you to make reference to another object that is not in it's hierarchy. Something I learned while making my own space shooter engine. (ala Scorched Earth style)

Now I've got to re-teach the AI how to aim using the new class structure 'cos at the moment, it's really, really confused

So does that put NN on the table? Seriously, it would be great for this!

[jasonf]

Yeah, I know that trick and I use it.

I've got a Dropship class. It has to know about the FuelCanister class and vice versa. They attach to eachother.

If the fuel canister is destroyed while the Dropship is carrying it, the fuel truch flies off.

If the fuel canister hits the ground the Dropship flies off.

If the Dropship is hit, it drops the canister and flies off, the canister then falls to the ground and explodes on contact.

I could probably have coded it differently, perhaps had a TCarryable object which the Dropship can carry and apply all of the above rules to it. Then make the FuelCanister inherit from TCarryable. But the Dropship will only ever deliver fuel so it's not an issue.

I don't really like using that trick though, it seems messy. I feel that the compiler should be smart enough to figure it out without me having to resort to tricks.

[WILL]

Ah... well then you'll hate my next trick.

Use a TBasicShipParentClass pointer and check for their type every time you need to see if it's a specific kind of ship object. I did this a lot, not realizing how much memory leaks I put into the poor thing.

The trick worked great, but I handled the memory management badly so it made things tricky to manage. I'm sure you can do a better job though, esp. since you are much more skilled than I was back then.

[jasonf]

I'd prefer to use Events to be honest.

I use Events throughout the game. I've tried to stay as far away from pointers as possible. The language is good enough so you don't need to use pointers directly I think. The only real direct use of pointers is in the JediSDL stuff and the software rendering code. I've insulated my work from the pointer depenant code as much as possible.

Now all I need to do is check if the event code is assigned before I call it.

[jasonf]

After a lot of mad typing and swearing, mostly swearing, I managed to get my weapon system working the way it used to. No mean feat considering the amout of trauma my engine had just been through.. complete class restructures can be fatal to a project in my experience.

So I got my plasma cannon working and I decided to see how flexible the new system is. I changed the cannon fire rate and increased the number of bullets it could fire from 5 to 40.. It was completely devastating.. It's given me the confidence that my minigun idea is possible.. as I'd pretty much made one already.

At the moment the AI is still confuses as how to use this new weapon system and the bullet tracking doesn't work.. Although I'm thinking of removing the bullet tracking feature altogether and using a simpler mouse move camera, as I've mentioned before.

I've also built a generic damage system into the game. All objects can be killed unless they are specifically set to be immortal. Whereas before, each entity had to be told how to die and the bullet had to be told how to kill each entity.. now the base class deals with all of that stuff and just asks the derived class to die or explode in its own way as it sees fit depending on the impact and heat damage done by the projectile minus any armour which the object may have, the armour then gets depreciated by the impact depending on the armour's hardness. Much better I think.

Restructuring the code also means that things are easier to find. Although I am having difficulty with the Turbo Delphi Explorer when it comes to project management. It won't let me add the units to the project it seems.. so I have to either right click on the file in the uses clause or use File->Open to get at the file. Also, I'm finding the Complete Class at Cursor function sometimes gets really confused and chops up the begining of existing procedures.. like chopping of the 'p' of the first procedure then the 'pr' of the next. Anyone know of a fix for this?

[jasonf]

Oh the bugs...


With any amount of refactoring, bugs crop up. Bits missed, bits which now work differently.

One of the oddest bugs I've encountered is the immortal penguins which appear to die, but then continue walking.. it's actually kindof eerie.

My Mini-gun is working fairly well. I'll post some screenys soon showing the bullets and the massivly oversized minigun. The bullets I'm using at the moment would be better suited to the heat-ray weapon. So I'm in the process of drawing some new bullets. It should look quite cool.

I've got a couple of bugs where the barrel isn't rotating as it should and there's a bug in my angle calculations, but I'm confident that I'll have those sorted soon... well, as soon as the party season is over anyway

Anyone who's considering refactoring their code.. be prepared for the emptiness.. especially if you had got something working before and now you've got to pick it apart to make it technically better whilst getting the same result you already have.. I find it to be quite soul destroying, all the extra work just to get to the same point. It feels like Sisyphus's punishment. But once you're past that, if the new structure is better, you can do more than was possible before. But it's hard to push past that empty feeling.