Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Combat system design.

Senuka Harbinger
A-Life, one bit at a time
Join date: 24 Oct 2005
Posts: 491
11-21-2005 13:31
My current project is creating a combat system using the mechwarrior table-top rule book by FASA. most of the actual combat sim is programmed in various "chunks" and right now I'm trying to get a very early alpha set up and have come to a fork in the road for my overall design and was wondering if some of the more experienced coders here could give me some insight into my design choices for advantages and disadvantages.

1) Complete HUD system.

All of the combat system's "Guts" would be contained within the combat system HUD that you wear; everything from firing bullets/lazers/missiles to damage, fuel, radar/target tracking, ammo, etc. I want the mechs to be upgradeable so when the HUD is turned on it will send out a message on a channel which the attachments will then report what weapons/armor/engine are available for the player to use. also messages will be sent out from the HUD to the weapons/parts to activate various graphical effects (smoke from severe damage, lazers charging up and firing, etc.) and movement restrictions incurred through damage. other than that all other messages would be sent through links in the HUD

2) Communicating attachments

With this method, all the attachments would communicate on various chat channels, using a specific channel for each info type (ex channel 14 is target keys, channel 15 is damage taken, channel 16 is ammo left, etc.). each time something is said on the channel, the owner's ID is sent out infront of the info, and the HUD checks the owner's ID against it's own owner's ID (this fixes a problem with people using the same mech/weapon types in close combat) before sorting through the data on that channel. this also makes graphical effects for firing relatively easy to program within the jet/engine/damage/weapon script(s) for each attachment, but there is still near constant communication between the weapon and the HUD to give updates on ammo/energy/fuel/etc. counts for a graphical representation on the HUD


I don't really see a significant advantage of one over the other, so I'm not sure which way to go, as once I choose a certain way, it would take a hell of a lot of work to undo it to the other when a major advantage is found.

[edit] Here's a short list of things that are being communicated (there's probably a dozen more but I can't get ingame right now to list them all):
Damage amount (integer)
Damage location (string if it's being sent by an attachment, vector if it's being sent by munitions)
Current target (key and string)
Secondary target (key and string)
ammo (integer)
teammate 1 (key and string)
teammate 2 (key and string)
number of hostile missiles (integer)
fuel (integer)
particle effects on/off (integer and string)
weapon type (string)
Current target's last known position (vector)
Current target's damage (sent as a string from the target, stored as a list)
weapon charge time (integer)
Senuka Harbinger
A-Life, one bit at a time
Join date: 24 Oct 2005
Posts: 491
11-28-2005 11:13
I figured I'd post a reply to myself since this seems to be such a major thing to me with combat system design that other people considering making their own combat system might want to look at why I took this route.


I went ahead and went with the HUD being the full controller for the entire combat system as it removes almost all the listeners for the various weapons I had, and makes the transmission of information from one part of the HUD to the next much faster than having to go through a series of llsay which then have to be listened for and further filtered based on what attachment said what and what info was transmitted. Also, it's helped me remove virtually all physics from the combat system, and I instead rely mostly on "special effects" generated upon getting hit than bogging down the system with many bullets/lazers/missiles. that may not even hit my target. It's also made setting up damage systems for a locational damage meter much easier as the damage info is only listened for by one receiving prim, and it then filters out the appropriate info into the child prims so that instead of using listener for each location that may or may not take damage, I'm only using a single listener.