Spreadshot and Weapons Systems

After discussing the issue with my friend on the terminology, I think I’m going to abstract all the “powerups” into “systems”.  That way, I don’t have to worry about what to call a system (shield as defense, gun as weapon, etc… they’re all just generic systems that have an activate method).

As for one of the hurdles I mentioned in my last post (spreadshot requiring 3 objects, which complicates things), I noticed that there is a “physics.ignorecollision” feature.  I also remembered (via the documentation for ignorecollision) that there is a collision matrix, so I can have all the bullets on their own layer and choose so that bullets don’t collide with things on that layer (i.e. other bullets).

This saves me the hassle of having 3 separate gun objects spread apart so as not to touch bullets upon firing.  Now I can have 1 single gun object, and when spreadfire is active, just change the activate script to spawn 3 bullets, each one rotated by a specific amount (probably +/- 30) via code as opposed to rotating the prefabs on the ship.  Since I don’t have to worry about collision, they can all spawn from the same point.  Not sure I fully like that, I kinda like the idea of bullets coming from three separate guns on the ship (nose gun and two wing cannons).  But if that’s what I need to do to make it easier to program the weapons system, I might do it that way.

On the other hand, if I figure out a way to implement sub-systems (like 3 guns in one system object), it might come in handy in the future in unforeseen ways.  There may be another system I think of that might be able to utilize that, whereas if I limit myself with a specific architecture like 1 object per system, I can’t expand on that or will have to code the extra objects per system at a future time (or skip it all together).

Frankly, just to get this thing to ship and knowing it’s my first game, I don’t think I’m going to worry too much about expandability.  I don’t particularly expect this thing to make much, if any, money, and I have other ideas I want to program after this, so I don’t plan on doing a lot of program changes besides bug fixes after it’s finished.  Unless for some strange mad reason, it actually takes off.

Weapon Systems II: The Abstract (Philosophy Time!)

In my last post I said that it’s fair to ask  whether a shield should be called a weapon.

I think this really gets into the heart of what proper design is, and the question of what level of abstraction is the best.  One aspect of programming is abstracting things into lower levels of detail.  Otherwise you’re just working on same Matrix-Level Simulation shit.  So, here, the question is “how detailed do I get when it comes to making these things?”  Part of abstraction is categorization, grouping things together into certain sets that make sense for them to share.  In that sense, the concept of “weapon” is abstracted to a higher level than just something that goes PEW and does damage to an external object.  The question then becomes: Is “weapon” even a proper name?  Is there some other term I can use to convey that abstraction (and in the process, allow for more open ended interpretation of those capabilities of things I currently call “weapons” and perhaps something else will come along and cause me to rethink them not as weapons but as some other type of object.

And interestingly this gets into some computer science type stuff, because what you then start to deal with here is the very idea of categorization and typing systems.  Whenever you make something in a class, you are making a category.  Whenever you place something into that class, you are having it partake of that which defines that class.  This is basically what a “type” is in computer lingo.  You have a defined set of rules specifying something, and all entities that can return “true” upon comparison to those rules indicate that it is a member of that set, and thus, of that given type of object.

What I *call* an object is irrelevant, I could call the “weapon system” a “potato system”.   That’s all syntactic…  It doesn’t really fucking matter to the computer what I call it.  It matters to me, but in the end, that’s just because of the function of the human mind to map words to exterior entities outside of itself and into its realm of experience, and it makes it easier (and thus more efficient) to map the words onto constructs I already know.  In fact, the ABSTRACTIONS of the objects I am trying to represent.  There is a level of congruency between the physical world that one is attempting to model in such cases, and the language we use to understand that world.

To finish up the point, we have a syntactic interface to a mental model which is a link or a map to an external entity.  We abstract things so as to not have to deal with irrelevant information that does nothing but complicate the essence of what we are trying to convey.  What we are trying to convey then, is a semantic, meaningful representation between these things, such that together they form a unified whole.  Ideally, it will present itself elegantly to the user such that they themselves can form a similar mental model as the one that the programmer is creating.

That is to say, the programmer is speaking a language, transcribing thought into specific language/code that the computer can understand and interpret.  This interpretation is then “run” and the end user has access to the output of the programmer.  The more accurately and expressive the programmer (and designer, programming by itself alone is only part of the equation – the language of design is yet another layer to this story) is able to convey what they are attempting to do, the more refined the process of the user to “intuit” what is happening, the more easy a system becomes to use.

But because everything is abstracted to some degree, there will always be a missing element to these interfaces.  It means that we can never create a truly “intuitive” interface, because one is always removing dimensionality from the mental model one places on the world.

Weapon Systems I: The Concrete

So, I’ve been thinking about how to approach my weapons system.

Right now, I have multiple weapon objects, each with their own “fire” method.  This method checks if a fire button has been pushed, then it checks the currently active weapon on the ship, then proceeds to shoot the weapon.

I believe when I first started to work on this, I had an idea for an approach and I didn’t use it.  My mind still thinks that approach is the right way, so I started to think about it, and I am running into an issue (and it might be that this is the issue that had me stop previously).

Basically, I’m going to have a “shoot” function on the ship.

The ship will have an array of array of weapons objects.

The first array is the weapon-type and associated trigger “button”.

The second is the “subtype” (as indicated by the names after the dash)

0. LeftMouseButton –  Gun/Cannon, Laser

1. RightMouseButton – Missile, Nuke

2. MiddleMouseButton – Shield, Vortex, AntiMatter Field)

 

So, to do something to fire a gun, I would do something like: ship[mouse_button_clicked][current_weapon_loaded_of_subtype].shoot()

(NOTE: This is pseudocode, with many warts, but meant to convey the concept)

This says, grab the mousebutton clicked, return it’s value, which then indicates which of the first arrays it is, then go into the second array and grab the weapon that is currently assigned for that slot and activate its “fire()” method.

This is all fine and dandy as long as one has each slot occupied by a lonely game object.

The problem arises when I have something like “spreadshot”, which is currently written as 3 gun objects.  The left and right objects are rotated to give an angle of spread, while the center gun object faces forward with the ship.  How do I assign all 3 to one “slot”.

On thinking about this, I’m pondering creating a generic container named “weapon” and it will contain a list of weapons that it contains.  Most weapons, then, will only have one item in it.  But for spreadshot (and if there is some other specialized weapon that has more than one “barrel”/weapon) it would probably be the best way to do this.  In such a case, I think I would merely activate and select the appropriate selected objects.  That is to say, I would not be required to create a single-shot weapon object, and then a spread-shot weapon object.  Instead, a single weapon container object will suffice, and then I activate or deactivate the subcomponents as needed.

I don’t particularly like making this deep of a hierarchy for something that should be fairly simple.

ship->weaponsystem->weaponcontainer->activeweapons->FIRE!

On the other hand, the goal right now is to architect something and do it properly.

—————–

The second issue with the weapon system is that I am going to properly use inheritance and private/protected variables this time.  To quickly do the prototype I made almost every variable in my classes public and that’s just bad design.

But more to the point, my general idea is to create a base weapon class.

This will have things like: active-state, fire-rate,  ammo-supply.

These traits will have methods to modify them.  Methods like: level-up, fire.

This base class can then have default values, and then the ability to be overridden by child classes, so a “laser” object will have a “fire” method and a “level-up” method, but it will be different from the “gun” object.

That part is relatively easy, it’s just a matter of doing it and doing it right, and that’s the reason I’m thinking through these processes now so I properly architect it this time (or rather MORE properly architected.  I’m still learning, so to say it is proper is a misnomer, it is merely one step on a path to getting better with my coding).

But in the end, that issue of multiple weapons is going to take some thought and play.  I have a feeling the array of arrays of weapon-containers which are defined merely as lists-of-weapons which can then be accessed via this hierarchy is the way to go, or close to it, but we’ll have to get some feedback.

The other issue is that I don’t like calling a “shield” a “weapon” but in terms of interacting with it, it pretty much is.  I click a button, an effect happens.  A defensive effect, as opposed to an offensive effect, but an effect nonetheless.