Warscale 40 - Handling weapons
by Guimo · 05/13/2009 (10:09 pm) · 9 comments
Hi all the 10000000E-8 followers of this blog.
This has been a very long week because, in fact, it has been too weeks since my last blog. I have tackled so many problems and even when some of them are almost unnoticeable the performance gains are significant.
I dont know if you have seen the fantastic (and extremely cheesy) movie Conan The Barbarian. There is a scene where Thulsa Doom tells Conan - What is the blade compared to the hand which wields it? - which in less esoteric terms would be read as... its not the sword which moves your hand but your hand who moves the sword.
Those words show that Thulsa Doom was indeed a cleric of incredible wisdom. Unfortunately it also says that Thulsa Doom was not a game programmer.
I must be honest and tell you that when I started programming Warscale the combat requirement was: When the creature attacks, play the attack animation. Period. No more considerations at all. That is... the same mental level than Conan.
Unfortunately in the game the weapon drives the character. If you hold a sword and a shield you will have a different stance than holding a spear, a hammer or a two handed sword. And the same applies to the attack animations, you have to carefully choose he proper one or suffer the comsequences.
And the worst part is that I really didnt noticed anything at all until this week when the avatar tried to crush a Dire bear using its crossbow as a mace. Of course the Dire Bear died because Im the programmer and my avatar is powerful enough to look good even when this kind of embarassing situations arise but Im quite sure he had the last laugh and I swear it somehow blended a smile animation along with the death animation.
So I had to fix this problem but it was fine because it forced me to tackle the movement which is one of the three largest portions of the game which is still underdeveloped which is the animation handling (the other being the sounds and the special effect handling). The result works great and may be nicely adapted for different creatures.
Other problems arised and were solved while trying to create a video to show the game progress. You can read the detail on that ahead.
Anyway, I think this was a nice long week and managed to complete my objectives and way more. Not bad at all.
If you have time and feel a little philosofical take a look at this funy reading:
What is the nature of happiness: civilized versus barbarian culture: Conan, Plato, and Epicurus
http://www.geocities.com/kd3qc/natureofhappiness.html
What was planned
Camera reset button
As per a suggestion I implemented a camera reset button so that it is easy to return to the default view after playing with the camera.
Fix a fix
There was a really bad lag hipcuc when I commanded the units to move. I thought it was due to a small fix I made on the AIPlayer code but in fact it was a problem with the bitmap buttons. I have some buttons on the lower right section and when the action changes new bitmaps were loaded for those buttons. This loading is synchronous and takes time so during this loading all the engine stalls. After loading the engine interpolates the missing time resulting on the the lag jump I noticed.
The solution was to create some additional buttons with the permanent actions of the game (move, run, attach, etc) which always have their bitmaps loaded and leave the mutable buttons for the special actions.
Updated AI
I managed to debug the AI. Im incuding a video of the current AI behaviour. If you notice the opponents usually run is because the function which analyzes the relative power levels and the actions to make is rudimentary at most but the point in this task was to lay the AI decision flow and not to do a deep tuning of the AI which will come later.
7 weapons, 7 armor
I was able to complete the 7 weapons but not the 7 armor. That 7 weapons provided with enough problems to solve and there are even more problems on the way to be solved before I continue.
What wasnt planned
Scale weapons on the fly
One of the things I like in Warscale is that the weapons are independent of the models. That means any unit may be attached a weapon at any mount point and it will gain all the abilities of the weapon (setting the ground for a Destroy equipment spell). The problem is that for this to look good I also need some way to manage the model size. I mean, I can use the same DTS to create a broadsword for a dwarf, a human or a frost giant but I need to dinamically change the model size to match the creature size. So I added an attribute to allow me to handle the scale of the weapon at run time.
Update the facing direction
I made this quick fix just to change the direction of the attacking creature so that it faces its target. This is just a quick fix as Im still evaluating the possibility to use a movement point for each 90 degree arc the unit needs to turn. But as always... KISS.
Search fix
I had to relax the search conditions in the editors so they are no longer case sensitive. That caused problems because looking for the keyword -shield- would skip completely any entry called -Shield-.
The weapon directs the attack animation
So, I was forced to fix the animation system. I was planning this task for the next week but I guess there is no better time than today. The game now supports multiple animation definition for each event so if the player has 5 hand to hand attack animations, I can pick one at random and play it then other and other. That keeps things more interesting.
Also, I can define an animation as an action, a thread or a single play thread so that I can blend animations.
This forced me to blend more portions of the MACK (the server side melee) over the AFX player object. I had some troubles because it seems the AFXs setLookOverride conflicts with MACKs playArmThreadOnce. On the end I dropped the look animation and just limited the viewing angle in the datablock for the units.
Model view in the game
The WSGuiObjectView is an amazing tool as it allows full control over the characters I want to show. The only problem is that switching from one model to other drops all the resources for the current model and loads the resources for the new one like the mesh, texture and animations. This is synchronous and takes time and it may get worse if the model has equipment which should be mounted.
In the game I had a single view object in the lower left which I had to use to show the models. Unfortunately the model can change quite frequently anytime the mouse hovers over a unit so it caused a lot of hipcucs and stalls.
The solution was to create a buffer of 10 views and manage them using a LFU algorithm. That way those views which have been used more frequently will be loaded and ready to display just by switching the view. If a unit which is not in one of the views is pointed, then the LFU view is updated with the model. This surely reduced loading time.
Reduce the number of Tile Effectrons
When the player selects an action, the game creates a list of possible destinations and then created a highlight tile effectron so show that point in the board. Unfortunately for areas which cover large portions of the terrain too many effectrons were created and the game became unresponsive. And thats now with a board of 11x11. Imagine how it was before when the board was 21x21! The solution was to optimize the point list so that it looks for groups of tiles. If there are 4 tiles forming a square, the game packs them in a single effectron which covers a 2x2 area. The result in my tests is an average decrease of 60% of the tiles which is enough to allow the application to stay fairly responsive.
Solve a problem with onReachDestination
This one was the hard one. I think I spent one full week trying to solve this one and its not completely solved yet. Some of you may have seen the problem when you plot a course for a unit and it needs to be near to the destination point to call the 'onReachDestination' callback. The problem comes sometimes when the unit is going just too fast, even the slowdown mechanism wont work because the player will start a crazy dance jumping from one side to the other of the point like its bound to it by an elastic band but never reaching a position where the speed reduction algorithm kicks in. Its a problem due to the discrete nature of the simulation.
Anyway, in warscale the problem got worse because sometimes I need to scale a unit so it reaches giant proportions, this in turn multiplies the running speed and I cant just reduce the speed or the large bear moves unnaturally slow. Worse yet, I dont like the way the slowdown is applied by default.
So, the solution was to create a callback called onProximityRange. This callback is extremely similar to onReachDestination but covers a larger area and it wont stop the movement when the unit gets into this area. The idea is to have an area which is considered relatively -near- the destination, like 3 to 6 units aways depending on the unit size. Then the callback is invoked and the script may take actions about letting the unit to follow its course of maybe taking the next point in the path. This turns into a more natural movement.
I still have a problem with large units behaving stange when attacking a target. They will stay on its position but will start to jump around. Maybe its related to the movement algorithm. I'm working on this.
Last minuteI Solved the strange movement behaviour. Looks like the getAIMove function in the AIPlayer uses the eye location for all its computations instead of the units position. Thi may have sense for people where the eye location is basically at the same vertical than the feet position. But in case of a quadruped like a bear, the eyes are ahead of the feet and that different causes the weird motion. Changing the line from eye.getPosition() to just getPosition() solved the problem.
Video!!!
Im so happy with the current progress that I decided to buy my license of FRAPS so I can record as much as I want. This is the video with the Avatar using some weapons.
The plan for this week
The avatar in numbers
I noticed the equipment editor allows me to see the avatar as it gets new items but I just cant see the total scores for it. That is, if I slowly add more and more magic items I will lose the count of how much it moves, how much mana it gains each round, its armor or its weapon damage. So I need a summary screen on the equipment editor which allows me to see the avatar as numbers.
Bloooooooood!!!!!!
I need to implement some damage for the weapons. I guess I will need to add some parental discresion and add some kind of control so that the particles look like blood or like water depending on the settings but right now they will look like blood, brains, green entrails, etc.
Projectiles
Right now the crossbows fire but no projectile comes out. This will force a better control of animations and the creation of simple projectiles which will be later used as the base for the spell system.
Optional: 4 more weapons, 4 more armors
Just 4 more of each one. I still need to finish setting up all the current weapons in the game.
I think this will keep me busy this week.
Luck with your projects!
Guimo
This has been a very long week because, in fact, it has been too weeks since my last blog. I have tackled so many problems and even when some of them are almost unnoticeable the performance gains are significant.
I dont know if you have seen the fantastic (and extremely cheesy) movie Conan The Barbarian. There is a scene where Thulsa Doom tells Conan - What is the blade compared to the hand which wields it? - which in less esoteric terms would be read as... its not the sword which moves your hand but your hand who moves the sword.
Those words show that Thulsa Doom was indeed a cleric of incredible wisdom. Unfortunately it also says that Thulsa Doom was not a game programmer.
I must be honest and tell you that when I started programming Warscale the combat requirement was: When the creature attacks, play the attack animation. Period. No more considerations at all. That is... the same mental level than Conan.
Unfortunately in the game the weapon drives the character. If you hold a sword and a shield you will have a different stance than holding a spear, a hammer or a two handed sword. And the same applies to the attack animations, you have to carefully choose he proper one or suffer the comsequences.
And the worst part is that I really didnt noticed anything at all until this week when the avatar tried to crush a Dire bear using its crossbow as a mace. Of course the Dire Bear died because Im the programmer and my avatar is powerful enough to look good even when this kind of embarassing situations arise but Im quite sure he had the last laugh and I swear it somehow blended a smile animation along with the death animation.
So I had to fix this problem but it was fine because it forced me to tackle the movement which is one of the three largest portions of the game which is still underdeveloped which is the animation handling (the other being the sounds and the special effect handling). The result works great and may be nicely adapted for different creatures.
Other problems arised and were solved while trying to create a video to show the game progress. You can read the detail on that ahead.
Anyway, I think this was a nice long week and managed to complete my objectives and way more. Not bad at all.
If you have time and feel a little philosofical take a look at this funy reading:
What is the nature of happiness: civilized versus barbarian culture: Conan, Plato, and Epicurus
http://www.geocities.com/kd3qc/natureofhappiness.html
What was planned
Camera reset button
As per a suggestion I implemented a camera reset button so that it is easy to return to the default view after playing with the camera.
Fix a fix
There was a really bad lag hipcuc when I commanded the units to move. I thought it was due to a small fix I made on the AIPlayer code but in fact it was a problem with the bitmap buttons. I have some buttons on the lower right section and when the action changes new bitmaps were loaded for those buttons. This loading is synchronous and takes time so during this loading all the engine stalls. After loading the engine interpolates the missing time resulting on the the lag jump I noticed.
The solution was to create some additional buttons with the permanent actions of the game (move, run, attach, etc) which always have their bitmaps loaded and leave the mutable buttons for the special actions.
Updated AI
I managed to debug the AI. Im incuding a video of the current AI behaviour. If you notice the opponents usually run is because the function which analyzes the relative power levels and the actions to make is rudimentary at most but the point in this task was to lay the AI decision flow and not to do a deep tuning of the AI which will come later.
7 weapons, 7 armor
I was able to complete the 7 weapons but not the 7 armor. That 7 weapons provided with enough problems to solve and there are even more problems on the way to be solved before I continue.
What wasnt planned
Scale weapons on the fly
One of the things I like in Warscale is that the weapons are independent of the models. That means any unit may be attached a weapon at any mount point and it will gain all the abilities of the weapon (setting the ground for a Destroy equipment spell). The problem is that for this to look good I also need some way to manage the model size. I mean, I can use the same DTS to create a broadsword for a dwarf, a human or a frost giant but I need to dinamically change the model size to match the creature size. So I added an attribute to allow me to handle the scale of the weapon at run time.
Update the facing direction
I made this quick fix just to change the direction of the attacking creature so that it faces its target. This is just a quick fix as Im still evaluating the possibility to use a movement point for each 90 degree arc the unit needs to turn. But as always... KISS.
Search fix
I had to relax the search conditions in the editors so they are no longer case sensitive. That caused problems because looking for the keyword -shield- would skip completely any entry called -Shield-.
The weapon directs the attack animation
So, I was forced to fix the animation system. I was planning this task for the next week but I guess there is no better time than today. The game now supports multiple animation definition for each event so if the player has 5 hand to hand attack animations, I can pick one at random and play it then other and other. That keeps things more interesting.
Also, I can define an animation as an action, a thread or a single play thread so that I can blend animations.
This forced me to blend more portions of the MACK (the server side melee) over the AFX player object. I had some troubles because it seems the AFXs setLookOverride conflicts with MACKs playArmThreadOnce. On the end I dropped the look animation and just limited the viewing angle in the datablock for the units.
Model view in the game
The WSGuiObjectView is an amazing tool as it allows full control over the characters I want to show. The only problem is that switching from one model to other drops all the resources for the current model and loads the resources for the new one like the mesh, texture and animations. This is synchronous and takes time and it may get worse if the model has equipment which should be mounted.
In the game I had a single view object in the lower left which I had to use to show the models. Unfortunately the model can change quite frequently anytime the mouse hovers over a unit so it caused a lot of hipcucs and stalls.
The solution was to create a buffer of 10 views and manage them using a LFU algorithm. That way those views which have been used more frequently will be loaded and ready to display just by switching the view. If a unit which is not in one of the views is pointed, then the LFU view is updated with the model. This surely reduced loading time.
Reduce the number of Tile Effectrons
When the player selects an action, the game creates a list of possible destinations and then created a highlight tile effectron so show that point in the board. Unfortunately for areas which cover large portions of the terrain too many effectrons were created and the game became unresponsive. And thats now with a board of 11x11. Imagine how it was before when the board was 21x21! The solution was to optimize the point list so that it looks for groups of tiles. If there are 4 tiles forming a square, the game packs them in a single effectron which covers a 2x2 area. The result in my tests is an average decrease of 60% of the tiles which is enough to allow the application to stay fairly responsive.
Solve a problem with onReachDestination
This one was the hard one. I think I spent one full week trying to solve this one and its not completely solved yet. Some of you may have seen the problem when you plot a course for a unit and it needs to be near to the destination point to call the 'onReachDestination' callback. The problem comes sometimes when the unit is going just too fast, even the slowdown mechanism wont work because the player will start a crazy dance jumping from one side to the other of the point like its bound to it by an elastic band but never reaching a position where the speed reduction algorithm kicks in. Its a problem due to the discrete nature of the simulation.
Anyway, in warscale the problem got worse because sometimes I need to scale a unit so it reaches giant proportions, this in turn multiplies the running speed and I cant just reduce the speed or the large bear moves unnaturally slow. Worse yet, I dont like the way the slowdown is applied by default.
So, the solution was to create a callback called onProximityRange. This callback is extremely similar to onReachDestination but covers a larger area and it wont stop the movement when the unit gets into this area. The idea is to have an area which is considered relatively -near- the destination, like 3 to 6 units aways depending on the unit size. Then the callback is invoked and the script may take actions about letting the unit to follow its course of maybe taking the next point in the path. This turns into a more natural movement.
I still have a problem with large units behaving stange when attacking a target. They will stay on its position but will start to jump around. Maybe its related to the movement algorithm. I'm working on this.
Last minuteI Solved the strange movement behaviour. Looks like the getAIMove function in the AIPlayer uses the eye location for all its computations instead of the units position. Thi may have sense for people where the eye location is basically at the same vertical than the feet position. But in case of a quadruped like a bear, the eyes are ahead of the feet and that different causes the weird motion. Changing the line from eye.getPosition() to just getPosition() solved the problem.
Video!!!
Im so happy with the current progress that I decided to buy my license of FRAPS so I can record as much as I want. This is the video with the Avatar using some weapons.
The plan for this week
The avatar in numbers
I noticed the equipment editor allows me to see the avatar as it gets new items but I just cant see the total scores for it. That is, if I slowly add more and more magic items I will lose the count of how much it moves, how much mana it gains each round, its armor or its weapon damage. So I need a summary screen on the equipment editor which allows me to see the avatar as numbers.
Bloooooooood!!!!!!
I need to implement some damage for the weapons. I guess I will need to add some parental discresion and add some kind of control so that the particles look like blood or like water depending on the settings but right now they will look like blood, brains, green entrails, etc.
Projectiles
Right now the crossbows fire but no projectile comes out. This will force a better control of animations and the creation of simple projectiles which will be later used as the base for the spell system.
Optional: 4 more weapons, 4 more armors
Just 4 more of each one. I still need to finish setting up all the current weapons in the game.
I think this will keep me busy this week.
Luck with your projects!
Guimo
#2
Scaling the weapons to fit any sized character/creature seems a good idea, thus pooling models and textures. Saving both on asset creating time but also on extra texture memory.
And I love the original Conan film.
You got a typo under "Upadted AI": should be analyzes.
And you've reminded me that I forgot to license FRAPS yesterday, when I was licensing a load of fonts.
05/13/2009 (10:46 pm)
Looking good in the video! Good animation. It looks like your models have "injured" anims when they've been hit. It'd be nice to sync them with the attack animations, maybe a wait-till-attack-anim-played-then-defender-play-wounded-anim.Scaling the weapons to fit any sized character/creature seems a good idea, thus pooling models and textures. Saving both on asset creating time but also on extra texture memory.
And I love the original Conan film.
You got a typo under "Upadted AI": should be analyzes.
And you've reminded me that I forgot to license FRAPS yesterday, when I was licensing a load of fonts.
#3
Its possible that the animation sync problem will be hacked this week while I solve the projectile firing.
05/13/2009 (11:06 pm)
Hahahahaahahahaah... fixed... I dont want to harm any feelings (or any other body parts) with my typos.Its possible that the animation sync problem will be hacked this week while I solve the projectile firing.
#4
Enjoyed the link to "the nature of happiness" by the way -- definitely a different (ligthearted) take on classical philosophy.
05/14/2009 (4:16 am)
Cool video. Sounds like things are really coming along.Enjoyed the link to "the nature of happiness" by the way -- definitely a different (ligthearted) take on classical philosophy.
#5
05/14/2009 (11:04 am)
i love reading/watching your dev blogs! you've come a long way. keep it up! 
#7
05/15/2009 (7:12 pm)
I love your menu and character inventory system, Guimo. It's appealing to the eye and I want it :P
#8
05/16/2009 (12:19 am)
If you can provide me with some of your fantastic models I can provide you with work to build a character system. Send me a mail if interested guimo at spritekin dot com
#9
05/16/2009 (7:55 am)
I'll be in contact soon, Guimo ;)
Torque Owner Guimo