Times, trials, and turbulence.
Items and munitions.
This entry is somewhat a large update (and explanation) from the Ye Olde Poste I made about Skirmish’s Object Model way way back when. It’s always interesting to look at “here’s how I think I’m going to code it” and “this is how I really ended up coding it”.
The original idea was to have a single base class, Object, which represented a single generic entity within the game world, and have classes like Player, Prop, and Item derive from it. What ended up happening was that Prop essentially became the base class — a Prop being an object in the world that follows the laws of physics within the game — that Item derives from. The idea is that everything in the world that performs physics but has no real purpose (chairs, empty bullet casings, splinters of wood from a broken box, etc) are just regular Props, but those props that were capable of existing both in the ‘game world’ and in the player’s inventory become the derived class Item. These have the logic of Props when they are on the ground or being thrown by a Player, but have an additional set of logic for entering/exiting the Player’s inventory, and for being used/fired/activated/etc as well.
Items are essentially weapons, depending on how you look at. Items have a Use, which can be defined as anything: create a networked bullet, heal nearby allies, launch a rocket, and so forth. It’s simple and flexible enough that I can generalize a lot of the network messages that will have to be implemented, and makes adding logic for new/different Items a really easy task.
Additionally, Items can each have one of three Ammo Models to follow for their usage. By default, all Items have values like ClipSize, FireDelay, ReloadTime, etcetera, and so all Items technically consume ammunition in some manner. An Item can follow one of three models, which all ties into how I’m handling things like reloading and ammo behind-the-scenes: Ammo Consumption, Object Consumption, and Infinite.
- The idea is that the first type will look for a certain ammo type in the Player’s inventory, say, “Standard Shotgun Ammo” as an Ammo object (derived from Item as well). Ammo objects hold an arbitrary amount of ammunition within them, and so they act as a sort of single container object for all of the Player’s ammunition of that type. Thus a Player with a rifle and shotgun would have one item holding all of his rifle ammo, and another for his shotgun ammo. These objects would be destroyed once the ammunition ran out, or merge two ammo objects together if another of the same type were added to the inventory.
- The second type allows the Item to instead consume another object in the inventory as ammunition. This is particularly neat, since it allows for some clever recursive ammo/gun relationships. One such example are grenades, which really would not make since under the above model. I mean, a grenade isn’t a weapon that you feed ammunition to; each grenade itself is a weapon. So, by setting a Frag Grenade’s ammunition to “Frag Grenade”, the weapon will consume itself as ammunition, thus destroying it from the player’s inventory. The inventory will seem to clean itself out as the player uses grenades/mines/etc without leaving over an annoying “Grenade with zero ammo” object. It also allows for weapons that use Props as ammo, like somesort of “Rock Launcher” that uses rocks you pick up from the ground. 😉
- The last type, Infinite, is pretty straight-forward. This is just a special type to accommodate for melee weapons, which have an infinite number of uses. This also applies to several special infinite-use weapons that some of the player classes have.
Above shows a disposable rocket-launcher item, which consumes itself as ammunition.
The HUD, The Map Editor, and Milestone 3
I don’t really talk about the game versions much, but I keep track pretty vigilantly in my internal documents. Milestone 2 is now completed, which has introduced the basics of the GUI system, saw Prop physics system implemented, the Object Model put into place, Player animations, firing basic weapons, and full map/object collisions.
The next Milestone, number 3, will be about fleshing out the HUD the rest of the way (lots to come!), and finally hunkering down and writing the map editor for the game. After that, well, maybe we’ll even start on the networking programming some day. 😉