CS297-298 Project News Feed

Had my defense today and it went well.  I am now basically done.  The 
only thing left is to submit the copies for binding, which I will be 
doing on Friday after the convocation.

Added some animations for Si Si, but I decided not to use them at the end 
because they end up causing trouble in the gameplay.  So I just scaled 
her to match Perry's size and used his animations for her.  

Fixed an animation problem I was having.  Basically I was timing when 
to an animation was over, but I needed to put a small safety buffer 
in there.  Due to some imprecision, the animation was going over the end 
and looping back sometimes, flashing the first frame really quick before 
it noticed it was over.

- Finished slides
- Added character select screen
- Put in rest of music and sounds
- Made 4 stages, which are selected randomly.
- Fixed crash bug that happened into going from game over back to 
title.  Problem was the queued graphics calls were not flushed 
beforehand.  So by the time they got to being drawn, they were 
already destroyed.

Got about half of defense slides.
- Added more sounds.
- Made it so creation of D3D device falls back on S/W if H/W fails.  In 
s/w it's really really slow, so probably not really worth running it 
anyway, but it's there.

I got word today that my thesis report has passed the plagiarism 
test, so I can now schedule a date for my defense.  The tentative date 
is Tuesday May 24 after my CS255 final.

Man... I blogged yesterday but there was an error and now I lost 
it all.  It was a long one too.  Anyway, basically, work has been 
very busy and I haven't gotten too much further on AF.  I did figure 
out why my fighter wasn't falling all the way down to the floor 
though.  For some reason, exporting using matrix keys from MilkShape 
seems to eliminate the translation.  So now my fighters can fall and get
 up.  I also made a few of PJ's animations better, tweaked the 
health levels to a reasonable amount, and have a somewhat working
 game over back to title screen thing.

Aside from a couple of bugs I have noticed, AF can be said to be done. 
 The one last major thing I will try to do is to add that second 
character.  Animation is just a tedious process for me and takes a 
lot of my time.  One thing I will not do anymore is to save AI 
statistics across fights.  I thought about this, and it won't 
gain me much.  The reason being that the AI already adapts very 
quickly.  So within several moves at the beginning of the fight the 
stuff learned from the last round won't really matter anymore. 

I almost forgot to submit my report to the CS department.  Good thing 
Dr. Pollett reminded me last week.  I sent it, and just got word from 
Dr. Hayes today that he has received it.  I can't schedule a 
date for my defense until I received word that I have passed 
the plaigarism test. 

Noticeably, I haven't  blogged for awhile.  I was actually in a bad 
situation because my laptop started to fail a couple weeks ago (staying
 on for only a short while at a time) and then totally died last 
week.  I am pretty sure it's some sort of heating issue, but instead 
of waiting around to have it fixed, I decided to get a new deaktop.  
Actually I was going to get one anyway, I just pushed up the date. 
 So I started working on AF again today.  I have another problem 
though, which is that I found out my academic version of VS7 will 
only activate once.  Since that already happened for my laptop, I 
can only run it 5 times total before I must activate it.  My 
plan: (1)leave it on for now and (2) try to get another copy either 
from Pollett or Beeson through e-academy, or the CS club.  I'll 
have to put in a lot of work tomorrow to make up for lost time, 
but for now I have to sleep if I hope to wake up for work.

Oh there is also good news though.  I found out last week my thesis has
 been approved by GS&R, although I will need to make some corrections. 
 They said they will contact me so I can pick up the copy some time 
this week.

I integrated my particle systems module from Spin Cycle into Alpha 
Fighter. I have a system called PSHit, which is basically a very 
small explosion type of effect. The particles spread from a point in 
all directions and decelerate. These systems are created whenever 
a fighter hits the other. If the hit was successful, red particles 
are used, otherwise blue particles are used.

I found out the weird interpolation problem I was having with the 
roundhouse kick animations was actually because I did the 
animation in some weird way. It was misleading because it still looked 
fine in MilkShape. Anyway, I fixed that. So the high roundhouse 
(medium strong) animation is new and probably finalized.

I will continue to tediously revise and add animations. The next coding
 thing to do is probably to add falling and a game over condition. 
I am thinking a fighter will fall when hit in midair, or when the 
health is depleted. A fighter cannot be hurt during the falling, 
or getting up states. A fighter cannot perform any other action in 
those states.

I'm going to start coding again tonight.  The list of things I plan 
on getting done before next Tuesday are:

- Improved animations for PJ.
- Get Mei Lan in there, including her animations and 
collision object setup.
- Start integration of particle systems.

The report has been submitted to GS&R.  They said it should be ready 
in 2 or 3 weeks.  Work on AF will continue in a few days.

I have received comments/corrections back from my committee members.  I 
will be done with a second draft sometime tonight.  Then I will send 
that off to my committee members again, wait for their nod (or at 
least lack of shake), and give a copy to Graduate Studies on Friday.

The 1st draft has been completed.  All 66 pages of it.  Well actually 
not really, I still need to do Appendix A, which is a class diagram. 
 It would be much sweeter though if I didn't have a bunch of work piled up 
to do over the weekend that I put off because I was working the thesis.  
Darn.

My sister Si Si found a glitch in my alpha version.  The low punch 
animation was done so poorly that it ended up hitting high.  Since 
the NPC thinks that low punchs will hit low, the adaptive NPC will 
actually learn to do the wrong thing!  It will keep think, low 
punch coming, block low, but then it gets hit high.  This will be 
fixed when I get around to redoing the animations.

I have suspended work on the game and am now in full writing mode.  I
 have a basic outline for the thesis and also gathered all my 
references and wrote notes about each.  I'm pretty much done with 
the AI code.  I might want to tweak a parameter or two later for 
gameplay.  I compile two alpha versions of my game for testing: 
one with the adaptive AI, and the other without (basically picks 
random moves and tactics).  I sent a request to a bunch of people to 
help me test it out.  I'm not having them test the gameplay or 
find bugs, but I gave them a small questionnaire regarding the 
difference (if any) between the two versions of the game.  The results 
of this survey will be incorporated into my thesis report.

- separated fighter to two subclases: FighterPlayer and FighterNpc
- added hurting action and animations
- fixed bug where totalpoints in a list was not in sync with points of
 its elements
- adaptive part of AI is basically done.  The NPC seems to be learning
 and adapting alright.  There a couple of indirect problems that 
affects the performance of the NPC.  (1) Some of the dummy animations I 
have now are bad enough to the point where the attack will miss 
the opponent, or hit low when it should hit high.  I'll try to get 
some other dummy animations in there that are more accurate.  (2) 
The are so few tactics right now, only three, that the NPC's moves 
are very limited.

In preparation for writing my thesis report, I updated my AI 
display so I can get better looking screenshots. Here are a couple of samples.

http://www.leolees.com/images/alphafighterss6.jpg
This shot is of the player(left) starting a high roundhouse 
kick(medium strong attack). The NPC got this prediction 
right(probability of med. strong = 0.936) so decided to block high. 
About the displays, I moved the numeric health displays so they are
 next to their respective fighter's health bar. The range display is 
moved up just a bit. I then squished all player's attack 
pattern HMM over to the left side of the screen. At the bottom are 
the three rows of logs: player's action log, NPC's action log, and 
NPC's tactics log. At the right bottom in blue, I show the details 
of the NPC's current tactic, with the current step highlighted. Above
 that, I have the predictions the AI is making about which attack the
 player is doing. The most probable one (The prediction) is 
highlighted. Also of note are the collision object colors, which I 
changed awhile back but never put a screenshot up for. Each individual 
body part has an independent state: attack(red), blocking(green), or 
neutral(yellow). Not seen here, but if a collision object is colliding,
 it is blue.

http://www.leolees.com/images/alphafighterss7.jpg
Just another screenshot, but at a quieter moment. One thing to note 
here is that the threat predictions are not shown. Instead, I display 
"No threat" when the player is not doing any attacks.

At the last meeting when I was telling Dr. Pollett about how the 
AI uses predefined "tactics" he asked if they were based on a 
script so I can easily add new ones.  They weren't, but it was 
certainly a good idea.  So I made it so tactics are read off a 
tactics specification file now.  The details are below, but one 
thing to note is that the loader ignores any not within a 
BEGIN_TACTIC/END_TACTIC pair.  This is so I can put in comments.  In 
fact, what follows below is the header comment from the tactics 
file itself.

(Taken from the tactics file)
**********************************************
Format for a tactic:
BEGIN_TACTIC name counteringFlag points
StepType param1 param2 ...
...
END_TACTIC

"BEGIN_TACTIC" and "END_TACTIC" are the string literals.

In the BEGIN_TACTIC line, name is the name for the tactic.
The counteringFlag parameter should be either 0 or 1.  
0 indicates the tactic is a regular, non-counter tactic,
1 indicates it is a counter tactic.
The points paramter is an integer of the initial point value
for this tactic.  The higher the points a tactic has, relative
to other tactics, the more likely it will be executed.  This is
only the initial point value, as points are dynamically changed
through reinforcement learning.

Each line between BEGIN_TACTIC and END_TACTIC specifies a step
for that tactic.  The sequence the steps are specified is the
order the steps will be executed for that tactic.  See below
on how to specify each particular type of step.

Format for various steps:

MoveToRange range
Range is an int within [0, NUM_DISTANCE_RANGE - 1]

Attack
No parameters

Block maxTime
maxTime is number of seconds to block at most.

Jump direction
direction is character in {'F', 'B', 'R', 'L'}, to indicate
which direction to jump: forward, back, right, or left respectively.

JumpAttack direction
direction (see Jump above)
**********************************************

- Added C2dStatModel, CStatList, CStatNode template classes 
  These are used for 3 of the 4 statistical models.  The only one 
that does not use this, is the prediction HMM, which has it's own 
class CPredictionModel, and it more complicated.   The other three 
statistical models are: for the NPC attack, regular tactics, and counter tactics.

It's 5am... tired....
Fixed a couple of bugs with controls:
- blocking while attacking e.g. low kick => right leg attack, left leg blocking
- while moving, block, fighter keeps moving

The big thing is new AI stuff.  I added CStrategy, CTactic, and CStep.
- Steps:
   + StepMoveToRange
   + StepJump
   + StepJumpAttack
   + StepAttack - still need to determine which attack to do
   + StepBlock

- Tactics:
   + Move to kicking range, attack
   + Move to kicking range, jump attack towards player
   + Block, attack

Still need to do.
- Log tactics over time
- Select tactic by weighed random.
- Reinforce logged tactics when one of 4 reinforcing events happen.
   (1) NPC damages player.
   (2) Player damages NPC.
   (3) NPC attacks, but doesn't hit player.
   (4) Player attacks, but doesn't hit NPC.
   Reinforcement weighed according to how long ago tactic occurred.
- Create attack statistical model.
- Train this model when damage() is called.
- Statistical model for counter-tactics.

I didn't blog for a few days so there are a number of things I 
updated. I haven't started coding the AI decision stuff though, 
although I have been thinking about it. I want to have a pretty good 
idea before I dive in. There are always details within details, but 
I'm getting close to a solid design and I should be starting to code by
 tonight. I am planning to have the AI mostly done by Tuesday. The 
design and implementation hopefully won't change from there, because I 
need to write the stuff up. But I might tweak things a bit 
afterwards. On to the list of updates.

(1) Restricted fighters from moving too close to each other.

(2) Exported from Milkshape with matrix keys, instead of rotation 
and translation keys. This seems to make the interpolation better.

(3) Put in sounds for menu cycle and select, and pause. Found some 
other sounds that should come in handy later. I'm not really 
worrying much about sound until after I submit my report.

(4) I changed it so instead of fighter's collision object being a 
composite, the fighter itself is a composite, made up of CBodyParts. 
This was one of my previous ideas. I went back and realized that this 
would be the best way to go. Each of these body parts have a 
non-composite collision object. A big advantage of this is I can tell
 which parts of the two fighters' bodies collided. This will allow me
 to make a more meaningful and accurate determination of who hit 
who, that is, better collision reaction (see 5 for detail). Later 
on, this will also allow me to easily add particle effects to the 
area where the collision occurred. Right now I don't determine the 
position the collisions occur, having body parts makes it easy 
since I know where the body part's collision objects are.

(5) FighterStates is now at a higher level and the old 
FighterState is now ActionCategory. There are three FighterStates, 
FS_NEUTRAL, FS_ATTACK, and FS_BLOCKING. The fighter itself has
 an overall state, and each of its body parts also has a state. This 
will be used in collision reaction. The fgt file has 8 lines after the 
collision object specs., one for each type of attack action. Each 
line is a list of which body parts are part of the attack. For 
example, a left jab might involve the bones: left_wrist, left_elbow, 
and left_shoulder. When an attack action occurs, these body parts are
 set to the attack state, while the others remain in the neutral state.
 The collision objects are drawn with different colors based on the 
state the body part is in. When a collision occurs then, I can tell 
whether an attacking part of the body is hitting a neutral part, or 
perhaps if two attacking parts are hitting each other. This is 
necessary to distinguish. If one fighter is punching and the other 
is kicking, there is a difference in the collision reaction whether 
I'm punching his head, or his kicking leg.

(6) Minor bug: fighters' body parts will collide on the first frame of 
playing state. Body parts don't get updated to fighters' positions 
until postMove(), which happens after detectcollision(). This isn't
 a problem in practice, but might be a little annoying when setting 
breakpoints in debugging. I probably won't have time to fix 
this since it isn't that important.

(7) Added mechanism so each attack can hit the other guy at most once.

Here is the planned schedule as of now.
- Now (Tues. 3/1) to Tues. 3/8: Work on AI decision and try to get 
it pretty much done. 
- Wed. 3/9: Start the report.
- Fri. 3/18: Produce a 1st draft of report and submit to committee 
members.
- Receive suggestions and comments back from committee before Tues. 3/29.
- Fri. 4/1: Submit revised draft to Graduate Studies.
- Afterwards: Continue putting finishing touches on game including:
+ Better animations.
+ Possibly more moves.
+ Possibly particle effects on hits.

Fixed bug where fighter jumps lower if 'k' is held.  Turns out that 
pressing 'k' prevented the stop action from being requested each 
frame, which had the effect of accumulating a negative y velocity 
due to gravity (The stop action sets velocity to zero).  Solved it 
by setting y component of velocity to zero if the fighter touches the 
ground, in addition to clamping the fighter above the floor.

I would say I have the prediction part of the AI done now. I am 
basically thinking of there being three stages: learning, 
predicting, and deciding. After some careful thought I have made 
some modifications.

(1) I will have two HMMs, one for predicting the player's next 
action, and one for keeping track of how well particular attacks 
work against the player. I have not implemented the second, 
offense HMM yet.

(2) The prediction HMM no longer cares about the player's health 
and NPC's health, but only the distance between the fighters. It 
is true the player may be more aggressive when she has more 
health and more defensive when she is weak, but I do not think 
her overall strategy changes. If I care about the healths, I can 
clearly see overfitting problems occurring. The AI will learn the 
player's strategy. One of the fighters loses enough health to 
drop to a lower level. Now the AI knows nothing in this new world 
state.

(3) Jump actions are no longer logged. I really only care about 
the player's attack actions, since I no longer need to predict 
when the player's action will occur, but only what it is.

(4) I decided the AI only gets one single action notification, 
and that is at the start of the action. Originally, there was 
consideration to update the set of possible moves, narrowing it 
down if the AI chooses to wait longer before making a decision. 
Since these actions are all relatively fast movements, I do 
not think that is representative of how a human player will play. 
With fast attacks, the human player basically see something 
coming and makes a decision what to do. She will not have the time 
to wait and see. The exception would be if the action was a very 
slow one. For example some games have attacks where you must 
charge up and then do the attack. In that case, it would be 
reasonable to give maybe two notifications to the AI. But in 
the case of quick attacks, I think one notification is 
reasonable.

Here is basically how the AI works now.

Learning:
- Each frame, check if player has logged a new action.
- If yes => train prediction HMM with that data.

Predicting:
- When the player starts an action that is logged (any attack 
type action), notify the AI the player is performing an action of 
a particular given category (FighterState).
- The AI receives this notification and updates its list 
of possible actions the player is performing. It keeps that along 
with a the probabilities of each of these possible actions, based 
on its prediction HMM.

I have completed items (1) and (2) from the previous blog. Item 1 was 
to specify the rest of PJ's collision objects. Item (2) was to 
get a paused game state in there. The pause menu is very simple, and 
I will probably keep it that way. It only has two options, resume 
playing the current game, and quit to the title screen. I will be 
trying to get the AI prediction stuff done by Tuesday before the 
meeting with Dr. Pollett.

I got the other half of collision object setup done. I had the 
collision spheres done awhile back, now it is complete with the 
collision capsules. Basically the work entailed getting it so the 
collision capsules can be specified in the fighter info 
(.fgt) file. Also the collision capsule moves with the fighter's 
animation. I found a bug in the segToSegDistance() code and fixed 
that. I was basically missing a couple of the border cases. 
Everything seems to be working fine now, although I have not had 
too much time to test it thoroughly yet. I will be placing 
the rest of PJ's collision objects (i.e. filling in his .fgt 
file) later tonight.

My goal to get done by next Tuesday is:
(1) Collision setup. This is completed as mentioned above.

(2) Pause game state. This might come in handy for debugging. I 
might even put in a frame-by-frame control for debugging.

(3) AI - Prediction. Based on a new method I have written down in 
my thesis notes, similar to the idea Dr. Pollett and I discussed 
last meeting. This is a refinement of my 
original "reaction time" idea.

The learning (updating of AI model) is completed.  In 
anticipation that I'll be adding more action types, I no longer 
log movement actions.  All movement actions are of the type 
FS_FREE (actually AI_STOP, the idle action is also this type), 
so I simply ignore logging the action of it is of this type.  I 
think it is reasonable because I really don't care about movement 
actions.  Perhaps the human player keeps track a little bit 
of things like, he likes to punch when moving forward.  But I think 
the same result is achieved (and perhaps it is even more true to 
what the human player thinks), when we think along the lines 
of, "He likes to punch when he is close to me."  Of course, 
distance is already taken into account in my AI model. 


I just checked on the speed a little bit, moving the MAX_N_GRAM 
value to 5.  This means we are using uni-grams, bi-grams, tri-
grams, 4-grams, and 5-grams in our HMM.  The framerate still did 
not show any significant drop.  The framerate is tied to the 
refresh rate so I won't notice any drop until it goes a little 
below 100 (my refresh rate is 100).  There is however a very 
noticeable difference in the time it takes to allocate and free the 
storage used by the AI model.  This is not surprising since the 
space requirement is O(n^n).  This is not a big deal though 
since I am not working with a very small amount of memory.  It 
would be a problem say if I was developing for a console system 
or something.


I also found out some possibly bad news today.  The copy I 
submit to graduate studies on April 1st must have a signature 
page with all three of my committee members' signatures.  
The problem is, I had planned with Dr. Pollett that I would 
continue working on the game to put finishing touches on it after 
the April 1st deadline.  But now basically I need the approval of 
my committee members on my thesis, before the game is 
finalized.  Hopefully they are all willing to let me keep 
working on finishing touches afterwards, instead of insisting 
that I finish everything before they sign off.

I worked more on the AI today.  Actually wasn't as productive as 
yesterday.  I actually thought about it slightly wrong.  It's 
actually a 3D matrix of HMM trees rather than a 4D that I stated 
before.  I had to redo some of the code because of that.  I 
still don't have the learning code in yet, but I'm going to 
sleep early so I can be fresh for my interview tomorrow.

The AI implementation is moving along. It's really an extension 
of what I did last semester for the HMM predictor applet. In 
that, the HMM was really modeling several n-grams inside it. Well 
the model for AF is an HMM that basically holds several of those 
HMM models. Each of these are tree structures. Each level of 
the tree is basically another level of n-gram. For example the 
root contains the unigram information, level 1 the bigram 
info, level 2 the trigram, etc. Each of these trees are specific 
to a particular action and state of the world. There is a 4D 
matrix where each cell holds a pointer to the root of one of 
these trees. The 4 indices of the matrix are action, player's 
health, NPC's health, and distance. It is a huge data 
structure so I am a little nervous about efficiency issues 
down the line, but I'll just have to wait and deal with it if the 
need for optimization comes up later. At this point the 
structure is set up, at least to the point where the unigram model 
could be used. I have to code in updating (learning) part, 
probably tomorrow after my midterm.

I was thinking about the details of the AI system today, which led 
me to rethink some of my initial design. There are two points.


First, I think the way I was thinking about it being a Dynamic 
Bayesian Network was more complicated than it needs to be. 
It's really just a static model, a Bayesian Network, but with its 
probability tables adjusted for the learning. There are really 
just two levels here. The top level represents the state of the 
world such as the fighter's health, distance between 
fighters, history of actions for each fighter, etc. All of these 
affect the lower level, which are the probabilities for each 
possible action. This is really what it boils down to. I suppose 
this was really what I was thinking initially too, but 
somehow I was trying to fit it within the framework of a time 
based model, which just made it more confusing than it should be.



Second, I was thinking about how the AF AI system is different 
from the AI in the small experiments I did last semester 
in CS297. One big difference is that in those programs, I 
basically didn't have to worry about time. Things basically 
happened turn-based, I waited for the player to make a move and 
then made mine. It didn't matter if I made my move 1 ms or 1 hour 
after the player as far as the AI was concerned. It would have been 
the same move and the outcome would have been the same. In AF, 
timing is a big consideration. My prediction is dependent on time, 
and not only that, but I must make my decision within a certain 
timeframe for it to be useful. I had this idea before of 
simulating the "reaction time" of a human player. When a person 
plays, she doesn't say, "I predict my opponent will throw a 
jab in 1 second." She is thinking more on the lines of, "I think 
he's going to throw a jab soon, I'll get ready for that." This 
puts the human player in a state of being prepared for a jab, but 
the player will still rely on her reaction time to see when the jab 
is coming. If the player's prediction is right, then it's 
likely the player will be able to defend or counter the jab. If the 
player was wrong, say the opponent does a low kick instead, 
then that will throw the player off and it's more likely she will 
not be able to defend against that attack. I plan to simulate 
this with what I'll call the reaction time model. When the 
player performs an action, the NPC could of course cheat and 
find out what that action is. To avoid that, although that action 
goes into the fighter's action history, the NPC cannot observe 
it until after a reaction time period. This reaction time period 
is variable, and is determined on a per action basis. It is based 
on what the NPC is thinking at the time the action occurs. For 
example, if the player throws a jab, and the NPC was thinking the 
probability the player will throw a jab is very high, the reaction 
time for that action is very short. Thus, the NPC will be able 
to realize the player threw a jab very soon after it happens, and 
it will probably be in time for the NPC to perform a defense or 
counter move. On the other hand, if the NPC was thinking the 
probability of a jab is very low, then the NPC was caught off 
guard. The reaction time for that action is set to a high value. In 
this case, it is likely the attack will hit the NPC before 
the NPC even knows it has happened so to speak. I believe 
this approach will provide a much more robust AI system and a more 
human-like system, than if the NPC was strongly depending on the 
system to predict exactly when the action will occur. This 
rewards the NPC for making good predictions, but gives 
flexibility even when the predictions aren't right on.

I had finished doing the CD code awhile back, but never got around 
to placing the actually collision objects on the fighters. While I 
was thinking about how to 
implement the AI, I started 
working on getting these collision objects in place for 
one of my characters, Perry Johnson. I decided to use the 
fighter info file (.fgt) to specify where collision objects 
should go for a data-driven approach. I hit a slight hurdle 
last night when I realized I must basically animate these collision 
objects just as I animate my character's skinned mesh. There 
was no easy way I could think of to place additional "collision 
object vertices" inside my main character mesh. Well actually it 
was more like there was no easy way for me to get it out from the 
VB. Anyways, so I had to basically do the animation 
separately for the collision objects. I have this done for 
collision spheres and I have set up the spherical components of 
PJ's collision composite object. This includes areas like his head 
and fists. I still need to do this for collision capsules. 
Capsules will be used for the limbs. I will probably have to 
suspend this until later since I should probably be starting my AI 
implementation tomorrow.

Here are some screenshots.

This one has the collision object drawn over the character mesh.
http://www.leolees.com/images/alphafighterss3.jpg

This one looks like two snowmen are about to duke it out with 
each other. It's showing only the collision objects.
http://www.leolees.com/images/alphafighterss4.jpg

This one shows that the collision objects are moving with the 
animation, and that a collision is detected (collision objects 
are red). Note that these are two collision composite objects. That 
is why even though say, the spheres on the head of the 
fighters are not physically colliding, logically they still 
are since the spheres are part of the composite.
http://www.leolees.com/images/alphafighterss5.jpg

So in the meeting with Dr. Pollett today we mainly talked 
about the AI system.  I showed him the design I had again in my 
AI System writeup.  Several areas needed to be adjusted, but 
overall it was decided the approach is good enough to 
implement.  Over the next week I'll be working on the 1st half 
of the brain, the part responsible for prediction.  The 
2nd half would be the part responsible for making a 
decision.  One concern I had was that if I kept track of even 
small actions like the player moving, I would be keeping track 
of too much stuff.  That in turn could lead to overfitting 
problems and inefficiency.  I was thinking of the weighted 
influence of something as falling off over time elapsed.  Pollett 
brought out a simple idea that I didn't even think about.  I could 
just base these weights on a factor such as how much damage I 
took from the corresponding action.  So in this case, most 
walking type action won't last in my memory for long.  They don't 
need to be because they're not very significant.  On the other 
hand, attacks are likely to stay in my memory for awhile since 
they have the potential to damage me.  I could even incorporate 
time with this idea.  So for example, maybe nothing is 
happening, so actions tend to be forgettable.  Now I get hit, now 
actions that occured near when I got hit are very significant. 

Controls are now all working. I even added a simple jump animation.
 I also got capsule-capsule CD working now. I finally got around 
to doing the segToSegDistance() which calculates the closest 
distance between two line segments. This is used for the special case 
of capsule-capsule CD when only the two cylinder bodies are touching 
and not the spherical caps. I made a new class, CCollisionComposite, 
but didn't really do anything with it yet. This will of course be what
 the fighters actually use. Their collision objects will be made up 
of spheres and capsules. I think I'll put the placement and 
orientation of these component collision objects in the fighters' 
.fgt files.

The controls were basically finished late last night. The 
only thing that still needs to be added is the jump attack. Most of 
the animations are still dummy placeholders. I figure that art 
isn't crucial to my thesis report, so even if I need to 
replace a few animations after the April 1st deadline it won't 
be a problem. So tonight for valentine's day, I'll be spending 
it with my love, programming! I'll get the jump attack control 
in there and possibly finish up the capsule-capsule CD. I also 
need to rethink the AI a bit. I have a feeling the way I have it 
set up now, the NPC might just stand there and always wait for 
the player to get closer. The AI system is working on a defensive 
strategy, I need to also incorporate an offensive strategy.

Since having completed the animation code.  I've been 
working on getting the controls squared away.  I'm calling it 
the "controls logic" although I'm not sure if that's the right 
term.  Basically I need to build in the logic that dictates what 
actions a fighter can and can't do at any particular situation.  
For example, a fighter should not be able to start another attack 
while a prior one is still being executed.

I should be done with this by next week, at which time Dr. 
Pollett and I will start discussing the AI.

This is a repost from the (Mon, 24 Jan 2005 15:41:12 PST ) entry, 
which was formatted badly.


I stayed up late last night (or should I say early this morning 
since it was 8am when I went to sleep) to finish up my writeup on 
the AI system. Everything was basically outlined during the 
trip. I guess it marks the beginning of the semester's work. 
I hope I can stay on top of the hectic schedule I've set up for 
myself.

This could be considered a milestone - animation works!  So 
I guess it took about two and a half days to get it working.  
It's not interactive yet, in fact I still have to create the real 
animations for the fighters, but it is finall animating.  I 
eventually had to ditch the vertex shader route.  My ATI 
Radeon 9000 only supports vertex shader 1.1.  There are several 
problems with using 1.1 to do vertex blending.  While there are 
ways around these problems, it turned out to be not exactly 
trivial.  Luckily, I found an article on MSDN on the various 
ways one can do skinning.  I settled on using 
ID3DXSkinInfo::UpdateSkinnedMesh(), which performs software 
skinning.  Well actually I didn't have much of a choice as my card 
doesn't support vertex blending.  The speed is still quite 
reasonable though despite skinning in s/w. 


The next step now is to create the animations for my two 
characters I have now, Perry Johnson and Mei Lan.  Then I'll 
have to add in the interactivity, i.e., the controls.  Hopefully I 
can get all of this done by early next week since Dr. Pollett and I 
are suppose to discuss the AI system at that time.
   

I was making pretty good progress on getting animation in and hit a 
hurdle last night.  It all started when I found out that the 
function I wanted to use ID3DXAnimationController::AdvanceTime(), 
wasn't added until the December 2004 release of the 
DirectX SDK.  So I downloaded it and got back to work after 
getting home from school.  Compiler errors started popping 
up left and right because they made some changes to some of the 
functions.  I fixed those fairly quickly and ran it, but then I 
got a mysterious crash bug.  The error message was not helpful.  I 
finally narrowed it down to a problem with the X-file itself.  
In fact, the new Mesh Viewer (it was updated from v1.0 to v9.- ???) 
wouldn't open up my X-files anymore.   It would still open up 
tiny.x so I suspected it must be the exporter for Milkshape.  
Searching through forums were of no help.  Finally, in comparing 
the tiny.x and my .X file I found that an attribute was declared 
with different types, changing that solved the problem!  More 
specifically, my X file had:


template SkinWeights
{
    <6F0D123B-BAD2-4167-A0D0-80224F25FABB>
    CSTRING transformNodeName;
    DWORD nWeights;
    array DWORD vertexIndices[nWeights];
    array FLOAT weights[nWeights];
    Matrix4x4 matrixOffset;
}

Changing "CSTRING" to "STRING" solved the problem.

Now I can get back to programming.

So I've started implementing the animation stuff and I realized 
that the way I was thinking of breaking down the CFighter into 
CBodyParts won't work with the way the animation is done.  
Intially I was going to have CFighter be composed of 
CBodyParts, which would be a subclass of CEntity.  Each of the 
body parts would have their own 
visual.  For example the arm, 
would hold the arm part of the mesh and so on.  I've found out 
that this is not the way one wants to do animation, also known 
as rigid body animation, because it leads to unsightly seams and 
sharp angles at the joints.  Instead, using a skinned mesh is 
preferred.  In this case I would just keep the entire mesh as 
one.   After some thinking, here's what I came up with.  I 
can still make the CFighter up with CBodyParts, and the body 
parts can still be derived from CEntity.  However, they would not 
have visuals.  Only the fighter itself is responsible for drawing 
the entire skinned mesh.  The fighter has a CModelSkinned, 
which will contain the D3DXFRAME hierarchy, i.e. the mesh and 
skeleton.  The fighter itself though, will have a its own 
hierarchy, the structure of which will be a duplicate of the 
D3DXFRAME hierarchy, except this one will contain CBodyParts 
instead.  These body parts will hold attributes like its status 
flag (attacking, neutral, defending), and collision 
object.  So basically I can still delegate the collision 
detection/reaction down to the body part level, but the 
rendering of the mesh has to be isolated to the top level, 
CFighter, because I'm using a skinned mesh.

I figured collision planes are unnecessary, so I took them out. 
Also added a new display mode, where both the normal visual is 
displayed and the collision object. The same key is still 
used to cycle through the now 3 display modes: normal only, 
normal and collision, collision only. The most notable thing is I 
found out the cause behind the mysterious black lines bug. I was 
having this problem where when drawing lines, sometimes the 
lines would show up black when they should have color. I thought 
it was a problem with how I was flushing some lines early when I 
run out of VB space. Today, I had a similar problem where the 
wireframe collision meshes for the fighter capsules were being 
drawn in black if they were the only ones around. But if I had a 
CBall added after I added the fighters, everything would show 
up fine. It turns out the cause was texturing. It seems that when 
I have a texture set, the lines and wireframe mesh are using the 
texture and turning out black. I got around it by just setting the 
texture to null before I make the relevant rendering calls. I'm 
still slightly perplexed by it since I would think the texture 
should be ignored because I'm setting the FVF to one without 
texture coordinates. But anyway, now everything is nicely colored 
the way they should be.


I also realized the capsule-capsule CD isn't working because 
I was finding shortest line to line distance, but I should have 
been looking for shortest segment to segment distance. Segment to 
segment shortest distance turns out to be a little more 
complicated so I'm postponing that, especially since it isn't 
crucial for CD to be working at this point. That's the last of 
the CD anyways though. I'm going to move on to animation next time.



Oh yea, I'm also going to simplify the way of making sure 
the fighters stay within their boundaries, both on the stage and 
not running into each other. At first, I was going to handle it 
through their collision reaction. That is probably a better way to 
do it, but I'm going with a much simpler approach. Basically I 
added a postMove() method for entities. This is where after 
they have moved, but before they are rendered, they can adjust 
themselves to satisfy whatever constraints they have. So for the 
fighters, they would check to make sure they're (1) not below 
the floor, (2) not off the stage, and (3) not too close to the 
other fighter. In effect, they're doing a very simple CD and 
reaction all within that method.

Got sphere-capsule CD done.  Capsule-capsule CD mostly works 
too, but I haven't finished testing it.  I think there might 
be some problems, especially when I start rotating the owner 
entities.  I'm planning to get the rest of the CD stuff done by 
this weekend.  Next week will be devoted to animation.  I'm hoping 
by the end of next weekend I'll have most of the controls and 
some corresponding animations in.  I won't deal with collision 
reaction yet.  So they'll basically be like two ghosts 
trying to hit each other.  This will allow for observation of 
future AI experimentations.

Got the collision capsule display working.  It took a little bit of 
restructuring the way CGraphics does the drawSphere and 
drawCylinder calls.  Actually it just has drawSurface() now and 
the type you want is specified as a parameter.  I also got rid of a 
couple of things.  The virtual getMin/Max() functions of 
CCollisionObject are gone.  They were meant to be bounding 
dimensions in world space for the collision objects but I don't 
think they're actually neccessary and were just left over from Spin 
Cycle.  I also got rid of the floor collision reaction, which 
was to be used to keep the fighters above the floor.  On 
second thought though I'm going to keep things simple and just 
clamp the fighters so they stay above a certain y (the floor) and 
within the bounds of the stage; probably in the move method or 
something.

Fixed the bug where rendering the same mesh multiple times in a 
frame would only draw the last one.  It was a dumb mistake, I 
forgot to call SetTransform to change the world matrix, so all 
the render instances were just going to the same place.  I also 
started some work on getting a collision capsule to show up.  
The cylinder is orientated the wrong way right now though.  My 
sleeping schedule is kind of messed up from the trip, didn't 
sleep at all last night, so I'm going to go to bed really early 
tonight.

I started coding again a little today.  Here's what went on.

Bugs:
The follow camera sometimes will be messed up (doesn't follow), 
after switching from the debug camera back to the follow 
camera.  I only experienced this once though at the beginning of 
the session so maybe I inadvertently fixed it.


The problem where some lines drawn using CGraphics::drawLine() 
show up black is still there.  The ones flushed early because I 
ran out of VB space show up black, but the ones flushed 
regularly have color.  I haven't figured out why that is though.  
I could just crank the VB size up, but a more robust solution 
would be preferable.


I'm trying to use one sphere ID3DMesh for rendering multiple 
spheres, by just setting the render states for each sphere I 
want to draw and then calling DrawSubet() for each one.  But it 
isn't working, only the last sphere is being rendered.  Made a 
post on gamedev on whether I can call DrawSubset for one mesh 
multiple times for one frame.  If not, that's the problem.



Done:
Added a button to toggle cameras instead of it automatically going 
to the free camera in debug mode.


Added m_colliding flag for entity: true if colliding with 
something this frame.

Collision object display, which shows the collision objects 
instead of the normal objects.  The collision object is shown in 
wireframe, red if currently colliding, white otherwise.  So 
far I only have it working for collision spheres.


Made it so the game reverts to using the normal camera and 
display flags when turning off debug mode.


Next:
I'll try to fix the last bug concerning DrawSubset(), and then 
try to implement the other CD stuff.  After that I'll try to 
get it to a state where experimenting with the AI will be 
easier.  I basically just need to add some dummy observable changes 
on performing the various possible actions, and probably 
some display of the current "thoughts" of the NPC.

- Write 297 report by next week.
- Probably hold off on working on character until break.

Oops, forgot to blog.
- Made HMM prediction prog. in context of game.
- Did some work on texturing (hand, arm).

- Finished HMM program
- Touched up previous slides as deliverable 3
- Still working on model.....

- Got the body of model, still need to make head.
- Halfway done with HMM word prediction prog.

- Continue modeling
- Create HMM word prediction program

Done most of reading and slides.
Still working on model.

To Do:
- Slides for reading:
 + [Tozour04] and [Ghahramani01]
 + Literature on IK and FK
- Get at least one model made

Done:
- Redid deliverable 2
  * Converted to html
  * Added section on research

To Do:
- Figure out a way to export model.

Done:
- Deliverables 1 and 2 online

To Do:
- Add research data for payoff matrices.
- Convert deliverable 2 from pdf to html.
- Figure out a way to export model out of Maya or other tool.

Done:
- Initial ideas for characters and moves.

To Do:
- Bring completed deliverables to next meeting with descriptions.
- Write down game premise.
- Add more variety of characters.
- Construct payoff matrix based on research on real fights.

Done:
- Demoed RPS app and showed survey of its performance against people
- Made a Java applet of RPS, which was originally in C++

To Do:
- Game characters/moves

Done:
- Finished n-gram word predictor
- Finished Rock, Paper, Scissors app

To Do before next meeting:
- Collect performance info from friends testing RPS app
- Create ideas for characters and moves

Done from last week:
- Finished design and ~60% done with code for n-gram word predictor
- Read [Manslow04]

To do before next meeting:
- Finish n-gram word predictor
- Create ideas for cool characters and moves
- Make simple sequence prediction program, Rock, Paper, Scissors,
based on string-matching from [Mommersteeg02].
Test on human players to see how well it works.

Done from last week:
- Read [Charniak96], [Evans02], [Kaukoranta04], [Laramee02],
[Manslow02], [Mommersteeg02], [Yamamoto03].
- Completed PowerPoint presentation of literature
- Started design on n-gram word predictor

To do this week:
- Continue design
- Start coding
- Read [Manslow04]

After I finish reading the literature for this week, 
I will prepare a half hour PowerPoint presentation on what I've taken from them.  
I will then work on a design for my n-gram program and do a one page write up on that.  
I will also start doing a bit of coding and present that at the next meeting.

Stuff