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).
Thursday, January 26, 2012
Tuesday, January 3, 2012
Weapon Systems Analysis
1) Current System of Weapon Pick-ups
Pros
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
3) Same as the Crafting Items idea above, but with only 1 material/currency
Pros
Cons
4) Glyphs appear on tiles. Glyphs replace crafting materials. (Thomas will have to correct or fill in any remaining details).
Pros
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
Pros
- Easy and fast to implement
- 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)
- 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)
- Reduces game-play complexity
- 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"?)
- 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
Sunday, January 1, 2012
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.
Subscribe to:
Posts (Atom)