Trade Show & It's all over!

Project has finally come to an end, and after an awesome Trade Show in which we jointly won the Best Project at the Trade Show 2011, it's all over! We're very happy with what we produced, which met all our initial expectations and all went to plan. We've all learned a lot in the process, in the fields of coding, game design, teamwork, organisational skills and computer science project development cycles.

That's Just... Low!

COM/AI reaches an all-time high (correctly using moves corresponding to your hitbox including knocked down) and an all-time low (kicking you while you're down) in the same revision.

Move ranges, effects, polish

More stuff tonight... a slow-down effect when you KO the other player, some small bugfixes, some small improvements to the game and to the animation, another small piece of music, and "Move Hit Ranges". Now instead of a move having only a set instant where it "hits" and if it isn't it range then the move is discarded, moves have a time window where the move can potentially hit. This was made for, especially, Takeshi's flying kick where any time he is flying in the air is a potential hit, not just one particular moment in the air.

Moves such as Takeshi's flying kick didn't have a specific
instant of time that the move connected.

Polish-wise, I've just implemented various all-around improvements like removing the "Round 1" announcement from training mode, not allowing you to choose AI for story mode, and that sort of thing.

I've also tinkered with the AI/COM and am glad to say it plays a lot better now. It's more fun to watch and makes for more exciting demos. I did discover one bug which made it impossible for AI/COMs to do crouching moves (even though there are only two.) The subsequent fixing of this bug and a few other bugs which affected blocking, introduced by the new HitBox type "Lowest" (which can also hit downed fighters, unlike "Low",) and a bit of tweaking, was vital to this improvement.

Final touches.

I'm glad to say that this week, in the coming days before the trade show, we have only the final touches to put on Project Sensei-now I'm doing nice things like making the demo mode loop, making additional sound effects and polishing up some of the graphics, making small changes to how the game looks--just details here and there. Probably some time tonight I'll start working a bit more on polishing the AI/COM behaviour, as it just needs a little tweaking to give a more exciting and natural performance for demonstration purposes.

Interfaces, menus, physics fixes, polish

Last night for about 4 hours I worked on completing the menus, in particular the in-game pause menu which needed a new submenu "COM Customisation". I also added varies elements to the existing UI to polish it. For example, the credits screen now says (B) Back in the corner, and blank black backgrounds in two of the screens have been replaced with a dark grey scrolling plasma pattern.

This morning I did a few major fixes to a couple of small bugs in the event manager related to physics. One such bug was that move-related inertia was being inverted entirely where only the X component of the 2D vector should have been inverted. Another bug was using the inertia value before clamping it, resulting in the full inertia for one frame then the clamped inertia from then on (imagine teleportation.) This bug was only noticeable with move inertia significantly greater than the clamping threshold (10).

Now we can do proper flying punches and kicks in our combos without teleporting.

OneClick Installation

After about an hours worth of debugging and getting this OneClick installation to gather all the right dependencies and figure out why it wanted to load things that didn't exist (but once did) and forget to create some folders (guess since there was nothing in there...) I finally have a working Windows Binary installer setup binary for Sensei. This is a good milestone.

More polish work

Tonight in the last hour I've put together the new in-game paused menu with a brand new volume slider bar. I've also touched up some of the intro screens and I plan to polish up a few of the other UI screens now.

Shiny. Das ist gut.

Helpful instructions and a clean interface.

And now, inexplicably, it's grey and ripply. Yay

Project Polishing

All yesterday and all morning today I've been busy working on polishing up Sensei. Knocking off things on the TODO list is our group's hobby right now, and last night I did a few more UI elements, shaded Takeshi and Catalina and gave them their final look, did some bugfixing with the guys and today I'm finalising the Technical Manual.

Knockdown

Here's what the effect looks like when you use a Knockdown move.

Tons of AI/COM/DecisionSystem work

All this afternoon I've been working on AI/COM/DecisionSystem stuff (except for a few bugfixes here and there, some small changes I required to do certain things, improving a little bit here and there, and debugging) -- I improved the degree to which the DecisionSystem responded to the personality traits--and refined blocking and countering tactics to ensure I had full control over when and where it was happening (counter attacks were happing by chance before, more than they should have.)

AI now has "rage" training which is an informal term for the ability to learn and morph its states based on its experience as a fighter. At learning speed l = 0.1, which is quite fast, after 3-5 minutes the trainee has the mindset of a champion-- it's ready to lunge at the opponent and attempt counter attacks where appropriate. The personality traits that make up this mindset are static for different COM difficulties. So, a beginner level COM will jump around and wander aimlessly sometimes, unsure or perhaps a little afraid to approach the opponent. A normal-level COM will get into it but give an average performance.

Training now saves and loads AI brain modules in their full capacity and in that regard is functionally complete. I can now train real AI save files through the game.

Another big hurdle I got through tonight was combos. I implemented, for both COM and AI, a combo limiting function which applies a threshold on the variety of moves in the moveset they will use, and how often. In this regard, an AI or COM with very high competence in combo moves will almost always use combination moves (like a human that has memorised the combinations AXY, ABB, AAX, etc.) Conversely, those with low competence will never use combination moves, and thus cannot practically learn them until they are more adept. This brings a slightly cool side-effect that you can't teach the best moves to a newbie trainee since they will not understand it.

AI stuff

During the Skype work session tonight I got a lot done on the AI and it has blocking and countering fully implemented, learning and improving. At the moment our default learning speed is pretty high as in a few rounds it can master blocking (100%.) But it's good for testing.

We now have an AI visual interface to measure the training and observe the AI. I may make a second interface to show the inner workings of the AI's thoughts since this is basically just to aid training the AI.

More stuff!

More work on the computer-controlled characters. Their behaviour should be highly tweakable now and they can put up a good fight when they want to. Also, I've made the counter-move special effect so it's highly noticeable.

DecisionSystem/COM

Now I'm working on the DecisionSystem and COM code. I've implemented counters so that can be done. Right now I'm going through and filling in small gaps in the decision tree but the main thing I'm doing is getting everything to use the Personality variables. So, blocking will be less successful if the personality has mercy and they are winning by a fair bit. It's almost all "fuzzy logic" so the end result is a more natural behaviour. The main thing I have to implement personality for is so that the different difficulties of COM actually differ in behaviour. In that regard I believe I'm successful so far. Expert COM is just about impossible to beat, even though it doesn't use the debug move that kills you instantly any more. For now the COMs don't do combos because of the way the move sets are being played with at the moment (by the fighting engine guys) so they only do basic attacks. But when that's sorted out they'll being doing combos and all that.

Dojo Battle Music

Music I composed this morning for the Dojo.

Putting new sounds in

Hehe. These bugs are funny :)

Voice Acting

Today we did the official voice acting session for Sensei. This included Takeshi (played by me), Ivanov (played by Vince) and Catalina (played by a friend) grunts and groans, good times and laughs were had by all. I also did the announcer's voice.

Outtakes :P

We had the whole group there so in total there were 5 people... 1 person voice acting with 4 people trying to stifle bursts of laughter (at least in the beginning) ... Haha.

Character Selection Screen improvements

The new and improved Character Selection Screen has fewer controls down the bottom to confuse people with. Start is no longer required to begin the game in Quick Fight, it starts when both characters are chosen. I also put in coloured dots and a colour overlay with the selectors to make it more obvious which one you were choosing.

AI/COM linkage

This morning I've been working on linking up the AI and COM stuff to actually be useful in the game. There is a "stock" default AI in there called Punchbag which has a learning speed of 0 and knows nothing. We can use this AI to beat up like a punching bag and it will never retaliate.

New AIs can now be created from inside the game and used. They will learn in Training mode but not in Quick Fight (that's just a fight, not a learning session.) COM difficulty goes from Beginner to Expert and actually sets the COM's personality. That isn't extensively used in the code yet so the appearance is minimal for now, but the values are there as actual personality structured information instead of quickly hacked debug ones.

I am going to do more AI/COM work when I get a big block of time to work on it. I don't want to sort of start to get into it then have to rush off since I want to focus on it so that I can get things working properly and effectively. It's not a quick 10 minute job to add new features to the AI like it is for UI, so for the rest of this morning, the next few hours, I'll be doing odds and ends to get the game's polish up.

AI management

This morning I've been working on getting AI saving and loading, and integrating AI creation, selection and deletion from the Character Select screen.

The AI Brain creation screen. Only one player may create an AI at a time. Very simple for now, I might just put some psychedelic background and we're all done really.

Two players may select or delete AIs simultaneously.

More stuffs

I made a proper credits screen which looks really good now, fixed up a few things in UI, made some improvements to the effects in game, and tweaked a few things here and there.

High priority items on TODO list remaining:

AI Saving/Loading functionality
All UI graphics complete
AI readout display
Final Colour/Shade character sprites

And a lot of medium priority things.

Then if I finish that I can just polish (week 13 probably.)

Moscow!

We now have Ivanov's stage in: Moscow:

And some health bar bug fixes.

Blooper Reel #2

Trying to get animations to play backwards, I just dived into the code and thought I could hack it in a few minutes. Hilarity ensues, possibly more awesome than the desired result. 10 minutes later I got it working properly though :p

COM packs a punch

Okay so I just linked up the COM with the default DecisionSystem processor since we only had a stub COM fighter. It picks random moves for now, which is pretty dangerous since there's like a 1/8 chance it'll instant-KO you. :P

Backgrounds, music, UI

Some various changes to Sensei regarding the UI, mainly just changing the debug font to the Sensei font. In this update, the Beach stage is in there (Catalina's stage) and the theme music plays on startup. Leaves fall in the background of the Dojo stage.

Various updates

I did some small modifications to the Character Select Screen just to make it work better. I also fixed a small bug in the process. Modeller (the fighter creator/animation program) now has support for defining an action point per motion. I wrote a basic effects engine for the fighting engine, which for now creates an impact sprite whenever a hit is landed.

First Sensei music

I really had no idea what kind of themed music Sensei would have so I went for an official orchestral sound, at least for the main theme; taking inspiration from the Soul Calibur soundtrack.

It is a slow piece, meant for the splash screens and menus. The battle music will be more upbeat.

Hopefully the piece will be received well. This one took about 3 hours to compose.

Character Select Screen

Has some more proper graphics in it and some of the logic was rewritten so it should handle all cases of all combinations and permutations of players now. :I

Minor website modification

The welcome page has some updated screenshots and the project's poster on there now:
http://jordan.trudgett.com/sensei/

Alternate spritesheets and new health bars

The title says it all. I've coded in/implemented alternate sprite sheet colours for the second player and the new health bars.

Final Poster Design

Click for a bigger size

Here is the design for our Project poster. The art is done by a good friend of mine as a commission.

Background class

I've now abstracted the background (area) into its own class so each arena can handle it's specialised drawing routine, whether it be animating water, falling leaves, rain, all that cool stuff. Later on once I've drawn and done all the backgrounds then I will go and paint them properly and animate them to make them come to life.

First things first though, I am going to be implementing the proper Health bar and then work on COM/AI stuff, which is about half done (the difficult half ;)) including the AI insight/readout panel.

Outlines, spritesheets, more work after 48

Just came back from Queensland on Monday night from the 48 Hour Game Making Challenge. We won the award "Best Graphics." I've been very busy these last couple of days just catching up on everything which is enough work as it is without taking out a massive weekend chunk out of it :P But despite that I've managed to get the other two characters' spritesheets in and wrote a function to generate outlines for the characters to draw in-game. I'll be doing more Sensei work today as well, starting with the Background class to handle the active backgrounds of each stage.

Poster Art Final Draft

Our external artist is making good progress on the poster art. This is the final draft before she does the inking.

New Character Select UI stuff I was working on.

And an update...

Small updates

I made a few changes to Modeller to make it more pleasant, I've put the Dojo in the background and so it almost does look like a preview of how it will look in-game. I made a couple small changes to Sensei and I put together the Takeshi spritesheet. I'm probably going to do the Character Select UI now.

AI and UI Demonstration

She learns from what I do, and quickly discovers a killer tactic.

New UI

Two quick pics to add for the UI stuff I've been doing lately, the two most changed screens are the Main Menu and the in-game battle screen. Other screens have had some slight changes including using the new Sensei font but otherwise haven't been changed too much.

Modifications to the main menu include using the
new Sensei font, and cleaning up the menu items.

The menu here is clean and simple to use.

The in-game interface (top) was made. The health bars
themselves are still temporary.

The in-game UI is shiny.

Poster art

An artist's first quick sketch of our project poster.

So I'm commissioning an artist to do our Trade Show poster so it can have the attention it needs as a poster while I'm busy with other project work. Here's a first look at the poster image that I asked her to design: the Sensei in the back with the three fighters in the front; Catalina with a jump kick on the side, Takeshi in the middle with a karate stance, and Ivanov on the other side "looking menacing."

More as it comes!

Ivanov

Ivanov's always tricky because his arm overlapping his chest is hard to distinguish. I've put in some gradient shading to make that apparent here which hopefully doesn't look too odd. Again I'll wait for Vince's approval for this one.

Catalina

And now Catalina has a face. Hmm..
Again no shading, just want to get Vince's green light on these characters, if he wants the body shapes changed I can easily do that at this stage.

More game artwork.

A quickly put together version of the
final Takeshi Oshiro in-game character

Hi again. I've started working on game art now, and since Vince wants his hands on the final character's models so he can get to animating, I'm going to be making them now. In the last hour I put together this guy. I'm following references from Vince for the character look. Right now there's hardly any shading (just where I couldn't help myself and got carried away cause it looked cool :P) just so we can have the actual limbs created and see if it's what Vince wants. He can start animating and all that while I'm doing the shading and details, it will seamlessly integrate after that, so long as the base shape is the same.

I've also decided that I want outlines to be drawn in-game, like above, which makes them look cooler :)

Modeller v 1.0

Modeller now supports changing a bone's sprite during a motion, which brings Modeller to it's fully functional capabilities, so it's version 1.0 now.

Website Update

I redid the front "welcome" page of the website and changed up a few things. The online versions of the Technical Documentation and Project Plan documents are also up to date.

Now I will probably have a short break then work on UI graphics.

Tech Doc update to reflect new AI changes

Yup, this morning after finishing my other assignments I updated the Sensei Technical Documentation to reflect the new AI changes I've made recently. That involved adding in a section here and there and removing some sections, changing a diagram and rewording some stuff. I also took out the Pseudocode section... I just don't think it's necessary if we have a Code Snippets section as well. I doubt anyone will miss it.

Next on the list is updating the website, then I will probably get into working on Modeller and game art.

More AI/DecisionSystem work

Today I did a fair bit of work making the AI and DecisionSystem behave more natural. The neural network now distinguishes between jump attacks and ground attacks. The DSState is now implemented to a decent degree so you can see the behaviour of the AI change depending on its mood. Blocking is more natural now, it doesn't just block as soon as you attack, it blocks when it thinks you might attack (pre-emptive!)

There are also a bunch of small changes and additions to Inferences and ShortTermMemory which were made so this could be done. It's getting there. :)

Today's work.

I did a fair bit on Sensei today, mainly between 4 and 9 pm. Here's what I did since the last post.

Worked on the neural network some more, improved the decision system in various ways, added a "global timer in use" warning (I want to abolish the use of these... they are error prone and ugly) and worked with Ryan on linking move information from the event manager with the decision system.

The new neural network system is working just fine. Next on my want-to-do list is making the AI act more human-like (sort of already started that, I've implemented blockAbility and delays between attacks) and fix up some UI stuff to make that more polished. It's lagging behind.

The New Neural Network.

After long deliberation, I have decided to revamp the AI's neural network implementation. There are a few main reasons:

• Our "neural network" was only really one by namesake. It was a rigid model that externally behaved like a neural network but had virtually nothing else in common.
• The Neural Network, Policies and Memories were getting a lot more complex than required and the maintenance required for those classes would become overwhelming.
• The "neural network" was limited in the sense that it wasn't terribly exciting to watch.

So... I thought long and hard about what I could do. And I had to really think about how all the AI components fitted together and how each had their own separate task.

Conclusion: I will be rewriting it from scratch. It sounds like a big task but actually I'm reducing the size of the problem by making it simpler and more effective. I will not be scrapping DecisionSystem -- which, if you recall, actually does most of the legwork currently (the AI-specific stuff was only very early stage.) But instead of the neural network competing with the DecisionSystem, vying for the authority to make decisions for the AI (which is, in this context, by and large a qualitative problem not a quantitative one) the neural network is going to be applied to the AI's fighting style and preference towards certain moves (out of a pool of the moves it knows.) I am also going to be implementing this artificial neural network in a closer-to-standard way with neurones and weighted dendrites but it will still be slightly unconventional in its usage.

I'm not sure if neural networks have been used in this way before. Maybe it's a hybrid... But in this way, the problem is made simpler for the neural network as analysis of the output with respect to the effect on the world is not necessary. Only forward inputs (from the world) are required, and weights are adjusted on the fly based on those inputs. The neurons themselves only need to work in one mode and there is no need to calculate error derivatives such as required in the back-propagation algorithm.

In a sense I'm downgrading the goals of the neural network to something that makes more sense and it should work seamlessly. I've already begun the coding and it's going smoothly.

Learning will still be apparent and should actually be easier to demonstrate. This is done through the KnowledgeBank class as well as the NeuralNetwork (they are tightly coupled.)

Our main goals for the AI are to provide a computer-controlled player that improves over time with direct relation to its experiences and I believe this system will achieve that to a greater level of success.

Multiple updates

So, where to begin? Haha. After merging Tech Doc information and updating that document as well as the Project Plan, I began to work more on the AI and DecisionSystem. I also quickly did up sound effects for the demonstration and we all put in a little effort to get it a bit more polished up for the demo.

Tonight I did a whole reel of bugfixes and improvements to multiple areas of the project from Bone Animation to screens to event management to the Fighting Engine. I added rumble to attacks. I also got the AI to block low moves as well as high moves, and some other stuff. Towards the end of the week (Thursday-Sunday) I will begin to work on AI learning but the focus for tonight was good demonstration material.

So, we have a working game more or less and two players can battle each other and have a match. :P

AI! Fighting Events! Demonstration!

So for the last few hours or so (time flies when you're making AI) I've been developing the AI and the DecisionSystem further. It still doesn't learn at all yet but it's getting there. Since we're doing a prototype demonstration this week, I'm going to have the AI running on defaults, stubs, and hardcoded hacks. It sounds bad but they're really just placeholders for the real deal -- learning, pattern recognition, skill proficiency, etc. Right now, as of the revision I just committed, the AI will block whenever it sees that it's under attack, and it will keep attacking you whenever it can. If it can't reach you, it will get close to you. So basically what we have here right now is a killing machine. Vince wanted me to commit it so he could try it out.

She's blocking my kick :( Click for full-view. :)

AI Brain and neural network.

Just a quick blog post before I rush off to my next class. Spend the last hour and a bit doing more AI stuff. More implementation of the neural network and further development on the policies and memories. At the moment there is a partially functioning policy system going on but there are no input memories so it isn't the full works and therefore doesn't do anything terribly exciting at present. However, it was interesting and so far everything's been going well and according to plan and the layers of abstraction all make sense. For example, well there are a lot of examples where the various pieces of the AI system are interdependent, but the brain is responsible for assigning costs to policy solutions. For example, who's to say that the diminishing distance between the two fighters is a positive result for the goal "GetCloser"? The brain (AIBrain) does that.

More later!

I did a fair bit of work on the Tech Doc today, after a few hours of LISP (CSCI337.) I decided to create the following diagram which shows how the information flows from the Event Manager through various stages during the Controller (AI/COM) and DecisionSystem classes. 

How information in the fighting world goes through different stages for the
DecisionSystem and AI/COM classes to process; and how these forms relate.

I also continued the implementation of the AI system; currently working on the neural network: policies, memories, and integrating it with the host (AI) class.

AI in-depth DFD

I needed to make this to make sure I didn't get lost in the AI system.

A more in-depth look at how the AI system works.

The fact that each one of these classes has a fair bit of work to do on its own it was a lot to keep in mind. But the abstraction is so far working great and I only have to think about what each little bit does at any one time, and as long as each part does what it's supposed to, it should all work ;P

AI Neural Network

So I've officially started the AI NeuralNetwork class. It all seems to make sense in my head based on the design of it but it will no doubt expand as we discover small cases where our needs redefine our designs. So far the NeuralNetwork is (meant to be) a container for the knowledge and memories of an AI brain. It also calculates and manipulates policies inside a PolicyMemory class which it uses to form the output. Essentially it is a wrapper around PolicyMemory since PolicyMemory just gives raw access to the neural network, it doesn't do any of the processing between the Brain and the data itself which is what the NeuralNetwork class will do (i.e. search for rules, filter, extract, update conditionally, etc.; all that ugly stuff we want to abstract.)

AI Reaction Time.

Turns out my hypothesis about AI reaction time in my post a few posts back works great. It took a few minutes to implement and test and it already makes the AI fighter look more natural.

Dojo parallax background

Took me about an hour and a half to paint up this dojo which is separated into 3 layers that scroll independently. The effect makes the scene a bit more natural and now we have a nice background to look at which isn't from Google Images.

UI tidying and some niceties

Here's a cool logo screen that's generated on-the-fly. You can watch it actually paint the logo.

I have more plans for this, either to go with that style and put it on a paper texture and make what you see here actually a stencil over a paint texture, and add some more stylish stuff (ink blots etc.) to make it more presentable, or do something else completely (like abstract lines that form into our logo or something?), but this will do for now. And there's no annoying JXEngine logo sound any more.. haha.

I also made the main menu neater with minor touches; also made the stage selection screen cooler and tidied up code for some of the screens.

I spent way too long on that logo, but it was fun writing a brush simulator right down to the ink viscosity on the varying-lengthed bristles. Probably could use help from a pre-made algorithm but if you know me I like to roll up stuff myself.

Other dummy characters modelled.

Vince and I worked together to bring the other two characters to life with dummy models. Catalina and Ivanov can now be tested and seen instead of just red Takeshi's. Vince did a great job of putting the skeletons together and making the basic animations we're using for now, in a flash. Most of the work I did for Sensei since last update was organising and tech doc stuff (it's in the agenda) but I also made the AI attack you just because I can. It'll be something nice to show Luke.

AI hitch?

Alright so splitting up all the AI/COM common code into its own class was successful. Very much so. However I have been spending a little bit of time on a little problem. "Reaction time". It is a harder problem than it first seems. I tried twice, and ended up with two side-effects (which I kept there in case we do find a use for them): observation latency emulation, and controller latency simulation. Neither of which is functionally equivalent to reaction time. Why? Reaction time is non-symmetric. Let me illustrate...

Imagine you are a racing car waiting for the green light. Reaction time affects how long after the green light you actually start moving. However, it does not affect how long after the finish line you hit the brakes! It only affects the initial event. Now the reason this is tricky is movement events are generated once per frame. If I just keep them in a buffer (queue) with an x second delay, we get the effect of the guy walking and continuing to walk even past his goal (controller latency.) If instead I keep the world states in a buffer (queue) with an x second delay, we end up with a similar situation, except that he doesn't "see" anything that happens until x seconds later, and he doesn't realise he has gotten to his destination, so he again, overshoots.

Now what is the solution? Buffering events for a certain amount of time would most definitely be the way to delay things. But what do we buffer? That is the question I am trying to answer now. One potential solution is to buffer the worldstate for everything except myself (i.e. my fighter's state.) That has the effect of creating a worldstate which has me in the present, and everything else x seconds (or frames, which may work better for practical purposes) in the past. That is an inconsistent worldview, but is that a problem? I mean we are trying to introduce imperfection!

The question remains whether such a worldview is logically equivalent to reaction time. After writing up all this, which has made me think about it more (different cases and what side-effects this kind of buffer would cause for the AI,) it seems like what we want.

Maybe I'm thinking too much into the reaction time parameter. Perhaps for more human-like AI behaviour I should start coding in some of the subtleties in a fighting strategy algorithm such as standing ground, etc.

More from me later!

Code Surgery

So while cutting code today for the AIBrain class I realised that what I was writing was actually code that is common to both COM and AI-- decision making, crunching goals and making inferences. So I've decided that I want to restructure this a bit and put that common code into its own class, possibly named DecisionSystem. The thought had come up a long time ago (eureka!) but was sort of left in the documentation to rot and I forgot about it. So anyway I've rediscovered it and will be working on it. From there, the AIBrain will use the DecisionSystem in addition to its own learning and understanding system (dynamic) to, ultimately, generate the fighter's instructions. The COM will use the DecisionSystem and convert goals directly (more or less) into actions (static) to achieve the same end. So my task ahead involves some code surgery, but it should leave the classes neat and well structured and of course mean that there's less work for me to do (code reuse is a great time-saver.)
I think this way of doing things is the most ideal considering that now the AIBrain can now just store the AI-specific stuff, and the decision system can store the short-term memory, inferences, and all that stuff which is generated on the fly.
More updates tonight when I've done that :)
Oh, and I'll need to be updating the technical documentation somewhat (perhaps change up the diagrams a bit) to reflect these changes as well as others. No worries though, it's all in the plan -- Week 7 -- updating Tech manual to reflect changes.

Weekend work

Today I did a lot of AI-based work, which involved methods in the AIBrain class for pulling information together, expanding the skeleton of the AI decision system and implementing simple brain goal and action management in the AI. Right now it doesn't do anything visibly different because the WorldState is not being filled by FightEngine and some RoundStates are not set properly; hence the AI is deaf and dumb. But it seems to work in theory (:

Also I drew the (temporary) spritesheets for the other two characters so we have some visuals to go on for the other two. They just need to be skeletonified and animated. I may leave that to Vince as he is the primary animator :)

Animation Blending

Motion Blending! And having fun over Skype while working on project :)

AI and COM progress

I've now implemented some more of the AI/COM structures as per the functional requirements. Two new structs were added, Personality and AIAttributes, to define the behaviour and identity of COM/AI opponents. I will now be working on building up the AI class and getting it into the game.

Animation Engine Goodies

Just working on the higher-level stuff in the Animation Engine. Since the fighting engine guys will be playing animations by their string name, there may be the case where they forgot or misspell an animation. So in a few minutes I put together a few more helper functions in the helper library, one of which is string Helpers.FindClosestString(string, IList<string). It uses the Levenshtein distance to find the closest string. When an animation isn't found by that specific name it throws a (usually) smart exception:

The animation 'eyerish jeeg' doesn't exist. Did you mean 'Irish Jig'?

Really loving LINQ stuff and other powerful tools like generics, lambda functions, etc.

Brand new Character Select Screen

As I said I would, I rewrote the core of the Character Select screen and now it works wonderfully with selectors and a SelectorManager...it functions just as you expect in all cases I've tried.

Progress, work and more work

Alright so I've just done 3 assignments in the last few days, and I've been fairly busy but I've still been keeping things up to date with the project, making sure everyone knows what they're doing and has a pretty good idea of the path they're on. I'll be rewriting the core of the Character Select Screen to better reflect the final version tonight, as well as working on the implementation of the user-friendly AnimationEngine functionality, so that the Fighting Engine devs can interface to it properly.

I still have a short list of TODO's for the Character Modeller but they can wait for now. I've got another assignment I need to make a few tweaks to then I'll be working on Project flat out. I've gotta do the two other placeholder character models this week and I might have a go at some music sampling.

COM stuff

I've put in some basic COM stuff after re-arranging the structure of the namespaces. AI/COM stuff is now under FightingEngine.AI. It makes more sense that way, why didn't I see it before? :) Right now the computer player just moves back and forth. It demonstrates that it is fully functional with the event manager right now.

Some placeholder art

Since I'm done on Modeller for a while now at least, I'm starting to work on the main Sensei project with the other guys. I put together some placeholder graphics for the character select screen so it can look and work a bit more like the final thing. I may put together a title screen and stuff like that a bit later on. I'm just about finished on my other assignments too.

Mildly busy week

Phew, it's been a bit busier than usual this week, with two other moderate sized assignments I'm working on and a "Celebrating Research" dinner I attended last night. I'm also marking assignments in CSCI356 which is sort of taking a bit out of me. I'm sort of done on the Modeller for now so I will be working with the other guys on the main Sensei project.

Dummy fighter in modeller

So I dismembered our little guinea pig fighter and put him in a spritesheet, created a character model for him in Modeller with appropriate skeleton and made a few quick test animations. With the sprites as they are at the moment, he is pretty much limited to that one fighting stance. But once we get multiple sprite-bone links in we should be able to mix and match different views of limbs to create the right perspective for that motion. It all looks pretty cool and it's always fun to see the fruits of your labour doing a little jig!

A dummy fighter.

I've drawn up a quick 10-minute sketch of a Japanese martial arts fighter, based on a stance of Ryu from Street Fighter. It's a bit hard to see everything so far since it's not coloured in but it's all drawn in separate layers to separate the body parts. Soon we should be able to have this dummy fighter in the game.

sort of based on the description of Takeshi Oshiro, however I will require
further direction from Vince as he is the primary character designer.

And here is the coloured version...

I'll pull him into the character modeller and have some fun soon :)

Modeller v0.9

A big update this time with plenty of lovely features, changes, and bugfixes. Firstly here's the changelog:


- 321 Modeller; v0.9
  * IMPLEMENTED: Sprite Rectangle deleting functionality
  * IMPLEMENTED: Bone renaming functionality
  * IMPLEMENTED: Bone ordering (i.e. draw order) functionality
  * IMPLEMENTED: "Looping" animation interpolation mode. Useful for motions which are
                 meant to be looped such as walking animations. In effect: does not grab
                 keyframes wrapped around from either end. In effect makes animations more
                 stable and loopable as you would expect.
  * IMPLEMENTED: Can select bones by clicking on them in the Bone List
  * MODIFICATION: New bones now have a number e.g. "New Bone 4" later will have
                  a name dialog box prompting for the new bone's name. (And a confirm
                  delete dialog box for deleting bones too.)
  * MODIFICATION: Brightness now goes from 20-100% in 20% steps (less clicking)
  * MODIFICATION: Changing motions now refreshes the skeleton, rewinds the motion
                  and pauses it if necessary
  * MODIFICATION: Scrubbing tools (play/pause/step etc) are now not accessible via
                  keyboard shortcuts in Skeleton Edit mode
  * MODIFICATION: Changed to an edited version of the Calibri font, which has some
                  arrow symbols in it and a pipe character edited for a cursor.
  * BUGFIX: Align tool didn't take sprite rotation alignment into account
  * BUGFIX: Translation didn't take into account parent rotation;
            and with this bugfix, all combinations of tranformations should
            work as expected now and all tools should work correctly
            (requires testing though)
  * BUGFIX: Scale/Size tools had a small bug in the calculation of angles which resulted
            in strange behaviour occasionally. Fixed now and always works as expected.

and a screenshot of course:

Modeller v0.9. Work that Calibri.

As far as I know, those were the last features before it was production-ready. There are still a few missing features that are not really necessary at this stage and some niceties which can be done which I will add in next week.

More modeller progress

Doo-be-doo-be-do, bet you can't guess what I'm still working on! Ding ding ding, Character Modeller program.

Some really sweet improvements in this upcoming version, the full details will be released with the release of the next version but a sneak peak:

• Motion parameters UI in info pane / can set motions to be "Loop" which affects how interpolation works on the start and end keyframes
• You can now click on bones from the bone list to select them. Sweet, a convenient way to switch between bones now. Although there is no way to rename bones in the application yet.
• Background brightness value is now in 20% increments.
• Alignment tool was fixed to take proper offsets into account. It was confusing to the user before if the sprite had been "AlignR"'d before "Align"'d.
• A latent but warmly welcomed bugfix in the bone chaining matrix multiplication algorithm now fixes certain combinations of transformations which had unexpected results. Now everything (translating, rotating, moving, scaling, sizing) works "as expected" in any combination. (More thorough testing required.)

Next on the list of improvements is being able to name and re-order bones (for Z-positioning) and then next big implementation is the previewing of combinations of motions.

Modeller progress

Have still been making adjustments and additions to the Modeller program. With the next big implemented feature it will be pushed to v0.8 but for now it is v0.7.21. There have since been some discovered minor bugs to be fixed in the next version.


- 321 Modeller; v0.7.21
  * IMPLEMENTED: "None" option for bonesprite
  * FEATURE: Bone/Sprite draw order can be swapped with checkbox
  * BUGFIX: Sprite Edit Rects weren't being resynced after loading character model file

Modeller v0.7.19

After playing around with it some more, discovered a few quirks here and there introduced with the sprite rendering algorithm. Fixed that up with a few other minor undesired features :p

- 321 Modeller; v0.7.19
  * MODIFICATION: Swapped Size/Scale button locations. Now buttons on top row will
                  mean local edit tools, bottom row will be global edit tools (affects
                  the bone globally, not just on that keyframe)
  * MODIFICATION: Motion listbox can no longer have nothing selected, which makes
                  little to no sense for the user (editing a 'scratch' motion)
  * BUGFIX: Move tool did not compensate for parent rotation
  * BUGFIX: Sprite translation alignment replaced with proper algorithm. Now affects
            rotation and scaling correctly.
  * BUGFIX: Global edit tools cannot be used in Edit Animations mode now.
  * BUGFIX: Loading a character did not set some motions variables properly

Modeller v0.7.13

Yay for features and bugfixes. I think I'm just about ready to attempt to make a proper dummy model from start to finish and see if everything's good. (If not, then coding that up takes priority.)

- 321 Modeller; v0.7.13

  * IMPLEMENTED: Background (subway)

  * FEATURE: Added tooltips to various new widgets.

  * FEATURE: Background brightness adjustment

  * BUGFIX: Checkboxes did not call Widget (parent's parent) update function

  * BUGFIX: Dialog boxes marked "active" by default (before being visible) which led

            to their widgets being active even though they weren't being drawn

Screenshot (click to enlarge)

Modeller v0.7.7

The remainder of the night working on Modeller. It is now theoretically possible to create a full animation set however I haven't done so yet :p I did make a smileyface though :)

- 321 Modeller; v0.7.7
  * IMPLEMENTED: Bone list view
  * IMPLEMENTED: Align sprite to bone tool
  * IMPLEMENTED: Change Sprite ID per bone
  * BUGFIX: Remove Motion when no motion selected caused crash

- 321 Modeller; v0.7.8
  * BUGFIX: Bone translation was not being affected by parent rotation

Modeller v0.7

Just been working away at the modeller program today. From the changelog:

- 321 Modeller; v0.7
  * IMPLEMENTED: "Rename Motion" functionality
  * IMPLEMENTED: Listbox UI widget (for motions list)
  * IMPLEMENTED: Add/Remove/Refresh motions list functionality
  * IMPLEMENTED: "View" checkboxes in UI (may add more later)
  * BUGFIX: Checkboxes now activate on mousedown instead of mouseup
  * FEATURE: Modified the colour scheme a bit to make it less depressing.
  * FEATURE: Status bar now has sundry information.
  * BUGFIX: Could use tools while slider was being dragged

Screenshot of Modeller v0.7

Another screenshot, here showing only the sprites. Bone list is also visible.

More on Modeller.

So I'm finally back on the Character Modeller since I have spare time. So far I've implemented a few things and fixed a few bugs. I'm working on getting this functional to a level where you can actually use it to create a decent animation. That means "remove keyframe" needs to actually do something, and a nifty little feature called "Frame Lock" now works too. It won't be long until I'm making a test subject in Modeller to make sure all the required features are there and working properly.

Modeller is now version 0.6.

Technical Doco Update

Today I got around to revising some sections of the tech doc to make it clearer so we were all on the same page with the classes. The fighting engine's event manager events needed clarification, as did the IController interface; and the Fighter, Human, AI classes needed to be documented entirely. I also added in documentation for various information-holding structs, such as ControlInstructions, and some state-information structs such as WorldState. All of this new documentation is basically related to the fighting engine, where most of the progress in the project is focused on at present.

Holiday mode

Alright so we're almost out of holiday mode-- which for us was pretty much work (part-time jobs, hobbies, other commitments etc.) and games...not much time for project work sadly, but we did have a good think about all the stuff we are working on and we're immediately back on track this week and straight into work (coding.)

More stuff as it happens, folks!

Holiday work

My work on the project has been mostly organisational during the holidays. I have been organising the project direction and holding meetings and discussions. Due to a multitude of other commitments and unforeseen circumstances, I haven't been able to work much on the Character editor but at this stage it is not slowing down any other aspect of the project, so we should still be able to move on at full speed.
My timetable for this session is looking fairly good, with one lecture/lab conflict (unfortunately.) We'll be having in-person meetings and work days very soon.

6/7/2011 Google Wave Meeting

Today we had a brief meeting on Google Wave discussing our plans and project progress. Vince was absent but since it is all recorded there he can easily catch up. We've just confirmed all our project duties and roles and are getting back into gear to get this show back on the road.

Minor update on the character modeller

Just a small update for the character modeller I'm working on, sprites are now linkable to bones and they draw. Next will be implementing the bone start/end positions to line up the sprite properly and sprite selection per bone...then we'll be able to create a little smiley face! There are a couple other things I want to implement shortly as well:

• Reording of draw order of bones so the sprites draw properly
• Being able to manipulate keyframes better, deleting keyframes, adding keyframes in different places, that sort of thing.

Modeller progress

Today I worked on the character modeller from home, starting to implement the sprite/spritesheet stuff in. I've so far got an interface set up that allows the user to define sprite rectangles:

Here's my test spritesheet which I will be using to make a smiley face and he will have some animations like bounce and roll.

Character Modeller

Did some more work on the character modeller in the last hour or so. The number of frames in the current animation can now be changed and a number of improvements have been made to the program in general, including implementing more keyboard shortcuts, removing bugs in some tools, etc. Here's a video of me mucking around in it.

Design, documenting, meeting up

Ryan and Vince popped around to the project lab for about an hour or so and we worked together on a couple of things. We discussed some of the more fine-grained details about the fighting move system, such as impact types, hit area categories, etc., while they were writing up the documentation for the Move structure. I wrote some small placeholders for these bits of information in Move.cs. I explained the relationships between the bone animation system, the character models and the moves since Vince wanted a clearer understanding of what exactly will be required (code-wise and content-wise.)

Apparently Adam is meant to show up some time soon. I'll stick around to say hi and get a bit of work done then probably head off at around 4:45 for food and go home.

More work in the project lab

So I've been here for about an hour. I installed Visio onto my computer here so we could edit and create UML diagrams. I've been sort of picking at the tech doc, adding things here and there and editing a few things. I also moved all the diagrams into their own sections, to keep things organised. I created a use case diagram to show the range of interactions between the player and the game system. I will also do one of the Character Modeller. Haven't touched code today, probably won't (until I get bored :P)

More stubs

Just spend the last hour or so writing up more stub functions in AI and Fighter, as well as setting up some more specialised datatypes. Building from the ground up here, or "top-down", I guess. I created a base abstract Controller class which the three fighter controller types (Human, AI, COM) inherit from in order to store some controller-common information such as which player (one or two) the controller is controlling. This sort of information needs to be made available to the decision-making processes of AI/COM to determine who is who in the world state information.

AI programming

Right now I'm in the project lab working on implementing stubs for AI data structures, specifically KnowledgeBank, MemoryBank and PolicyMemory. Putting together the building blocks of the AI engine is both exciting and a learning experience. I've always wanted to do a machine-learning system like this, hopefully it isn't too ambitious. Realistically, I know I can produce something. Something that functions. But I'm going to strive to achieve something really impressive.

Busyness

I've been busy lately, went down to Parramatta on Saturday for my dad's wedding, which involved going down on Friday and coming back Saturday arvo. Got a heap of assignments to mark as a tutor, 18 down, 24 to go. I am also doing an OpenGL assignment where we use shaders. So I'm squeezing in project into the gaps between real life, uni work and sleep :D Right now I'm just getting everything finalised and organised for our meetings over the next few days.

Artistic stuff

Frankly didn't think it would turn out this well. I'm happy. It says "Sensei" (in Kanji) and the signature is just made up (it resembles "CSCI321")

Guess it could be cool for some kind of logo or find some use in the user manual

More on tech manual

Alright so the tech manual now has a glossary (I got tired of wanting to explain things throughout the manual, so eureka!--the glossary was born.) as well as the initial writing version of the documentation for the currently known AI/COM data structures and types. Phew. It feels good getting it all down in technical terms because it affirms my knowledge in it and confirms that I know what I'm doing to some degree.

Now my focus is on updating the project plan so we have a clear path to follow next week.

Technical Manual / Project Plan

Right so it's week 10 now and we're pushing to keep on track (the timeline that we've set to push us to do enough work to theoretically have spare time towards the end (the "spare time" that will quickly be eaten up by unforeseen delays)) so we're working day and night squeezing in Project where possible. I've been pushing on the with AI / COM stuff, mucking around with some onionskin code (yes I just made that term up to mean a very thin outer layer of code with no substance to be used as a guide) and I'm going to fill out my sections of the tech manual sometime tonight as well. I added our formal project requirements (was a separate document) into the tech manual under Project Information. It's a good addition to the manual.

I'm also updating the Project Plan to designate specific tasks for the upcoming weeks and that'll be up shortly.

Coding <3

Okay, so for the sake of your sanity, it would be better to remain oblivious to this post's timestamp. Okay, thanks anyway.

For the last few hours I have been coding, thinking and stubbifying. I've been focusing on my area, the AI/COM fighter controllers, but they have required a bit of a base in other areas like the Fighter class itself so I've put some basic stuff in there too.

I've written large block comments for both the AI and COM fighter controllers to elaborate on specific requirements for the class. I find it is easier to garner real requirements while coding. So while I'm not actually implementing anything, I'm getting a good idea of how it's going to work anyway.

So, for AIData, which is a code library for information types common to AI and COM controllers, I've created the following structures: ShortTermMemory, Inferences and WorldState to add onto the existing data types and structures: ActionType, GoalType and Goal. Each serve a different purpose in the think/decide/do process on the AI/COM side of things.

I also created a GeneralData code library to hold useful constants and enumerated types such as Character (to distinguish between the playable characters) and a static function, CharacterName which gives the full name of a given Character.

In the AI's brain class, I had a good think about the implementation details of the neural network proposed. With the help of Dr. Wiki, I put down some comments about the technical nature of the decision making process:


At each point in time , the agent performs an action  and the environment generates an observation  and an instantaneous cost , according to some (usually unknown) dynamics. The aim is to discover a policy for selecting actions that minimizes some measure of a long-term cost; i.e., the expected cumulative cost.)


That's all fine and dandy, let's hope it isn't too much in the way of implementation. I also realised that the AI is going to need 4 different types of "memory banks"-- two long-term and two short-term. The two non-volatile memory banks are loaded from disk and the two volatile are created and updated on the fly.


That's all for now, signing off from your dear AlphaLogic leader --
Jordan