Warscale 41 - Starwars, Startrek, space-time and Warscale
by Guimo · 05/30/2009 (7:25 am) · 5 comments
I love Starwars as any other fan and, completely against most people, I think the three prequels were quite cool. Of course they had their bad moments and of course there was Jar Jar Binks but all was forgiven on the scene where the young Jedis in the schools ask Anakin - What should we do? - and the answer from Anakin is just a lightsaber hummmm... best scene in the all the prequels IMHO.
But even when my desk at work is full of Star Wars minis (dont call them toys please... thats for kids), if I need to pledge allegiance, Id go for Startrek. Even when I havent been able to watch the original series other than one episode here and there, I have seen all the movies (Khaaaaaaaaan!!!), ST:TNG and Voyager (the doctor being my favourite character). So I was morally bound to go and see the new Startrek movie.
I was really impressed. I dont care what true fanatics say, JJ Abrahms has produced probably one of the best movies in the series. They wont have Ricardo Montalban but Eric bana made a convincing foe and Zack Quinto as Spock and Karl Urban as McCoy were amazing. Not to take any credit away from Chris Pine, Zoe Saldanha (Uhuuuuuuura... drooling) and the others. Even the ship makeover from what I could only compare... a 1950's Cadillac to a 1970's Mustang. You feel all improved but the manual things are still there. Personally, if I was to pick between the Starwars trilogy and this movie I would pick this one inmediatly. I even went to see it with a friend who had never ever seen Startrek at all and now he is trying to live long and prosper.
I just hope the producers dont get too excited and try to produce a movie where Picard has hair and Data was a toaster.
Anyway back to Warscale.
I have been workig the last three weeks trying to solve what I consider the last big piece of code of Warscale which is the event management. The problem is that even when the game is deterministic and the changes are applied in the game as soon as the messages arrive from the server, there are some actions which should take time to make efffect.
In a game like chess, events happen inmediatly. You move a piece and the piece is placed on its destination and the target, if any, is captured an removed from game. Almost all board games work this way.
In Warscale the problem is that actions take time. If you invoke a spell, the unit has to dance and throw particles and launch the fireball and the target receives damage and an explosion is shown and maybe the target dies with a slow and painful death. This choreography takes time to execute and unfortuately if in that time I get other message, then there may be a conflict and many things may happen... from just getting the wrong animation played to altering the event sequence which would be catasthrophic as the game relies on the precise action sequence.
I.E. a message comes telling a wizard has invoked a fireball which kills 3 goblins. The events are computed inmediatly but the wizard still needs to dance, then launch the fireball, then it explodes and kills the goblins. So I have a simultation which has already computed this while on screen it should still be playing the animations.
Now, say another event comes while the wizard is still dancing about a unit which is moving to the spot one of the goblins is standing right now. We need to apply this in the internal simulation and it works fine because in the internal simulation the goblins are already dead and out of the board. But in the visual portion the wizard is still dancing.
My solution was to apply the event to the simulation as soon as it is received and then queue the new events which originate on response to that event and play them. There were so many tricky parts which I was forced to solve which may take a really long time to explain. Let me say that the solution to this problem involved some heavi rewiring of many important components, the complete rewrite of my event manager which moved from a simple FIFO queue to a stack of queues where events are dependant between them and wont fire unless its parent events have been resolved. I also wrote an animation manager which is in charge of translating some mini programs which allow me to choreograph the special effects which occur on each event.
My design document for this part is about four page long and thats just a quick description of the cases. The point is that I managed to make this work and here is a small video with the action. It may not be obvious but the basics are there. The attacker will play an animation and it will fire the delivery method which is the bolt. The bolt hits the target and makes it play the damage animation and throw some blood particles all around. You may not be able to see the bolt due to the reduced resolution and the compression but its there, I swear (I think it appears in one frame in the third attack).
So now Im read for more interesting visuals. But right now I need to focus again in the equipment.
Oh and I forgot... the reason I was talking about sci-fi issues is that this blog, with the exception of the video was actually written before I finished the solution. How about that as a space time paradox?
What was planned
The avatar in numbers
I managed to implement the avatar as a mini view on the equipment editor. That means now you can see the avatar fully dressed or just switch to the numeric version to read its stats. I can guarantee this will be an excellent option for all those munchkins which love to see their stats increase.
Unfortunately this exercise became something really nasty after as I was forced to refactor a lot of code which was tested and working. Nore on this on the unplanned section of this blog.
Event synchronization
As I mentioned it was hard and took me a lot of time to complete. I was really afraid about this portion of the code.
What wasnt planned
Code refactoring
There are some times when you start feeling uncomfortable with a portion fo your code. In my case this happens when I find that Im doing almost the same thing in three (or more) different sections of my code and I have a function for each of those cases. The problem as you may know is that any change in the code will force a rewrite on all those extremely similar fuctions. Usually this is a situation which cries for a better solution and I may only suggest an inmediate refactoring. Even when it doesnt look that important, you will notice that even a little refactoring will clean many old code and even help improve other functions which relate to that code.
Im my case, I found I had similar variations in at least 5 points in the code: the army editor, the movement in the game, the attacks in the game, the area selection in the game, the mini view in the game and one more in the new numeric avatar view. All of them doing very similar calculations but with small variations.
So for my own sanity, I decided to refactor the code. I had to rewrite many classes and break a lot of code here and there and test everything again. On the end I finished with a core of functions which are reused in many different places and everything is easier to maintain. Funny enough I solved a couple of bugs and simplified other related functions in the process. Not bad.
Screenshot
I have showed a video just above. I think It would be nice to show you the avatar stats feature as it changes from the full view version.


The plan for this week
afxMagicMissile fixes
I need to make the afxMagicMissile to ignore any other unit except the target. This is a modification very specific to Warscale.
Mana in the user bar
The mana is no longer a unit attribute so it should be removed from the player mini view. It should be located in the player bar at the top of the screen during the game.
Icons for the user bar and creature cost
Im missing icons for units in hand, graveyard and mana. I need to make some and put them in the bar.
Add 7 weapons and 7 armors
Yes yes... I have been saying this for a long time and still nothing. But now I guess I have nothing else other than add more content and test the code.
Good luck with your projects!
Guimo
P.S. If we could find the programming language for women, game programmers would be kings!!!!
But even when my desk at work is full of Star Wars minis (dont call them toys please... thats for kids), if I need to pledge allegiance, Id go for Startrek. Even when I havent been able to watch the original series other than one episode here and there, I have seen all the movies (Khaaaaaaaaan!!!), ST:TNG and Voyager (the doctor being my favourite character). So I was morally bound to go and see the new Startrek movie.
I was really impressed. I dont care what true fanatics say, JJ Abrahms has produced probably one of the best movies in the series. They wont have Ricardo Montalban but Eric bana made a convincing foe and Zack Quinto as Spock and Karl Urban as McCoy were amazing. Not to take any credit away from Chris Pine, Zoe Saldanha (Uhuuuuuuura... drooling) and the others. Even the ship makeover from what I could only compare... a 1950's Cadillac to a 1970's Mustang. You feel all improved but the manual things are still there. Personally, if I was to pick between the Starwars trilogy and this movie I would pick this one inmediatly. I even went to see it with a friend who had never ever seen Startrek at all and now he is trying to live long and prosper.
I just hope the producers dont get too excited and try to produce a movie where Picard has hair and Data was a toaster.
Anyway back to Warscale.
I have been workig the last three weeks trying to solve what I consider the last big piece of code of Warscale which is the event management. The problem is that even when the game is deterministic and the changes are applied in the game as soon as the messages arrive from the server, there are some actions which should take time to make efffect.
In a game like chess, events happen inmediatly. You move a piece and the piece is placed on its destination and the target, if any, is captured an removed from game. Almost all board games work this way.
In Warscale the problem is that actions take time. If you invoke a spell, the unit has to dance and throw particles and launch the fireball and the target receives damage and an explosion is shown and maybe the target dies with a slow and painful death. This choreography takes time to execute and unfortuately if in that time I get other message, then there may be a conflict and many things may happen... from just getting the wrong animation played to altering the event sequence which would be catasthrophic as the game relies on the precise action sequence.
I.E. a message comes telling a wizard has invoked a fireball which kills 3 goblins. The events are computed inmediatly but the wizard still needs to dance, then launch the fireball, then it explodes and kills the goblins. So I have a simultation which has already computed this while on screen it should still be playing the animations.
Now, say another event comes while the wizard is still dancing about a unit which is moving to the spot one of the goblins is standing right now. We need to apply this in the internal simulation and it works fine because in the internal simulation the goblins are already dead and out of the board. But in the visual portion the wizard is still dancing.
My solution was to apply the event to the simulation as soon as it is received and then queue the new events which originate on response to that event and play them. There were so many tricky parts which I was forced to solve which may take a really long time to explain. Let me say that the solution to this problem involved some heavi rewiring of many important components, the complete rewrite of my event manager which moved from a simple FIFO queue to a stack of queues where events are dependant between them and wont fire unless its parent events have been resolved. I also wrote an animation manager which is in charge of translating some mini programs which allow me to choreograph the special effects which occur on each event.
My design document for this part is about four page long and thats just a quick description of the cases. The point is that I managed to make this work and here is a small video with the action. It may not be obvious but the basics are there. The attacker will play an animation and it will fire the delivery method which is the bolt. The bolt hits the target and makes it play the damage animation and throw some blood particles all around. You may not be able to see the bolt due to the reduced resolution and the compression but its there, I swear (I think it appears in one frame in the third attack).
So now Im read for more interesting visuals. But right now I need to focus again in the equipment.
Oh and I forgot... the reason I was talking about sci-fi issues is that this blog, with the exception of the video was actually written before I finished the solution. How about that as a space time paradox?
What was planned
The avatar in numbers
I managed to implement the avatar as a mini view on the equipment editor. That means now you can see the avatar fully dressed or just switch to the numeric version to read its stats. I can guarantee this will be an excellent option for all those munchkins which love to see their stats increase.
Unfortunately this exercise became something really nasty after as I was forced to refactor a lot of code which was tested and working. Nore on this on the unplanned section of this blog.
Event synchronization
As I mentioned it was hard and took me a lot of time to complete. I was really afraid about this portion of the code.
What wasnt planned
Code refactoring
There are some times when you start feeling uncomfortable with a portion fo your code. In my case this happens when I find that Im doing almost the same thing in three (or more) different sections of my code and I have a function for each of those cases. The problem as you may know is that any change in the code will force a rewrite on all those extremely similar fuctions. Usually this is a situation which cries for a better solution and I may only suggest an inmediate refactoring. Even when it doesnt look that important, you will notice that even a little refactoring will clean many old code and even help improve other functions which relate to that code.
Im my case, I found I had similar variations in at least 5 points in the code: the army editor, the movement in the game, the attacks in the game, the area selection in the game, the mini view in the game and one more in the new numeric avatar view. All of them doing very similar calculations but with small variations.
So for my own sanity, I decided to refactor the code. I had to rewrite many classes and break a lot of code here and there and test everything again. On the end I finished with a core of functions which are reused in many different places and everything is easier to maintain. Funny enough I solved a couple of bugs and simplified other related functions in the process. Not bad.
Screenshot
I have showed a video just above. I think It would be nice to show you the avatar stats feature as it changes from the full view version.
The plan for this week
afxMagicMissile fixes
I need to make the afxMagicMissile to ignore any other unit except the target. This is a modification very specific to Warscale.
Mana in the user bar
The mana is no longer a unit attribute so it should be removed from the player mini view. It should be located in the player bar at the top of the screen during the game.
Icons for the user bar and creature cost
Im missing icons for units in hand, graveyard and mana. I need to make some and put them in the bar.
Add 7 weapons and 7 armors
Yes yes... I have been saying this for a long time and still nothing. But now I guess I have nothing else other than add more content and test the code.
Good luck with your projects!
Guimo
P.S. If we could find the programming language for women, game programmers would be kings!!!!
#2
05/30/2009 (3:02 pm)
Cool video, blood is always cool though sometimes under done lol, love the gui but I would love to see the shot with out the gui blocking them hips! Woof! woof!
#3
Ketchup overkill looks rather good actually.
05/30/2009 (5:03 pm)
Second on Trekkies being weird ... though I love the original series, great arty, uber-melodramatic lightingKetchup overkill looks rather good actually.
#4
Being a non realistic game makes it easier to add extreme effects as this one. This effect is the insectoplasm slime/blood splatter with different free textures taken from the web. The events systems in Warscale uses small spells and combines them to form the complete animation. This way the splatter is shared along all the creatures without need of creating an AFX spell object for each case.
One modification over the default insectoplasm splatter is that I ranked the splat decals. So a larger creature will show mre decals in the ground making for a larger effect.
05/30/2009 (6:51 pm)
Thanks for the comments.Being a non realistic game makes it easier to add extreme effects as this one. This effect is the insectoplasm slime/blood splatter with different free textures taken from the web. The events systems in Warscale uses small spells and combines them to form the complete animation. This way the splatter is shared along all the creatures without need of creating an AFX spell object for each case.
One modification over the default insectoplasm splatter is that I ranked the splat decals. So a larger creature will show mre decals in the ground making for a larger effect.
#5
05/30/2009 (11:08 pm)
looks great. You need more blood! :) 
Associate Michael Hall
Distracted...
I like the blood splatter, it's ridiculously nice! Are you just slapping down decals in a radius or something a bit more involved?
Oh, and Trekkies creep me out ;) I once lived near an Army School of Music and just about everyone of those nerds, I mean fans, were "strange".