Weapon Modding System

As an alternative to the weapon crafting system, another possibility is that all the picked up items are modifications to a base weapon. The player can pick up up to 3 modifications that grant different stacking properties to the base attack. The player may pick up 3 different modifications to give 3 different properties to the attack, or multiples of the same modification for an amplified effect.

Mods will add properties such as:
-rate of fire
-explosion radius
-multiple parallel projectiles
-damage over time (multiple mods extend duration)(damage stacks from multiple hits)
-projectile speed
-slow target (multiple mods raise the magnitude of slow)(slow refreshes on consecutive hits, but magnitude does not stack)
-knock back
-homing (multiple mods improve homing ability)
-priority over enemy projectiles

The player picks up a mod by standing on it and pressing a button. Once picked up, the mod's icon is added to the end of the player's list of mods (shown on the HUD). If the mod list is full when the player picks up a new mod (all 3 slots are filled) then the 1st mod on the list is dropped on the ground, the remaining mods are moved up on the list, and the new mod is added to the last (3rd) slot. The dropped mod is placed in the exact same location as the mod that was just picked up. The player can remain standing on the spot and tapping the pick up button until the undesired mod is the one left on the ground.

Mods spawn periodically on the map and can also be dropped there by players who swap mods. Any mod on the map will remain there for a duration, but will disappear if not picked up for a time. When a player drops a mod, the mod exists for a duration similar to as if it had just been spawned on the map. Mods will not spawn on the map in the same location where another mod currently exists (to prevent confusion about what the player can pick up).

Upon death, the player's mods are all destroyed. Players do not drop any mods on the map when they die.

This modification system allows players the freedom to customize their own weapon (as best they can, given what mods are available on the map). Rather than collect abstract crafting resources that are spent to create weapons, players can see how each mod type directly alters their weapon. This becomes similar to Bomberman's power up system, but with a maximum number of power ups that can be held at one time to prevent any one player from becoming too dominant. While the player is unable to amass a large collection of resources, the mods they collect are more meaningful and obviously functional. Since the mods a player wants may not always appear when desired, and because the player loses the mods upon death, players will often be looking for all the mods to create the final weapon they want (or whatever the next most preferred mods are, given what's available).

Weapon Systems Analysis

1) Current System of Weapon Pick-ups

Pros

• Easy and fast to implement

Cons

• More limiting on player choice. That is, player does not have immediacy of choice for the weapon they want to use, since they have to pick it up first. A semi-solution to alleviate this issue is to have 2+ weapon slots for special weapon pick-ups, but it doesn't completely solve the issue and introduces an additional switch weapon button which can be awkward since the mouse only has 2 buttons (assuming the left-button is reserved for the basic weapon).
• Special rules for dealing with picking up weapons is awkward. (E.g., not being able to pick up a weapon when slots are full)
• The appeal of "collecting" is not well realized here (due to the limitations of weapon slots)

The remaining ideas do a better job of giving immediacy of choice to the player.


2) Crafting Items (e.g., craft weapons, and craft amplifiers/power-ups such as temporary shields that protects from some weapon types.) Note, I'm thinking there should only be ~3 variety/types of crafting materials.

Pros

• Better captures the appeal of "collecting" (since there's no limit on collecting materials)

Cons

• More work than other alternatives

Concerns (and Potential Cons)

• Design of UIs/Menus for displaying materials and items that can be crafted
• Input method for crafting items (e.g., correspond a button with each material, Morse Code w/ 1 button, etc.)
  

3) Same as the Crafting Items idea above, but with only 1 material/currency

Pros

• All of the above
• Is simpler on design and creation of UIs/Menus
  

Cons

• All of the above
• reduces freedom to balance weapons (and therefore possibly puts some relative constraints on weapon design)
  

Pro/Con

• Reduces game-play complexity

Concerns (and Potential Cons)

• Input method for crafting items
  

4) Glyphs appear on tiles. Glyphs replace crafting materials. (Thomas will have to correct or fill in any remaining details).

Pros

• Simpler to implement than the other 2 crafting ideas, since additional UIs/Menus may not be necessary (except maybe for weapon "blueprints"?)

Cons

• Not as appealing as having something more tangible to collect

Concerns (and Potential Cons)

• Input method for crafting items

Questions to Consider:
- Any different ideas?
- Any solutions to the above listed Cons?
- Any modifications to existing ideas?
- Which idea is most appealing? Why?

Edit:

5) Mechanical states/switches

- Description
- Assume ~3 resources and activating the use of a resource may apply some power-up or bonus effect or state change on the robot, in which case it should probably drain the resource over time.
- resources will be represented by bars (or gauges) and markings will exists to indicate whether a minimum threshold has been reached to fire a particular weapon. Different colored/shaded markings (or symbols) will be used for different weapons. (Alternatives: have these toggled states be separate from weapons. This means the game will be more complex and use more buttons though.)
- Only 1 weapon will be selected at any one time. The highest tier weapon will probably be selected based on activated resources/state; if the minimum required resource is not met, then no weapon is selected (in order to keep consistency, each state is associated to only one weapon regardless of the current # of resources).

- Pros
- Can do many things and it'll still make sense
- Put soft limit on max resource by forcing automatic activation or put hard limit on max resource by having a max amount that can be gained, so that saving up and spamming doesn't occur. (Note, for the crafting idea, we can put some cool-down to disallow spamming or require time to craft, etc.)
- Allow player to dynamically change which weapon will fire (in contrast, with the crafting system, we can allow dynamic weapon changing if we have some sort of cool-down after each shot so that spamming doesn't occur, but it would require additional buttons, since we'd need buttons for crafting + switching weapons)
- Gives immediate sense of doing something with each button press
- Toggle switches work well with the keyboard & mouse layout, because the #keys aren't exactly close enough (to WASD) that it's comfortable to be pressing in quick succession (which I would assume would occur often with the crafting system if keys were used instead of the mouse button, assuming no cool-down system)

- Cons
- For simplicity, weapons will probably have static resource cost
- Hopefully, it can be implemented in a way that's not tedious, since I'd imagine players will be toggling states relatively often.
- gauges take up HUD space
- Can be hard for players to determine which weapon is selected (based on toggled state) (unless the rules were simpler. For example, if there's an ordering of material/resource values, say M1 > M2 > M3, then any weapon that uses M1 will have higher priority for selection; but this forces an ordering which will create higher valuation for M1).

- Pros/Cons
- Player will be expected to look offscreen to track the gauges, but it would be expected (by the player) as part of the experience since it fits well with the theme of the maintenance of robots. (Remark: Switch activation effects can be shown with particle effects or auras or trail tiles.)
- Game is more complex, but can also be more engaging

Visual Tests

These are images of some changes I've made. I have not committed any of these changes. Each image represent different changes (e.g., lighting, distribution of brightness). A couple of images uses only 4 distribution of tile brightness factors, while a couple of other images uses a completely randomized brightness factor between 0.0 and 1.0. Note, the name of the images (or its url) gives a hint on what the changes are.

Notice that "trail" tiles are not in any of the images (except maybe 1). Also, the images were taken when the materials were at their most "bright".

Some changes I've made:
- changed emission visual script for the tile material (for the uncolored state and colored state). The uncolored state is now much dimmer, where I first turned off all of the lights to determine a value for its emission component (so that it doesn't appear too bright). Note, I made a copy of the material (i.e., Thomas's material) before changing it to the current one.
- turned off the 2 previous lights. Created a dominant directional light.


I have not committed any of these changes, because the unrealscript side was done for illustrative purposes only; it's very, very inefficient since a new material is constructed whenever the tile color changes.


Edit: Added a new pic to the top. Note, it can be improved, but right now I'm just offering an alternative.

Intro and Menu animation

http://toshnak.com/giflash/start_menu_1.html

Here's an update of what I have so far.
I may need one of the artists to redraw the gate in the beginning of the animation since it is pretty low res.

I think once you click on start, there should be another "lobby" type of screen before you start the game.

Under the "options" menu it should be things like FX volume, BG volume, display quality, etc. The technical stuff.

On Weapon Design

Note - Didn't mention this at the meeting, since I didn't think of it then. However I did mention a similar approach months ago.

Approach:
The approach is simple. Just define all of the important/relevant properties and considerations (Note - this should be a list that is built up overtime. And ask others for points/things that you may have missed). Then use them when designing something specific, so that you can hit all of the points you've listed.

Example for Weapon Design (for our game):
(Note - if I'm missing something, then consider mentioning it by commenting)

(Weapon/Projectile) Properties:
(Note - remember to consider what I'm calling as meta-properties, such as the static/dynamic nature of each of the following properties.)

• Entity Damage (i.e., damage to an entity/robot)
• Status Effect (e.g., stun)
  
• Projectile Damage (i.e., damage applied to colliding projectiles)
• Size/Volume
• Speed
• Health
• Multitude (i.e., # of projectiles)
• Life Duration
• Flight Path
  
• Other Special Conditional Effects (e.g., splitting up an opposing projectile into multiple projectiles, where the # depends on the size of the opposing projectile)
• Momentum imparted upon killing a robot
  

Considerations:

• What role/stereotype does the weapon make the person feel that he's playing? (e.g., the turtle, tricker, damage dealer, phantom, etc.) (Note - a list of possible roles/stereotypes should probably be written out and kept tracked of)
  
• What does the weapon feel like? What will generally be people's perception of the weapon itself? (e.g., a weapon may feel powerful due to the explosive impact, or unwieldy, slow, floaty, etc.)
• Is the design relatively unique (compared to other games)?
• Is it deeply designed? What are the possible pros/cons of using this weapon in each possible scenario/situation/condition?

Specific Example Weapon:

Consider a phantom bullet that phases in and out on certain time intervals. (Note - during the initial conception, it's not always necessary to define specific values for each "property". And the design approach listed above is intended more for thinking rather than writing out everything with each item designed, because it would be too tedious otherwise; but it's important to mention at least a couple of considerations and to mention the non-obvious considerations.).

• I can't think of the vocabularies to exactly describe what role/stereotype the player will feel like they're in when using this weapon, but it's certainly considered (and I hope it's obvious, given the "phantom" name).
  
• The projectile will give off an aura of phantasm/ghostliness to emphasize the type of role/stereotype that the player should sense.
• An example case when this would be useful is that it can bypass a single dominating projectile.
• A case when this would not be so useful is going against a head-on beam (or rapid series of head-on projectiles) that can dominate it.
  

Ideas Discussed Last Meeting

1. Player gain a movement speed boost when walking onto enemy glow trail or onto the player's own tiles. This allows a player increased mobility when directly chasing down an enemy as well as when fighting from an area mostly under that player's control.

2. Environment has energy/elemental fields that modify the properties and characters and projectiles that pass into them. Possible changed properties include size and velocity.

3. Player picks up materials to craft weapons and expends all carried materials to craft an item by pressing the craft button. The type of weapon crafted depends on the proportion of material types in the player's inventory at the time of crafting. The quality of the weapon depends on the quantity of materials carried.

4. Player has reserve weapon slot. Player can press button to swap active weapon with reserve weapon. Moving over a weapon on the map will swap the reserve weapon with the weapon on the ground.

5. Player picks up materials to craft weapons and chooses which materials to use by inputting a button sequence, with a button assigned to each material type. The order and number of materials used in the sequence determines the crafted weapon. Each match, the sequence that qualifies to craft a each weapon is randomized, so players have to experiment with each new match to figure out what sequences will create each weapon. Forcing players to relearn with each match allows new players a fair chance against players who play the game a lot.

6. Create single player campaign levels selectable from a menu or a world map. Each level is a challenge in which the player much accomplish some objective in the arena. The objective may be collection, survival, defense, killing, or others. Each challenge is a re-enactment of some historical conflict in the game world's history and is named for a historical figure connected to the conflict. Performance on each level is scored, and sufficient total score from all levels combined will unlock subsequent sets of challenge levels.

Some Thoughts

Weapon Spawns
People seem to like being able to choose the weapon to pick up on the field, but I think it's awkward if characters automatically pick up weapons under certain conditions and walk through weapons when they already have another equipped. Here's a couple of solutions I considered where each introduces some Pros and Cons of their own. (Note - I'm intentionally leaving some details unspecified, since there are several possible options for them and these details are irrelevant to the main idea):

1. Objects on the field are basically crafting materials. Players need the necessary ingredients to craft the weapons. There should be some method to clearly show what items the player can craft; one example method is showing the recipe on screen. (Note - if recipes are shown, then it's possible to procedurally generate recipes or decide which weapons can be produced during the match, which can give a bit of randomness/uniqueness to each match as the players' tactics/strategy may need to change.)
   
2. Weapons belong to equivalence classes such that they disappear once one (within the same class) is taken. (Note - a class corresponds with a team/player color)

What if the player also has to consider if it's better to stay within his colored tiles?

What if the player is more vulnerable when playing aggressively (i.e., taking over tiles)? The player is challenged to consider and decide when it's better to be defensive or offensive. For example, characters standing on enemy or glowing tiles take 1.0x damage, whereas characters standing on their own non-glowing tiles only take .5x damage. (Note - The logic/rules for the glowing tiles would be tweaked/modified to support this concept).

Other Ideas that was considered in unison with the above ideas:

• Suppose what if under normal circumstances fired projectiles don't take over tiles. Instead, players must activate their "supers" for this to happen. This adds additional choices/decisions for the player to make and can add a psychological element to a battle as the player must predict the opponent's next move in order to best utilize the effect of taking over of tiles.
  
• Suppose that Hp and Energy are one and the same. What if firing shots (including the use of "supers") or taking damage both cost energy/hp? ( this can be compared to gambling in a way as the player is paying a cost for potential benefits).

Some concerns which arises from the above ideas:

• HUD/Screen space
• buttons for player input