Chris Pollett >
Students >
Leo
( Print
View )
[Bio]
[Project Blog]
[CS297Proposal]
[Del1]
[Del2]
[Papers Slides-PDF]
[Del4]
[CS297Report-PDF]
[CS299Proposal]
[CS299Report-PDF]
[CS299Presentation-PDF]
[Grad Photo1-JPG]
[Grad Photo2-JPG]
[Grad Photo3-JPG]
|
CS297-298 Project News Feed
Done
(Posted on Tue, 24 May 2005 22:44:49 PDT
.)
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.
|
Done...?
(Posted on Tue, 24 May 2005 00:04:05 PDT
.)
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 Animation Glitch
(Posted on Sun, 22 May 2005 03:31:34 PDT
.)
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.
|
More Stuff
(Posted on Sat, 21 May 2005 15:22:50 PDT
.)
- 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.
|
Slides and Sounds
(Posted on Sat, 21 May 2005 15:21:09 PDT
.)
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.
|
Not Plagiarized
(Posted on Wed, 11 May 2005 02:23:19 PDT
.)
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.
|
Update
(Posted on Wed, 11 May 2005 02:20:54 PDT
.)
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.
|
Back
(Posted on Mon, 02 May 2005 01:13:03 PDT
.)
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.
|
Particle Systems and Animation
(Posted on Sun, 10 Apr 2005 14:16:25 PDT
.)
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.
|
Diving Back Into Code
(Posted on Tue, 05 Apr 2005 15:41:44 PDT
.)
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.
|
Submission to GS&R
(Posted on Fri, 01 Apr 2005 20:25:58 PST
.)
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.
|
Developing 2nd Draft
(Posted on Wed, 30 Mar 2005 15:56:14 PST
.)
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.
|
First Draft
(Posted on Fri, 18 Mar 2005 23:10:15 PST
.)
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.
|
Glitch
(Posted on Tue, 15 Mar 2005 22:45:55 PST
.)
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.
|
Finalized AI. Writing Mode.
(Posted on Sun, 13 Mar 2005 15:07:24 PST
.)
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.
|
AI Completed...
(Posted on Sat, 12 Mar 2005 13:45:49 PST
.)
- 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.
|
New AI Display
(Posted on Wed, 09 Mar 2005 17:26:38 PST
.)
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.
|
Tactics script file
(Posted on Wed, 09 Mar 2005 14:44:51 PST
.)
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)
**********************************************
|
Statistical Models
(Posted on Wed, 09 Mar 2005 00:43:03 PST
.)
- 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.
|
AI - Strategy, Tactics, Steps
(Posted on Tue, 08 Mar 2005 05:24:46 PST
.)
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.
|
Collision Reaction and More
(Posted on Sun, 06 Mar 2005 17:24:00 PST
.)
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.
|
Schedule
(Posted on Tue, 01 Mar 2005 15:03:59 PST
.)
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.
|
Jump Bug Fixed
(Posted on Tue, 01 Mar 2005 10:30:02 PST
.)
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.
|
AI Prediction and Changes
(Posted on Mon, 28 Feb 2005 00:36:12 PST
.)
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.
|
Collision object placement and paused state
(Posted on Sun, 27 Feb 2005 12:57:52 PST
.)
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.
|
Collision Capsule Setup
(Posted on Fri, 25 Feb 2005 17:03:43 PST
.)
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.
|
AI Learning
(Posted on Thu, 24 Feb 2005 23:40:16 PST
.)
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.
|
More AI
(Posted on Tue, 22 Feb 2005 02:12:21 PST
.)
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.
|
AI Implementation
(Posted on Mon, 21 Feb 2005 00:59:15 PST
.)
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.
|
AI System Design Thoughts
(Posted on Sat, 19 Feb 2005 23:11:56 PST
.)
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.
|
Collision Objects
(Posted on Sat, 19 Feb 2005 11:59:56 PST
.)
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
|
Meeting
(Posted on Tue, 15 Feb 2005 14:53:54 PST
.)
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 Complete and Capsule-Capsule CD
(Posted on Tue, 15 Feb 2005 10:16:11 PST
.)
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.
|
Valentine's Coding - Most of Controls Completed
(Posted on Mon, 14 Feb 2005 13:23:38 PST
.)
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.
|
Controls
(Posted on Wed, 09 Feb 2005 17:27:10 PST
.)
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.
|
Repost from (Mon, 24 Jan 2005 15:41:12 PST )
(Posted on Wed, 09 Feb 2005 17:23:32 PST
.)
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.
|
Let there be Animation!
(Posted on Thu, 03 Feb 2005 23:37:38 PST
.)
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.
|
Title for BLOG entry.
(Posted on Thu, 03 Feb 2005 09:42:36 PST
.)
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.
|
Title for BLOG entry.
(Posted on Tue, 01 Feb 2005 09:38:38 PST
.)
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.
|
Title for BLOG entry.
(Posted on Sun, 30 Jan 2005 15:49:31 PST
.)
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.
|
(Posted on Sat, 29 Jan 2005 06:43:01 PST
.)
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.
|
Title for BLOG entry.
(Posted on Fri, 28 Jan 2005 02:38:09 PST
.)
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.
|
Title for BLOG entry.
(Posted on Wed, 26 Jan 2005 21:17:48 PST
.)
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.
|
Title for BLOG entry.
(Posted on Wed, 26 Jan 2005 02:56:12 PST
.)
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.
|
Final 297 stretch
(Posted on Tue, 30 Nov 2004 21:17:41 PST
.)
- Write 297 report by next week.
- Probably hold off on working on character until break.
|
touch up HMM prog
(Posted on Sun, 28 Nov 2004 19:09:42 PST
.)
Oops, forgot to blog.
- Made HMM prediction prog. in context of game.
- Did some work on texturing (hand, arm).
|
Just modelling
(Posted on Fri, 12 Nov 2004 00:10:48 PST
.)
- Finished HMM program
- Touched up previous slides as deliverable 3
- Still working on model.....
|
Half way on Modeling and HMM
(Posted on Wed, 10 Nov 2004 22:13:53 PST
.)
- Got the body of model, still need to make head.
- Halfway done with HMM word prediction prog.
|
Modeling and HMM
(Posted on Tue, 02 Nov 2004 14:02:56 PST
.)
- Continue modeling
- Create HMM word prediction program
|
Still reading and modeling
(Posted on Wed, 27 Oct 2004 11:35:07 PDT
.)
Done most of reading and slides.
Still working on model.
|
Some reading and start modeling
(Posted on Tue, 19 Oct 2004 15:04:25 PDT
.)
To Do:
- Slides for reading:
+ [Tozour04] and [Ghahramani01]
+ Literature on IK and FK
- Get at least one model made
|
Deliverable 2 redone
(Posted on Wed, 13 Oct 2004 02:41:18 PDT
.)
Done:
- Redid deliverable 2
* Converted to html
* Added section on research
To Do:
- Figure out a way to export model.
|
Rework deliverable 2 and start on deliverable 3
(Posted on Tue, 05 Oct 2004 16:18:58 PDT
.)
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.
|
Onto 3rd Deliverable
(Posted on Wed, 22 Sep 2004 01:11:00 PDT
.)
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.
|
RPS add-on
(Posted on Thu, 16 Sep 2004 14:05:21 PDT
.)
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
|
Progress on 2nd Deliverable
(Posted on Mon, 13 Sep 2004 14:38:39 PDT
.)
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
|
Finishing 1st Deliverable
(Posted on Tue, 07 Sep 2004 15:20:29 PDT
.)
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.
|
Up Front Reading
(Posted on Tue, 31 Aug 2004 12:40:57 PDT
.)
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]
|
The Beginning
(Posted on Tue, 24 Aug 2004 15:23:30 PDT
.)
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.
|
My test entry
(Posted on Tue, 24 Aug 2004 13:19:28 PDT
.)
Stuff
|
Really Simple Syndication (RSS) Feed...
|