Skip to main content
gamedev.net
🔒 Locked

Making weapons

Started by Dauntless Apr 24, 2003 at 10:08 PM 39 replies 2.6k views
Original Post
Dauntless
Dauntless
I''ve been having some trouble trying to figure out how to do my weapons sub-system. My dilemma right now is figuring how to build offensive systems for both vehicles as well as infantry. My game takes place in the not too distant future (but more than a 100 years), but weapons technology has not significantly advanced too much. In essence, I''ve boiled weapons down into several categories, but I''m not sure how to fit it all together. Here''s my weapon breakdown as follows: Trajectory: Direct fire- attack is launched directly at target Indirect fire- attack doesn''t fly in a straight line Both Targeting: Line of Sight- target is lined up in sights, round flies in straight line Guided- projectile is corrected in flight to better hit target Homing- a guided projectile is actively guided to the target, whereas a homing weapon is passively guided) Observed- indirect fire is often observed, and then corrected Weapon Delivery System Kinetic- a round is delivered through kinetic energy to impact target Energy- weapon fires a non-material form of energy to deal out damage Pressurized- weapon uses a substance which is released via pressure (flamethrower). Kinetic weapons so far are subclassed (though I''m not sure if I''m going to do this inheritance-wise or use aggregation with sub-objects to create this effect) into: Chemically propelled- old-fashioned primer charge or modern binary propellant reactions used to accelerate a projectile Magnetic- projectile accelerated via magnetic rails along the barrel Self-Propelled- rockets or jet based projectiles which provide their own flight characteristics Energy Weapons so far only come in two types: Lasers- detonation lasers using chemical charges to generate the energy output and optical systems to amplify the photonic discharge Plasma- Shells of liquid hydrogen are superheated via a laser in amagnetic chamber until it turns to plasma, and is ejected via magnetic rails to the target. I think the first step is to ask what kind of Weapon Delivery System the weapon is. From this, the components necessary to create the rest of the weapon are determined. For example, let''s say you want to create a Direct fire, Kinetic weapon that is chemically based. Now that you know it is a kinetic weapon, you know that all kinetic weapons have the following parts in common: Receiver- Where the firing chamber is Barrel- the part of the weapon that guides the projectile (not always in self-propelled weapons) And every Receiver is composed of: FeedSystem- how the projectile is loaded into the chamber Magazine- a device that holds the ammunition It took me a long long time to figure out that the characteristics that we think of for a weapon...it''s damage, penetration, maximum range, accuracy and attentuation, are actually dependent on the type of ammunition loaded in the weapon. And the kind of ammunition that a weapon can use is in turn dependant on the barrel and the receiver of the weapon. For example, you have to know what size ammo fits in the Receiver and Barrel, and the Receiver determines how much energy can be imparted to the ammo (or in the case of railguns, determines the capacitor charge used to accelerate the round down the barrel). So now I have to figure out how to design the ammunition as well. But I''m still trying to figure out exactly how I should design the weapon subsystems for each classification of weapons....Trajectory, Targeting, Weapon Delivery System, and Weapon Type. Should I go the inheritance route? Or try to extract the common information and put them into sub-objects which are contained within the subsystems? I want my system to be as configurable as possible. I thought I''d use the aggregation route...but the problem with that is that each kind of weapon subsystem classification has game rules associated with it. For example, Direct fire and Indirect fire weapons have different rules for combat. Guided and Homing weapons also have different rules. Even the kind of damage a weapon does is dependant on the type of damage the weapon does (is it a pure kinetic weapon like an APFSDS round or does it use a shape charge like a HEAT round?). Doing a class inheritance may make it easier, but it may also stifle the ease of adding new weapon types, because game rules will also have to change. On the other hand, if I don''t make stipulations for differences between weapons, then some of the flavor of different weapon types gets lost.
The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants. We know more about war than we know about peace, more about killing than we know about living. We have grasped the mystery of the atom and rejected the Sermon on the Mount." - General Omar Bradley
Dauntless
Dauntless
I just thought I should clarify how the actual ammunition is created as well. In the case of kinetic weapon delivery systems, they throw "shells" at the target, and the weapon in combination with the round itself determines things like damage, accuracy, penetration, attentuation, etc etc.

So the first step is determing the size of the round itself. The larger the round, potentially the more damage it can do. But there''s a tradeoff. The heavier the round is, the more power the gun needs to accelerate the mass of the round. And the power that a weapon can deliver to accelerate the round is based off how sturdy (and therefore how large) the receiver is (in the case of chemically propelled weapons) or the banks of capacitors in the chamber (in the case of railguns). Along with the mass of the round is its diameter. Rounds can also do two kinds of damage to a target, through kinetic transferall (the round is simply a slug or sabot which attempts to penetrate armor via it''s own kinetic energy, or through a warhead which delivers an explosive or other energy transfer upon contact with the target. The former kind of round wants as much velocity imparted to it as possible, as well as a small diameter but high mass. The latter kind of round simply wants to have high mass and volume so that it can contain a large warhead. The trick here is that the chamber of the gun can only fire rounds of a predetermined bore diameter (and normally though not always of a predetermined length).

Given this, a weapon with a low bore diameter to length ratio will have good flight characteristics. For example, if the round is say only 25mm in diameter, but is 300mm long, it will have excellent flight characteristics (more accuracy, better attentuation and higher max range) than a round that is 125mm in diameter, but also 300mm long. The other concern is that each round if fired from the same gun, will have the same maximum amount of energy imparted to it....therefore even though both rounds can have say, 15,000 joules imparted to it, since the narrower round has less mass, it will have a higher velocity. Also, given that Force = mass X acceleration, and that Pressure = Force/area, you have to juggle the concerns over round diameter, mass and length if you want a kinetic kill weapon.

For rounds that use warheads, the greater concern is getting a large capacity warhead on the round, so it''s sort of the opposite almost of a kinetic kill round. While these kinds of rounds often have poorer ballistic characteristics of their KKR cousins, they are more versatile, and at closer ranges, may be the preferred weapon of choice. A warhead round can be filled with HE (high explosive) for use against infantry, CLGP (cannon launched guided projectile) rounds to achieve top armor hits and better accuracy, HESH (high explosive squash head) for dual purpose armor penetration and high area fragmentation (and good against ceramic based armors), Magnesium rounds to start fires as well as many other role capable rounds. This reason alone is the major reason why railguns have not supplanted traditional large bore Chemicall Propelled Guns (CPG) in the future (though there are large bore railguns, they lose the efficiency of small bore design and are not as popular).

Hopefully people will better understand how I''ve seperated the ammunition from the weapon delivery system itself. I''m still working on the energy based weapons though, and if anyone has some comments or suggestions they''d be welcome.
The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants. We know more about war than we know about peace, more about killing than we know about living. We have grasped the mystery of the atom and rejected the Sermon on the Mount." - General Omar Bradley
Obscure
Obscure
quote:
Original post by Dauntless
It took me a long long time to figure out that the characteristics that we think of for a weapon...it''s damage, penetration, maximum range, accuracy and attentuation, are actually dependent on the type of ammunition loaded in the weapon. And the kind of ammunition that a weapon can use is in turn dependant on the barrel and the receiver of the weapon.


Are you going to allow for a weapon to fire multiple ammo types (even though the barrel and receiver stay the same). Example - the old 19th century cannon, which fired cannon balls, airburst shells or canister rounds. A more modern example - your artilary may want to fire HE shells to hit armour, airburst/shapnel shells to kill ground troops, gas shells or smoke rounds.

Dan Marchant
Obscure Productions
Game Development & Design consultant
Dan Marchant - Business Development Consultant
www.obscure.co.uk
Dauntless
Dauntless
Yes I will. So far, I''ve mostly been working on kinetic and energy , but I decided that each Magazine object holds different ammunition types. The exception is if the feed object is of the type, Single Shot Manual (like for example a bolt action rifle, or a breedch loading cannon), in which case a loader has to manually select the ammunition type from storage (and really, the storage is just a different type of magazine). Normally magazines aren''t mixed with different ammo types, but it depends on the magazine type.

There''s tons of function calls made whenever a weapon is fired in my game.

Step 1. Check for line of sight to target (to determine firing mode)
Step 2. Check weapon firing mode (its trajectory)
Step 3. Select ammo type (passed in as parameter)
Step 4. Call to Feed type which determines rate of fire
Step 5. For each Feed.load() call, Magazine object subtracts load by 1 if Load is 0, no fire possible
Step 6. Hit calculation
Step 7. Damage Calculation

I would eventually like to make my design system robust and open ended enough to allow for historical weapons as well, including as you mention old artillery and even flintlock muskets. Partially I''m going to do this through technology levels. Tech levels will be rated from 1 through infinity and it will act as a both a pre-requisite for certain weapon types, as well as a pool of points for which to "tweak" various settings.

For example, let''s say that the base tech level is 10. This allows you to create all the weapons I mention above. While designing a gun, you want your gun to be more lightweight than others. Most games accomplish this by making the gun more expensive to achieve this. However, I''ve been thinking of a way which lets players introduce "design engineering savy" through the Tech Levels. So in this case, by spending Tech Level points, you can adjust the weight of the object without raising the price. Another player may want his rifle more accurate than the baseline, so he''d invest his tech level points in that way. And essentially, you can "buy" tech level points to increase stats in this way.

Always though, all of my Modules characteristics are private, and are never directly modified. Instead, the characteristics are determined via accessor member functions which can pass the amount of tech level points in as a parameter.
The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants. We know more about war than we know about peace, more about killing than we know about living. We have grasped the mystery of the atom and rejected the Sermon on the Mount." - General Omar Bradley
Doolwind
Doolwind
Dauntless-
Your ideas sound good, I just wanted to give you some advice that you may or may not have thought of with respect to making the system "robust and open ended".

When developing your different components make it as object oriented as you like, don''t worry that a tank may comprise of 10 different objects (turret1, turret2, projectiles for each turret, and each of them having subclasses based on their types).

I started to worry when I was putting my classes together that I was needing to "burrow" to deep when callling the fire method of a units weapon for example. In the long run it has actually made things a lot simpler to have this complex design from the outset. Things just seem to logically fit together now and when I add a new type of weapon it is a very simple process. By keeping all the subcomponents of each weapon broken up you can reuse a lot of code (good Soft Eng practice) and your game will seem more coohesive to the player.

Another point is the use of external text files or similar for the actual units and weapons. While you make up the classes for the types of components of weapons and units, the actual unit can be described in an external file. For example you may have a "missile" class which describes characteristics about how the weapon will fly, and you may also have a "nuclear warhead" class which deals with damage for a particular weapon. This way instead of making a "Tactical Nuclear Missile" class, you can set it up in an external file which says that for the "Tactial Nuclear Missle" the "flight" part (data item) is missile, and the "warhead" part is Nuclear Warhead.

I have found this allows more flexibility and while it may not be applicable I just thought it may help if you thought about during your design.

Doolwind
Dauntless
Dauntless
I''ve been slowly learning XML precisely so I can have XML config files for all the units and sub-units in my game. So for example, you can take a HullModule that has been configured in a text file, and then plug in an OffenseModule that you created earlier into the HullModule. I''ll have to develop some sort of validation parser though, since I don''t want people to directly modify the XML file to gain direct access to the private data characteristics. The HullModule is the master Module into which all other sub-modules are "plugged" into, so somehow the HullModule has to validate what kinds of Modules can plug into it (for example, you can''t plug in a 120mm smoothbore cannon onto the hull module of a HMMWV, nor can you have a TurretModule, which is a sub-class of HullModule, be larger than the HullModule it is bolted on to).

Really, my design system is a bit overkill for a strategy game, but I''d eventually like to make a more tactical game out of it as well (currently, I''m aiming for Divisional level combat in my strategy game, but I''d eventually like to make a company level game which focuses much more on tactics), so I can reuse what I''m doing now for that game down the road.

As I''ve been working on my game, I realize now that Vehicles are the easy part...infantry design is going to be much harder since it''s in some ways less modular than Vehicles. I''m also still panning out the concept of my Cluster design, and how individual units integrate into the Cluster, and how the Commander class controls the Cluster itself. Keeping track of data is starting to become a nightmare, because each individual unit stores some information into itself, the Cluster stores certain information about itself, the Commander must have access to all of this information, and the game world itself must know the information about the individual units, the Clusters, the Commanders, and the Orders those Commanders are given.

Ah well, one step at a time
The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants. We know more about war than we know about peace, more about killing than we know about living. We have grasped the mystery of the atom and rejected the Sermon on the Mount." - General Omar Bradley
Doolwind
Doolwind
How far along is you game going?? Last I spoke to you was about 3 months ago. I am still intriguiged as to how your Cluster design will turn out. I am trying to decide which direction to head with unit control.

Just be careful with your use of XML. It seems to be the "fad" at the moment and people are using it a lot where they shouldn''t. Just remember that it is quite verbose so don''t use it for anything that may travel over a network. It may be easier if you design your own format for units.

Doolwind
Dauntless
Dauntless
Gosh, I''m still in the analysis phase right now. The only thing I''ve actually been coding is the unit design system. Most of my work so far has been trying to do some UML modeling; both for object design and interaction between objects.

Unfortunately I know next to zero about AI programming, even though my game requires a heavy dose of it. I hope within the next month to put up a webpage with some of my UML diagrams and source code, as well as my notes on the game design and game philosophy....including background information on the game world itself.

I''ve also done zero work on the graphics, audio or input subsystems, though I''m planning on tackling the I/O subsystem soon (which is why I''ve downloaded the SDL documentation and trying to dig up any SDL tutorials). For graphics, I''ve been looking at the OGRE engine, as it seems to be very well documented. More than likely though, I''ll implement the graphics via SDL on some kind of 2d tile system. But inbetween going to school, working, and boning up on python and XML (not to mention C++) I have virtually zero time to do anything else. That''s why I want enough of a base and game conceptualization ready so if people would like to jump aboard, they''ll have a good idea of where I''d like my game to head. Of course, if people would like to help me out, my game''s going to be open source....so they have to be cool with that.
The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants. We know more about war than we know about peace, more about killing than we know about living. We have grasped the mystery of the atom and rejected the Sermon on the Mount." - General Omar Bradley
ElAntonius
ElAntonius
Why not try simplifying your current system?

While it is more inherently realistic to separate the gun from the ammo, for example, it would be far easier (to code and for the player) to simply have a gun with set characteristics.

For example, having a gun for direct fire and another for indirect fire is much simpler than having the different ammo in the same gun, especially when you have lots of different types of guns.

If you separate the ammo, not only does the player need to worry about what his tanks are equipped with, but what kind of ammo they have too.

"Oh crap man, it was artillery mode"

Moo.
Moo.
Dauntless
Dauntless
ElAntonius-
There''s a variety of reasons why I''m doing my system the way I am. While I do enjoy realism, it''s not the primary reason I''m building the system this way. I''m doing it mostly so that me the game designer isn''t limiting unit choices upon the player. In other words, I want the player to be able to easily create new weapons, vehicles, armor types, defensive systems, sensory systems, EW systems, etc etc and plug them into a chassis to create a brand new vehicle. Ditto for infantry types. I''m even going to allow the player to design his own military organization. Why should I the game designer force a 30man platoon on the player? Why must a tank platoon be 4 MBT''s to a platoon?

Not only does this allow the player to create armies of his own choosing, it also means that players will never know quite what to expect. In all other RTS games, eventually, every player figures out what combos of units work against other units. So it boils down to a race to see who can make the most out of his resources. In my game, it takes awhile to figure out the capabilities of your opponents forces and vice versa.

In the single player game, there will be pregenerated armed forces to fight with so you don''t have to scratch build everything. But in multiplayer, the sky is honestly the limit. Not only can you create your own units and military organizational structure....you can design your country itself (somewhat like Empire Earth). Want to play Russian style with masses of (poorer) quality troops and equipment to overwhelm your enemy? Maybe you want fewer troops but extremely well trained and disciplined? Perhaps your country is small with few resources, but the people are fanatical and rarely have to take morale checks.

In essence, the player will have pools of points dedicated to building the country''s resources, infrastructure, and fighting forces. My game is not going to be your typical "build your nation and fighting forces as you play" type of game. The world will already have massive armies at your disposal. There will also be a strategic scale map as well as a tactical scale map on which divisional scale battles will be fought.

So, yeah, I could have just said, "okay, here''s an M256 120mm binary propellant smoothbore cannon, and this is a M204 155mm towed artillery howitzer", but I don''t want me as the designer to chose the play style of the player. Ditto for battle maps. I don''t want the player to be forced to fight battle on maps I''ve created, so I''m trying to come up with a pseudo-random map generator which takes basic terrain detail from the strategic map to create the tactical battle map.

It''s all about freedom baby yeah
The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants. We know more about war than we know about peace, more about killing than we know about living. We have grasped the mystery of the atom and rejected the Sermon on the Mount." - General Omar Bradley
Dauntless
Dauntless
oh, btw, the AI commander will select what kind of ammunition will best be used against various targets according to some simple state rules (if the target is at such and such a range, and has such and such an armor level, then use this ammo type).

However, worrying about what kind of ammo to bring to the fight IS important. Generally speaking, most armies carry standard loads which can be tweaked, but it takes time. To me, logistics and supply are extremely important to battlefield considerations. I have another specialized AI class called "Quartermasters" who essentially are specialized in dealing with supply lines. They take "requests" from the player and the AI field Commanders and do their best to route supply transports across various transport network nodes (Distribution Hubs, Waypoint Nodes, Supply Centers) to get supplies from the homefront to the battlefield.

So ultimately, weapon loadouts will be taken care of for the most part behind the scenes. Hopefully someone can help me with adaptive AI techniques so that the AI Commanders can learn what best suits their forces when they requisition for supplies. And of course, this all ties in with good intelligence. If you think your enemy''s forces are mostly infantry, you''ll probably want your weapons loaded out with lots of HE, Beehive (flechette) or FASCAM (field artillery scatterable mines) type ammo. But if it turns out your enemy mostly has armored vehicles, you might be in deep doo-doo. So versatility can be a drawback.
The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants. We know more about war than we know about peace, more about killing than we know about living. We have grasped the mystery of the atom and rejected the Sermon on the Mount." - General Omar Bradley
Flarelocke
Flarelocke
quote:
But I''m still trying to figure out exactly how I should design the weapon subsystems for each classification of weapons....Trajectory, Targeting, Weapon Delivery System, and Weapon Type. Should I go the inheritance route? Or try to extract the common information and put them into sub-objects which are contained within the subsystems? I want my system to be as configurable as possible. I thought I''d use the aggregation route...but the problem with that is that each kind of weapon subsystem classification has game rules associated with it.
You know, you should learn to segregate your questions better. Having the *only* questions in your post in the *2nd* to last paragraph, beginning with the *3rd* sentence in the paragraph and ending with the *2nd* to last sentence isn''t a good way to draw attention to your questions. Either beginning or end of your post would work, as would the first or last sentence of a paragraph.

Anyway, in answer to your questions, I''d put each of the categories in their own class (with judicious use of "friend" between the category classes) The different behaviors would be either a huge switch statement or (member-)function pointers. I''d probably use member function pointers, if I could pull it off, but it''s somewhat arcane and may be too difficult for you or any other programmers you might include in your project.
---New infokeeps brain running;must gas up!
Dauntless
Dauntless
Sorry I''m a stream of consciousness kind of guy, and I really just type as fast as I think. But point well taken.

As for your idea, I was originally thinking of function pointers but they are very messy and seem sort of like a kludge. I''m trying to think of a way I can extract the basics out of "firing" at an opponent, and from there making virtual calls to each classes functions. But as I think about it, I still think there''s no way around a switch structure to test the combat conditions.

I guess I should flesh out exactly how the "To hit" part of combat works better, so that from there, I can figure out how the weapons have to fit together, and what functionality each class should have so I can delegate the function responsibility appropriately.
The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants. We know more about war than we know about peace, more about killing than we know about living. We have grasped the mystery of the atom and rejected the Sermon on the Mount." - General Omar Bradley
Kylotan
Kylotan
I''d just have a standard ''Weapon'' object, without any inheritance structure at all. That will give maximum flexibility to your system - and it''s obvious you''re looking for flexibility as a prime concern. The different delivery and aiming methods should just be part of the weapon structure (function objects or pointers in implementation terms). Switch statements will do the trick but function objects will keep the underlying algorithm cleaner. (This is a subtopic for the General Programming forum though.) It might end up looking like my basic medieval close-combat system, which at the top level looks like:

Choose attack method
Determine target
Determine chance of hitting that target
If hit successful
- Determine damage dealt based on ammunition

Each of those elements can be overridden easily enough, allowing for many permutations of attack. In your system, the 3rd step might need to be split up a little, but overall it would be similar, with interchangeable components.


[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]
sSimontis
sSimontis
The good thing is you can copy games. If someone owned ''chaingun'' and another guy owned ''plasma cannon'', the first person shooter genere would die. I like to copy games. Also, for information, test. Add what you think into the game. Then test for balance. Or create as program that does this, or use Excel.

Scott
Scott SimontisMy political blog
Dauntless
Dauntless
Kylotan-
Would it be better to still have sub-objects though? Like a kinetic round weapon should still have a receiver, a barrel, a feed system and a magazine?

I originally started out with just a class called, OffenseModule. I then thought, "what do all weapons have in common?". So I started listing attributes like damage, penetration, max range, accuracy, attenuation, etc. But then I realized that for kinetic based weapons that fired rounds....those attribues varied according to the kind of ammunition you used. So then I realized I needed at a bare minimum, two kinds of classes...an ammunition class and a weapon class (OffenseModule), where the weapon has a ammunition type.

But then I started getting into trouble thinking about how ammunition and weapons interact with one another. In my game rules, the first thing the attack function does is check for line of sight (trajectory). The result of this test is compared to the weapon type....if the target is not in LOS, then it must be capable of indirect fire, otherwise the attacker can''t fire. So then I had to think....is Trajectory an attribute of a weapon/ammunition type, or is it a fundamental object in it''s own right? As I started thinking, I think I can do Trajectory as a simple enumeration (enum Trajectory = {Direct, Indirect, Both}.

But then some other rules about combat crept in. After the LOS test is made, and the result is compared to the Trajectory, it also checks to see what kind ammunition the unit will has and will use. Normally a unit checks a table to compare target type with appropriate round at a given range....so for example, at extreme ranges against an armored target, sabot rounds will be chosen over HEAT rounds, or against unarmored targets, HE over flechette rounds. For example, let''s say a tank is firing at some infantry. Normally, the tank will want to fire some kind of fragmentation round (beehive, HE, HESH) in order to be effective. The round loaded will determine the penetration, accuracy and max range, and also the kind of damage (area effect, point of impact) and other attributes. So then a call has to be made against the weapon''s feed system to check to see if the ammuntion is available in its magazine, and then to load the ammunition into the receiver.

The feedsystem determines how fast a weapon can fire and/or switch ammunition types. The Feedsystem also queries the Magazine structure (which basically just holds the ammunition) and subtracts that ammo type from the Magazine.amount.

If I don''t do these as sub-classes, then the weapon class is going to have a buttload of functions and attributes all to itself...which as I understand from good OO programming, you should try to delgeate responsibility of handling data to the appropriate classes. The downside is that by doing this, I take away some flexibility to weapon design. But as I mentioned, the rules themselves are being kind of hard coded to reflect certain weapon types. For example, I''ve made no rules about particle accelerators (like a meson gun) which totally ignores all armor and causes radiation and superheating damage. Maybe a player would like to develop a weapon like that, but it couldn''t really be done because of the lack of rules to design such a weapon.
The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants. We know more about war than we know about peace, more about killing than we know about living. We have grasped the mystery of the atom and rejected the Sermon on the Mount." - General Omar Bradley
Dauntless
Dauntless
Village Specialton-
Well, may game will take copying to the Nth degree If you like a weapon but don''t see it as an option, then you create it yourself. In other words, I''m trying to free the player from the design choices that I make as a game designer. From the outset, my mantra is tweakability, extensibility, and moddability.

Since not all players are programmers, I also need to make this as simple as possible so that the greatest number of players can create things as easily as possible. That''s why I''m trying to come up with a scripting interface system that allows players to easily create game objects. Currently, I''m already thinking about my Unit design system in Python with a wxPython GUI interface so that it''s mostly a wizard based dialog affair. It''s why I also want the script to build a config file (probably XML or plain text) and it''s the XML file itself that gets parsed by the game engine, and the game objects are created (though I worry about potential loopholes that may cause).

But the ease of design factor is something I''m worrying about...and if it seems complicated now, hopefully the final result won''t be so confusing since the wizard will walk you through the steps initially. And not just for creating weapons, but designing Hulls, Powerplants, Mobility Systems, Sensory Systems, EW systems, and Defensive Systems amongst others. And vehicles aren''t the only thing you can design...but infantry, artillery (a vehicle without a powerplant or mobility system), and possibly even Buildings.
The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants. We know more about war than we know about peace, more about killing than we know about living. We have grasped the mystery of the atom and rejected the Sermon on the Mount." - General Omar Bradley
Doolwind
Doolwind
quote:
Original post by Dauntless
If I don''t do these as sub-classes, then the weapon class is going to have a buttload of functions and attributes all to itself...which as I understand from good OO programming, you should try to delgeate responsibility of handling data to the appropriate classes.


I just wanted to clear up what you mean here. The ammunition, feeder system etc should all be DATA MEMBERS of the Weapon class (not sub-classes of it) shouldn''t they? If something is a sub-class of something else then it should have the "is-a" relationship. EG Dog should be a subclass of animal as Dog "is-an" animal.

So if you say that ammunition and feeder-system are subclasses of weapon then they are types of weapons, is this what you mean? I believe you are thinking along the right lines, but your terminology is misleading.

Do you think ammunition should inherit from weapon or be a data member of weapon??

Doolwind
Dauntless
Dauntless
Doolwind-

Oops..my bad. I didn't mean sub-classes via inheritance, I meant component objects (via "has-a" relationship). That's what I get for being a n00b..

To help explain it better here's some more info...

I envisioned the FeedSystem and Magazine to be classes, and possibly the Receiver and Barrel. But since the Receiver and Barrel don't really have any functions, I can probably just make them data members...the data will affect other characteristics, but I would probably still have to make the Structs at least since they have several data components (a barrel for example isn't just about length, but also about weight, material and if I want to go that deep, the rifling for example).

Why do it that way? Most importantly because FeedSystems and Magazines have functions as well as data characteristics. Also the FeedSystem comes in different kinds which might be a valid use for inheritance. There might be a bit of confusion over what a FeedSystem does and a Magazine. A FeedSystem moves the ammuntion from the magazine into the firing chamber which is in the Receiver. For example:

Single Shot Manual (SSM)-
Bolt action
Pump action
Lever action
Muzzle loading

Single Shot Auto (SSA)-
Semi-auto manual (revolver)
Semi-auto blowback (pistol)

Full Auto-
Burst-
Full-

Variable-
Select-

The Magazines also have different types. The Magazine loads the next round into the FeedSystem and it also "counts" how many rounds are left. Here are some magazine types:

Box_Magazine- a clip that uses a spring to push the round into the FeedSystem's mechanism
Belt- Rounds are held in a belt through metal links, the FeedSystem strips these links as they go through the Receiver
Internal- The rounds are held in an internal magazine inside the weapon like a shotgun or a revolver
Manual- The round is manually inserted into the FeedSystem
Bin- Rounds are held in storage containers which the FeedSystem can select from (some tanks use this with autoloaders)

The best way to illustrate how it all works is with a bolt action rifle. A sniper style bolt action rifle would be classified as having a SSM FeedSystem with a Manual Magazine. When a person wants to fire, they load the bullet into the receiver (the magazine "loads" the round into the FeedSystem...in this case, the magazine happens to be a human hand) and when the user closes the bolt he is causing the FeedSystem to chamber the round (the FeedSystem.Load function is called). Depending on what kind of magazine and FeedSystem you have, it determines the rate of fire, as well as determing how quickly new ammo can be put in (a magazine is easier to load than an internal magazine). Therefore a tank with a bin autoloader can select different ammo types much more quickly to respond to threats than a dedicated gunner who manually loads the round into the gun (which is still the most common way of loading rounds into tanks).


[edited by - dauntless on April 30, 2003 3:45:04 AM]
The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants. We know more about war than we know about peace, more about killing than we know about living. We have grasped the mystery of the atom and rejected the Sermon on the Mount." - General Omar Bradley
Dauntless
Dauntless
quote:
Original post by Anonymous Poster
... An M16 with grenade launcher, when tested against a target might return [Direct, Indirect] or just [Indirect] if the rifle couldn''t hit the target but the grenade launcher could.

This would allow you (or another dev/modder) to add weapons with different trajectories, such as heat seeking missiles or X-COM blaster bombs. Individual trajectory tests could be made as classes which the Trajectory class would call, so you only make a Direct class, and the Trajectory class for the M16 calls the Direct class with the parameters for the M16 (range being the obvious parameter). This would improve code reuse a fair bit while allowing new types of trajectories to be added later.



Hmm, I think I get it. The Trajectory function could return a list of valid trajectory types, and compare this against the Trajectory modes of the weapon? So in the M203 example, the Trajectory test returns "Indirect", and this result can now be called on the weapon''s firing mode. The result can be passed in as a parameter to the weapon''s attack function, and if the weapon is Direct Fire only, it will see the "Indirect" parameter and therefore not fire? Or in this case, since an M203 has a grenade launcher capable of firing indirectly, it will be able to fire.

I do have Homing and Guided weapons, which are classified as Both for their trajectories. They have different "To hit" rules than direct fire or indirect fire weapons which take into account mostly movement modifiers and evasion techniques.

Actually, that gives me an idea. Like you said, it could be made into a class that wraps up several pieces of information...not just Trajectory mode, but range and visibility as well. These can all be passed into the weapon''s firing function. So the LOS test will essentially determine whether the unit can attack at all, and if it can already provide other data like range and visibility all wrapped up for the weapon to use.

The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants. We know more about war than we know about peace, more about killing than we know about living. We have grasped the mystery of the atom and rejected the Sermon on the Mount." - General Omar Bradley

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.