Ideas/Thoughts on Trail Tiles

Terminology

• Mind-Game - involves predicting what the opponent will be doing (in the future), and tricking the opponent (into believing and doing something that would be advantageous for you).
• Depth/Complexity - refers to the number of distinct, relevant possibilities/choices/situations that exists in the game.

---------------------------------------------------------------------------------------------------------------

Focusing on "Simplicity" (of design and work), there's a few ideas I want to bring up, that we may want to prototype (if we like it).

1) Steal Highlighted Tiles -

- Explanation: What if characters can steal highlighted tiles through weapons or through walking. That is, highlighted tiles owned by someone else can be converted to yours. Of course, stealing highlighted tiles would be useless if it didn't give any benefits, so suppose it does. Then this concept should cause the opponent to think about how their highlighted tiles can be used against them, or the reverse case (i.e., how can they use other opponents tiles). Also, they'd have to think about whether it would be wise to create highlighted tiles in certain situations. Etc.

- Questions to Think About:

• Upon ownership change, how is tile expiration time preserved/changed (based on varying situations, factors, weapon/armor types, etc.)?
• How many and what are the "valid" tactics that would be introduced?

2) Highlighted Tiles Increases Speed -

- Explanation: This is just 1 possible benefit of highlighted tiles, where the character's speed increases by running on a highlighted tile. I think this can add a bit to the mind-game element, where there's a clear benefit of a speed boost by being on the highlighted tile, but the highlighted tiles only exists at limited locations, which would make it easier for the opponent to shoot the target if the target only moves on the highlighted tiles.

- Questions to Think About:

• How many and what are the "valid" tactics that would be introduced?
• What if the type of benefit for being on the highlighted tile depends on some factors (e.g. armor type, traits, combat situation, environment, etc.)?
  
• Other Benefits or Restrictions imposed by being on the highlighted tiles?
  
• Alternative/Better Solutions (than what I discussed that would add more depth/complexity to the game or include other game elements that we want)?
• Other design ideas/concepts that would enhance this concept?
  
• Other ideas to add to the mind-game element? (Note that the existence of multiple "valid" tactical choices is an important ingredient for creating mind-games. Now, for example, consider how temporal and spatial aspects may come into play; what if moving towards a projectile allows the character to negate the push-back effect if the character has enough stats to withstand the impact, but moving backwards reduces the damage? How about moving left or right? To come up with these questions/considerations, realize that I focus on exploring the available freedom of control or choices first before injecting in rules/logic to support their "validity".)

Edit: just so I don't forget. I also want to talk about the "Hook/Cool Factor" (see the google site). I'm thinking some sort of EX/super move that uses up the highlighted tiles; maybe the move allows the character to counter the opponent somehow...

Linking up firing animation to actual weapon firing

I've set up an AnimTree for the robot here:
AnimTree'GI_Robot.Anims.AT_CH_Robot'

For "Lethal Injection," we used an AnimNodeBlendList to link up the attack animations in the AnimTree, and then triggered the children of the AnimNodeBlendList in UnrealScript. I want to try something a little different this time.

This time I have two nodes of the type AnimNodeBlendByProperty. Each of these supposedly chooses a branch of the AnimTree based on a boolean property in the UnrealScript.

http://udn.epicgames.com/Three/AnimationNodes.html#AnimNodeBlendByProperty

Currently, I've set the AnimNodeBlendByProperty nodes check for the following booleans (which don't yet exist in the UnrealScript, I think)
1. bFiring
2. bEndingFire


bFiring is set to activate the branch of the AnimTree that holds all the firing animations when TRUE. When FALSE, it uses the branch with non-firing idle and run animations.

bEndingFire is set to activate the animation in which the robot lowers his arm after he's finished firing when TRUE. When FALSE, it uses the branch in which the robot raises its arm to get ready to fire.

Rather than use Gina's firing recoil animations, I chose to use a Skeletal Controller named GunRecoilNode linked up to the r_arm bone. I did this because somewhere within the UnrealScript, UDK already looks for and triggers GunRecoilNode whenever a character fires a weapon, and it already works well with the default Linkgun's rapidfire and sustained fire modes.

So how I think the firing animation calls would be programmed is something like this:

1. When the player presses the attack button, a boolean named bFiring is set to TRUE, which should tell the AnimTree to use the firing branch.
1a. After some delay to let the AnimTree blend from the normal to the arm extending pose, actually fire the weapon, with the GunRecoilNode triggered upon firing (which already happens).
1b. While the attack button is held down, the character sustains the arm extended pose (which is the last frame of the extending animation). The weapon will keep firing at its fire rate, triggering GunRecoilNode with each shot.
1c. If the weapon runs out of ammo while the attack button is held down, then the character switches back to the default weapon automatically and continues firing without lowering the arm.
2. When the player releases the attack button, the weapon stops firing, and a boolean named bEndingFire is set to TRUE to select the arm-lowering branch of the AnimTree
2a. After some delay to let the AnimTree finish the arm-lowering animation, set bFiring and bEndingFire to FALSE, which should set the AnimTree back to the non-firing branch.

If you think names other than bFiring and bEndingFire would be more useful, you can easily change what property the AnimNodeBlendByProperty checks for by opening AnimTree'GI_Robot.Anims.AT_CH_Robot' and selecting the nodes.

Trail Screenshot

I just did a quick (improper) implementation to show what the trail would look like. (I'm not committing the changes, since the implementation is improper).

The currently implementation of the "highlight" is a bit jarring, but there's probably things we can do to make it look better.

I'll do a proper implementation some other time.

Edit: Changed the image, after I've used a new trail material.

art reference

few more art reference

Meeting Summary

Not really a complete summary, since I will just focus mostly on the combat/game-play topics which we mostly talked about. A lot of the discussion was between Thomas and I. The topics are listed below.

- Main Combat Game-play -

Purpose - the main purpose of the below described mechanics is to add complexity/depth to the combat system.

Note - weapons don't just deal damage, they may cause status effects as well. (e.g., slow-down or modified paint color).

• Tile Ownership - which tiles you own (or don't own) may result in different triggered weapon effect types or alternatively, the power of the weapon. (e.g., the number of owned connected tiles that you're standing on, may influence the fired weapon result.)
  
• Tracing Tiles Walked On - I thought it would be visually interesting to see the tiles that the character walks on be tracked (by highlighting the edges of the tiles). More specifically, we're thinking that the tiles that the character has walked on for a certain previous time duration should be tracked. Again this can influence the fired weapon result. I'm still pondering if it should be possible for an opponent character to cut off the trail.
  

• Mind-Game - For the game-play experience, we're thinking there should be some sort of mind-game. That is, some game mechanic that allows players to predict, guess and try to figure out what the opponent is doing and/or trick the opponent into believing the player is doing something they're not. (e.g., Street Fighter 3 has the parry system; even the regular fight mechanics has this mind-game element, since the speed of some attacks/throws are too quick to react to, so reading the opponent's patterns/habits become important.). For this aspect, we don't have any clear detail yet.
  

- Hitpoint Recovery - some form of hitpoint recovery is probably necessary, because we don't want the case where one player is left with little health left until time starts to run out, at which time the other player shoots him to erase all of his painted tiles. A couple of possible solutions are listed below:

1. auto-regenerate - the hp auto-regenerates. We're leaning towards this solution, since it reduces the necessity to remember a player-character's hp, which means we may not need a constantly displayed health bar on the screen.
   
2. items/weapons for regeneration - there's items or weapons that can aid the player in recovering hp.
   

- NPC Robots - we talked about NPC robots possibly being modified, upon being shot, to paint the tiles in the color of the shooter. (My personal thoughts: I think the rules/logic behind the NPCs should add some unique/distinct flavor to the level/map. But I have no clear detail in mind for this yet.)

enemy bot redo

enemy bot redo

So here's another version based of gina's comment

item bot sketchy

ehh mind as well can get started on modeling. texturing i will do later