Worst-case scenario: the UEd Goblin wipes the map and burns down your house.

Legacy:Solid Snake/Contrast Development Weaponry

From Unreal Wiki, The Unreal Engine Documentation Site
Jump to: navigation, search


Unreal Engine's weapons system changed between different versions of the engines quite a lot during their developments. I'm not sure if this had to do with different programmers programming the system, or if they decided that a particular style was better or worse. Whatever the reason, people who develop for the Unreal Engine have had to keep up.

Unreal Engine 1[edit]

Unreal Engine 1 used the approach that a single class was the best way of handling weapons. This meant the weapons' rendering, firing and other mechanics are all handled by this single class. For example, you would have different functions or function parameters to handle different firing modes. The pros of this method is that weapons are handled by a single class rather than various classes, which means that there isn't any overheads on object management. If your lucky enough to have several programmers on your team then you (if your the lead programmer) can tell people to just read this single class, and not have to explain much about object linking and integration. The cons of this style is that it can get very confusing how to handle different firing modes, copy and paste code is very likely to happen and you will have overheads in simply getting variables for various functions. What I mean by that is if you had a weapon with two firing modes, you would need two variables to store everything detailing about that weapon firing mode (such as firing intervals, damage amounts, etc etc).

Unreal Engine 2[edit]

Unreal Engine 2 used a heavy object orientated approach for handling weapon. Thus weapons had weapon fire objects. This means that the weapons only handled rendering and other various bits, and weapon fires handled how the weapon fired. The pros of this method is that it is a very clean approach (code wise that is), and you wind up with a lot less variable soup (since weapon fires have their own variables that are seperate from others), you can switch weapon firing modes easily and its easier to manage since your looking at a lot less lines of code per file. The cons of this style is that you now use several classes for a single weapon (three classes if you had a single weapon with two fire modes) and the linking and itegration of them is difficult, there will be overheads in managing the objects, and communicating how weapons work will be a lot more complex as other programmers will have to dig through quite a lot of extra classes.

Unreal Engine 3[edit]

Unreal Engine 3 (RoboBlitz's build) seems to have gone backwards back to a single class handles everything style. The main reason why I think this was decided was because Unreal Engine 3 was heavily marketed as everybody's engine. Thus easy to understand weapon management was crucial, and definately having a single class to handle weapons was the best way to go. Luckily with dynamic arrays and so forth, it made variables easier to handle, but in saying that replication would be a bit of a mess too, depending on how dynamic weapons were (adding and removing weapon modes etc).


Contrast needed to have a weapon system that would allow players not only to add/remove weapon modes quickly and easily, but to be able to switch between weapon modes very quickly. Using Unreal Engine 1 & 3's method wouldn't be possible in this case, as I would have needed to copy entire sections of properties all the time to the variable arrays. It would also be very messy to remove weapon modes, thus an object orientated method was much better. I pretty much rewrote a system very much like Unreal Engine 2's weapon system within Unreal Engine 3 (took me two nights to write the weapon, weaponfire, instantfire and projectilefire). This method would also allow me to write other weapon modes quickly, such as a beamfire (Much like the Link Gun alternative) and possibly other funky weapon modes.