Game Development Community

How To: Weapon individual Stats - Clip Size, Bullets Remaining, Projectile type, Reload Time

by elvince · in Torque 3D Professional · 03/24/2010 (3:29 am) · 8 replies

Hi,

In my game, I need to store stats per weapon (ie on RocketLauncher I have a an big clip, and on my 2nd RocketLauncher I have a small clip), I also need to influence some states time depending of the player stats (ie Stats X will help to reload faster).

As per my understanding :
*The current implementation of Weapon have shared stats accross all players (including AI).
*They are managed by datablock, so that means if I changed a parameter, it will change for all.
*They are no instance of weapon so we can override information.

As it can be a fair amount of work to manage this, I would like some help of the community to share what the best approach to do this?

Ideally, I would like to keep the current datablock system as a "Template" definition of a weapon and then override some variable per weapon instance. In my game, the player can have 2 rocketlauncher with different stats. One simple example is, on RocketLauncher 1 I have fire rocket and the 2nd I have poison rocket. So when I switch of weapons, I need to know what type of Ammo I should use. (I know this example is simple and can be treat by scripts, but it is just in the purpose to clarify my thoughts).

A basic implementation can be:
Each time the player have a new weapon, I create a new datablock ShapeBaseImageData based on the "template" datablock and update the stats & variable.
Then I send the datablock to the client who own the weapon. (need to create a specific function to send only 1 datablock)
Then when I want to use this weapon I'm calling the new ShapeBaseImageData so everything should work with the current code?
Did I miss something?

The only downside I see, is that the server will have all "weapon instance" as datablock. Is there any limits for this?
*We also need to take into account that after the initial datablock count, nothing should be send to all clients but only to individual clients to save bandwith.This is true in particular when a new player is joining the mission.
*The weapon template do not have to be datablock. This will save bandwidth & loading time.

thanks,


#1
03/24/2010 (5:46 am)
Just off the top of my head, first cup of tea of the day ...

How about something along the lines of ... you give the player a variable, and then script it so that when they pickup (to place in their inventory) or just whenever they select the weapon ... it mounts whatever weapontype goes with that variable? That way you'd already have all the datablocks before start and wouldn't need to change them on the fly.

Example:

%variable=1; clip =2; reloadtime =slow;
%variable=2; clip =2; reloadtime =fast;
%variable=3; clip =6; reloadtime =slow;
%variable=4; clip =6; reloadtime =fast;
etc etc

Not sure how that would go with overhead, depends on exactly how many of these you have.

I use something similar for my AI in singleplayer, my AI don't use playertype weapons but are given a special AI weapon (helps with friendlyfire and a few other things) divised from %weapontype and a %team.
#2
03/24/2010 (6:38 am)
Hi Steve,

Thanks for your answer. For example, my reload time are managed by State per weapon. Even with a variable, I would not be able to change the reload time or I need to manage it by script and do use the State machine.

I would like to find a way to change the current behavior and keep all the great opportunity of T3D like state machine.
In fact, I would like to find the less impact implementation so all the current stuff of Torque are still working and it's easy to maintain/update.
#3
03/24/2010 (7:08 am)
Just to check that we're on the same wavelength now I've had a few more cups of tea and the brain is working ...

My above idea obviously doesn't alter the States - that'd require some significant coding which I don't have the knowledge for - but the idea would be to replace the player's weapon with the new one (with different reload time) according to changes in the player's %variable.

%player.variable=1; mountimage.rocketlaunchertype1;
%player.variable=2; mountimage.rocketlaunchertype2;
etc etc

This is a bit of hacky way of doing it, and the "truer" way would of course be to recode the whole weapon FSM system ... which sounds like a big job.
#4
03/24/2010 (7:23 am)
This can't work like this.

In fact, If I understand properly you suggest to create all "possible" datablock and then switch depending of the context.

This might have been a solution but this won't work for me, as I want a player Stats "Reload" that depending of his value will influence the reload time of the weapon based on their level.
So it's not fixed value Fast, Normal, Slow but calculated value.

[Edit]
I know this is not a simple implementation, this is why I asked community feedback before going into it :D
#5
03/24/2010 (10:49 am)
Hmmm, calculated value, I see why you'd then be swamped with a ridiculous number of predefined datablocks in my work around.
#6
03/24/2010 (11:21 am)
You could set your states to not use the timeout and then use the statescript call to process your animation or trigger pull. You will need to expose setImageState with a console method to move to the next state manually. But doing that you can control everything based on a players stats.
#7
03/25/2010 (1:57 am)
Good catch Ryan, I will think about it, as I need also variable like how many bullet left in clip per weapon, I will need to manage that on player too with array/variable.

I need to see if I won't have issue with other transition other than timeout one :D
#8
03/25/2010 (10:16 am)
There are several resources dealing with ammo clips. I haven't played with any of them so I couldn't recommend one over the other. If you want to maintain different ammo amounts per clip then you will probably have to create a storage methodology out side of the inventory. Then when you reload a clip in the weapon just update the inventory ammo count with the amount in the clip. That would be an easy solution. Hmmm....might have to play with that, damn here comes a new project.