They way the animations were being implemented has been given a complete overhaul due to the discovery of some of the art tools available to us. I am aiming to have this done by the end of next week at the latest.
On a side note, the mortar is now broken which is annoying because I had it working a wee while ago. So that also needs to be fixed along with a few other bits and pieces.
Other than that, things are going well. Just gotta piece it all together next week so we can playtest and tweak it for gold.
Choice!!!!!!!!
Saturday, May 30, 2009
Friday, May 29, 2009
Michael Bastiaens -Friday 29th May
"Captains Log 29/5/09"
This week has been pretty hectic. Ive been working on a whole bunch of things from sounds to weapons. Ive made up a number of unique game sounds so far for the weapons and some of the destruction sounds and I am now waiting for some updates in the LUA scripts so I can add in some new sounds when the time is right.
Ive also spent a lot of time making corpses for all the enemies and have been exporting them out a number of times. On a more demoralizing note.... We have recently found out that ALL the assets need to be re-exported in the future due to a shader issue and how Maya deals with the Gamebryo shaders.... which brings me to my next point. Maya seems to hate Gamebryo when the hypershade is up. There is an incredibly annoying crash which tends to occur frequently when the hypershade is open. It crashes the UI in maya and until the issue is resolved it locks up all UI in all programs essentially disabling the right hand mouse button. If this ever happens to anyone simply close the hypershade in Maya and it should fix the problem. This error has only started happening since the computer was reformatted.
The last thing ive worked on this week is a new and improved rocket launcher projectile which has been rather uplifting considering all the annoying issues that have been occuring this week.
Ive gone with a kind of WW2 Shark head paint style on the missile (WIP Shown below) and along with the rotating fins and epic smoke trail its gonna look sweet az XD
-Michael
This week has been pretty hectic. Ive been working on a whole bunch of things from sounds to weapons. Ive made up a number of unique game sounds so far for the weapons and some of the destruction sounds and I am now waiting for some updates in the LUA scripts so I can add in some new sounds when the time is right.
Ive also spent a lot of time making corpses for all the enemies and have been exporting them out a number of times. On a more demoralizing note.... We have recently found out that ALL the assets need to be re-exported in the future due to a shader issue and how Maya deals with the Gamebryo shaders.... which brings me to my next point. Maya seems to hate Gamebryo when the hypershade is up. There is an incredibly annoying crash which tends to occur frequently when the hypershade is open. It crashes the UI in maya and until the issue is resolved it locks up all UI in all programs essentially disabling the right hand mouse button. If this ever happens to anyone simply close the hypershade in Maya and it should fix the problem. This error has only started happening since the computer was reformatted.
The last thing ive worked on this week is a new and improved rocket launcher projectile which has been rather uplifting considering all the annoying issues that have been occuring this week.
Ive gone with a kind of WW2 Shark head paint style on the missile (WIP Shown below) and along with the rotating fins and epic smoke trail its gonna look sweet az XD
-Michael
Thursday, May 28, 2009
Particles.....
Hello E!
So I have been working closely with an Artist trying to get all the games particles in and working as they have been described to work.
Gamebryo's Maya tools have proven to be horrible horrible when it comes to particles.
First we find we can't use all the particle options Maya gives normally after several failed exports. We later find in the docs in this tiny little piece in the middle of a page the options that are available in Maya to use.
We found some exports still didn't work with the apparently 'will work options' and it took a lot of trail and error before we could assitain what we could use.
The next issue we had was the sorting of the particles. They decided they wanted to draw over everything and anything. We found hidden in Maya some flags that could be set to allow for z testing and writing.
Then a new frame rendering system was implemented and the particles got shitted again! Now their alpha wouldn't work (stayed pink) and they wouldn't draw in front of any objects! Turns out they were being placed in a new root node that didn't have any an alpha accumulator set up on it properly and wasn't being updated correctly.
The next issue was that all the particle systems were Animating at the same time. Turns out a specific cloning process had to be adapted to allow for the time controllers to not be shared. The time controllers also needed to be set to app initialised so we could start and stop the particles when desired.
For a long time I was getting the time controllers out of the node hierarchy purely by chance, and when we started implementing a new particle system that system would not work. It took some time to realise the system could be opened in the asset viewer and the node properties could be viewed for what each node contained. Knowing the correct hierarchy now I could access all time controllers on all particle systems and work with them.
Turned out the particles could not be added to the scene and then removed and added again, they simply did not want to work second time around, something to do with gamebryo internal code. So I revamped the entire particle system so it was better designed to work with all we had learned and loaded each particle we would potentially use in the scene node first and simply moved to and off screen location and moved to the desired location we needed. This however is still and on going issue with reloading the game second time round because the particles get removed and re added to the scene node and still fail to work after a complete deinitialise and reinitialise of the game world.
Another error occurred where a particle was complaining off not having a colour value set, reset the colour value in Maya and re-exported until it worked. Not sure what the exact fix was but it works now...
After all these painstaking errors managed to get all the effects in and playing. Still need to change the way the game deinitialises and restarts so we can have particles on the second playthrough.
Managed to get particles to attach to other nodes in the scene graph so they follow them around.
Frame rate badly effects particles created with a vortex field, they go widely offtrack.
Managed to get looping effects working.
These are only the problems we have faced that I can remember, I'm sure there are plenty more and they have taken a massive chunk out of our development time to get working...
Screens of the particles to come later......
So I have been working closely with an Artist trying to get all the games particles in and working as they have been described to work.
Gamebryo's Maya tools have proven to be horrible horrible when it comes to particles.
First we find we can't use all the particle options Maya gives normally after several failed exports. We later find in the docs in this tiny little piece in the middle of a page the options that are available in Maya to use.
We found some exports still didn't work with the apparently 'will work options' and it took a lot of trail and error before we could assitain what we could use.
The next issue we had was the sorting of the particles. They decided they wanted to draw over everything and anything. We found hidden in Maya some flags that could be set to allow for z testing and writing.
Then a new frame rendering system was implemented and the particles got shitted again! Now their alpha wouldn't work (stayed pink) and they wouldn't draw in front of any objects! Turns out they were being placed in a new root node that didn't have any an alpha accumulator set up on it properly and wasn't being updated correctly.
The next issue was that all the particle systems were Animating at the same time. Turns out a specific cloning process had to be adapted to allow for the time controllers to not be shared. The time controllers also needed to be set to app initialised so we could start and stop the particles when desired.
For a long time I was getting the time controllers out of the node hierarchy purely by chance, and when we started implementing a new particle system that system would not work. It took some time to realise the system could be opened in the asset viewer and the node properties could be viewed for what each node contained. Knowing the correct hierarchy now I could access all time controllers on all particle systems and work with them.
Turned out the particles could not be added to the scene and then removed and added again, they simply did not want to work second time around, something to do with gamebryo internal code. So I revamped the entire particle system so it was better designed to work with all we had learned and loaded each particle we would potentially use in the scene node first and simply moved to and off screen location and moved to the desired location we needed. This however is still and on going issue with reloading the game second time round because the particles get removed and re added to the scene node and still fail to work after a complete deinitialise and reinitialise of the game world.
Another error occurred where a particle was complaining off not having a colour value set, reset the colour value in Maya and re-exported until it worked. Not sure what the exact fix was but it works now...
After all these painstaking errors managed to get all the effects in and playing. Still need to change the way the game deinitialises and restarts so we can have particles on the second playthrough.
Managed to get particles to attach to other nodes in the scene graph so they follow them around.
Frame rate badly effects particles created with a vortex field, they go widely offtrack.
Managed to get looping effects working.
These are only the problems we have faced that I can remember, I'm sure there are plenty more and they have taken a massive chunk out of our development time to get working...
Screens of the particles to come later......
Monday, May 25, 2009
Sunday, May 24, 2009
org hungry, org want eat
So recently we've got the particles working, which has been an absolute pain to SORT out, excuse the pun.
Our main issues were with gamebryo's depth sorting and lack of support for most of maya's nifty particle features (maya being our 3D package of choice). Then there were the little things, like particle systems syncing themselves to the same play time, particle life span and emitter animations; it will ALWAYS look weird when bullet impacts sync themselves together so they can play at the same time regardless of creation. And finally no animated textures, and when animated textures were implemented no syncing to the particle animation; everyone likes an animated billboard looking out of place in a animation right?
Thanks to some lifesaving shader work from Josh we fixed our depth sorting issues and implemented our sprite sheet animated textures. And thanks to Eli and the discovery of NiPSEmitParticlesCtlr (time controller) hidden way down the .nif hierarchy (close to Atlantis I'm sure) we managed to fix our syncing issues.
As for our limitations with Maya, well... In retrospect the use of Maya for particle system creation probably was not the best choice (as gamebryos particle support for 3DSMax is exceptional in comparison). A large amount of fields and features (especially ramps over particle lifespans) were greatly missed (although ramps are VERY expensive to calculate on the fly), but with a lot of planning we were able to escape with some acceptable results.
Although we will be using 3DSMax to get some effects (streak particles... not supported with Maya, but are in 3DSMax ~strange) and some of the outcomes of our effects are less than desirable in certain situations (billboard explosions fail in nooks and cranny's).
Next was the implementation of a day night sky dome. The approach to this was very similar to layered paper. Clouds can animate around a center pivot following a spherical path, while the sky dome (which in this case is a sky sphere ~fancy) rotates slowly across it's x axis continually; wallah a dynamic sky. The changes from day to night are handled by a interpolating texture, keeping 4 stages for gradual texture change (day -> dusk -> night -> dawn) textures can interpolate to gives an even MOAR dynamic sky (lovely ^_^)
this is roughly demonstrated in my notes above (the images detail a bit of thought process, pretty diagrams and such... and a few doodles)
Tweaking shaders to get desired results is something we got on top of and sat on recently. Characters especially were something quite frustrating to get right. The behaviour of the rim light was much too strong and was awkwardly lighting characters feet (which looks funky in a dark environment as the character literally floats). After a little head scratching with shader sliders the conclusion was to include a height gradient to kill the rim lights influence closer to the feet (this gives the illusion that character slowly emerge from the darkness rather then floating ~huzzah chutzpah).
Finally, Level of Detail meshes. Thankfully this isn't something that causes brainpain (TM), as some earlier prototyping and research cleared up the programmatic implementation and the artist pipeline. Gamebryos support for Maya LOD groups makes LODing assets... well... easy? However connecting LOD meshes for characters to BoneLODs is a little (a lot) less forgiving for pipeline execution and looks like it could eat a little time in the future (oh dear).
And appropriate exit based off of the introduction
"HALT I AM REPTAR"
Our main issues were with gamebryo's depth sorting and lack of support for most of maya's nifty particle features (maya being our 3D package of choice). Then there were the little things, like particle systems syncing themselves to the same play time, particle life span and emitter animations; it will ALWAYS look weird when bullet impacts sync themselves together so they can play at the same time regardless of creation. And finally no animated textures, and when animated textures were implemented no syncing to the particle animation; everyone likes an animated billboard looking out of place in a animation right?
Thanks to some lifesaving shader work from Josh we fixed our depth sorting issues and implemented our sprite sheet animated textures. And thanks to Eli and the discovery of NiPSEmitParticlesCtlr (time controller) hidden way down the .nif hierarchy (close to Atlantis I'm sure) we managed to fix our syncing issues.
As for our limitations with Maya, well... In retrospect the use of Maya for particle system creation probably was not the best choice (as gamebryos particle support for 3DSMax is exceptional in comparison). A large amount of fields and features (especially ramps over particle lifespans) were greatly missed (although ramps are VERY expensive to calculate on the fly), but with a lot of planning we were able to escape with some acceptable results.
Although we will be using 3DSMax to get some effects (streak particles... not supported with Maya, but are in 3DSMax ~strange) and some of the outcomes of our effects are less than desirable in certain situations (billboard explosions fail in nooks and cranny's).
Next was the implementation of a day night sky dome. The approach to this was very similar to layered paper. Clouds can animate around a center pivot following a spherical path, while the sky dome (which in this case is a sky sphere ~fancy) rotates slowly across it's x axis continually; wallah a dynamic sky. The changes from day to night are handled by a interpolating texture, keeping 4 stages for gradual texture change (day -> dusk -> night -> dawn) textures can interpolate to gives an even MOAR dynamic sky (lovely ^_^)
this is roughly demonstrated in my notes above (the images detail a bit of thought process, pretty diagrams and such... and a few doodles)
Tweaking shaders to get desired results is something we got on top of and sat on recently. Characters especially were something quite frustrating to get right. The behaviour of the rim light was much too strong and was awkwardly lighting characters feet (which looks funky in a dark environment as the character literally floats). After a little head scratching with shader sliders the conclusion was to include a height gradient to kill the rim lights influence closer to the feet (this gives the illusion that character slowly emerge from the darkness rather then floating ~huzzah chutzpah).
Finally, Level of Detail meshes. Thankfully this isn't something that causes brainpain (TM), as some earlier prototyping and research cleared up the programmatic implementation and the artist pipeline. Gamebryos support for Maya LOD groups makes LODing assets... well... easy? However connecting LOD meshes for characters to BoneLODs is a little (a lot) less forgiving for pipeline execution and looks like it could eat a little time in the future (oh dear).
And appropriate exit based off of the introduction
"HALT I AM REPTAR"
Friday, May 22, 2009
Michael Bastiaens -Friday 22nd May
"Captains Log 22/5/09"
This week I was chopping and changing between tasks which included working on the spawn marker, creating sounds, creating other new assets such as scavengable weapons and enemy corpses. I also did some more exports of the weapons as well so its been a pretty hectic week all up. Despite the numerous schedule changes I managing to keep on track on both sides of the schedule just in case we end up reverting to the previous schedule. In any case, next week ill be working on some more enemy corpses and then who knows at this stage XD. The following images are the scavengable weapons in the game which the player finds in order to research the corresponding weapons.
-Michael
This week I was chopping and changing between tasks which included working on the spawn marker, creating sounds, creating other new assets such as scavengable weapons and enemy corpses. I also did some more exports of the weapons as well so its been a pretty hectic week all up. Despite the numerous schedule changes I managing to keep on track on both sides of the schedule just in case we end up reverting to the previous schedule. In any case, next week ill be working on some more enemy corpses and then who knows at this stage XD. The following images are the scavengable weapons in the game which the player finds in order to research the corresponding weapons.
-Michael
Good Times
This week has been good times, i have finished all LOD for my assets, including the Shotgun, and have begun modelling a extra asset, with the possibilty of more extra assets on the way.
Also begun doing some testing of all assets in the level and wrote down any chrash errors and passed them onto the programmers.
Thursday, May 21, 2009
Tuesday, May 19, 2009
Tim Bewick - Week 19
I spent most of Week 19 working on tooltips that tell the player how to control their avatar when they first play the game. I made them so they only appear to tell you how to do something that the player has not done before. I also fixed the avatar's jumping and worked on the loading bar.
Monday, May 18, 2009
Whats left to do in 3 weeks.
Fortunately not that many tasks, unfortunately those that are left are giving us headaches. We finally got some networking going, just need to smooth out some of the animations and physics with our friend mister linear interpolation. Then tweak mother giving birth, AI path finding, a few animations, a few particles and fix a few bugs.
Its gonna be mean, the game is really fun.
Its gonna be mean, the game is really fun.
Art Update ! LOD
Some quick update ya'all :P here's the LOD for both Scientist and 1st Lieutenat, I just realised that I havent posted the 1st Lietenant so watch this space later. Cheers!
Friday, May 15, 2009
Man I'm Beta!
The team has just finished week two of a five week period before beta hand-in and the pressure is starting to mount. During this time, the main focus for the team has been to try and fix features that have been implemented so far as well as getting the gamer experience properly implemented.
My task has been the AI routing. This has given me a lot of trouble over the course of this project. The main challenge has been the fact that the environment is almost completely dynamic. I have been running into cases where the AI agents will almost always get stuck running to a waypoint because the path that it calculated has become invalidated. At the moment, AI agents are using a combination of pathfinding and steering behaviour. This kind of works but I still need fallbacks incase something wrong happens. Some suggestions have been given to me from peers, Darius, and Jon, our new GD Tutor and resident go-to guy. Here are the approaches that I will be trying over the next few days:
- Keep track of waypoints that have been successfully traversed. If the AI agent takes too long to get to its next waypoint, have it backtrack. Add a working memory fact that will change the cost of the edge that could not be traversed so that future AI agents will avoid going that way when pathfinding. Once the fact has expired, reset the edge cost back to the correct cost again. By setting a time limit on how long that edge cost can stay modified, it should stop the edge cost from being invalid for too long (NB: The time limit probably would not be needed if the environment was not dynamic....then again, the agents would probably not get stuck either).
- Place trigger areas around the map that could be problematic for simple pathfinding. If the agent gets into this area, have them perform some action to minimise the possibility of it getting stuck. For example, there are stairs in the area where agents tend to get stuck. I could place a trigger area at the bottom of the stairs that could make the agents jump to the top rather than just walk up it.
- Have designated areas in the map where AI agents can return to where they can easily get to certain areas in the level. If the agent gets stuck, have it try to get to one of these areas where it can begin its search again.
At the moment, I am leaning towards the first one. I'll be back with my progress in the next few days. Keep posted, later days.
My task has been the AI routing. This has given me a lot of trouble over the course of this project. The main challenge has been the fact that the environment is almost completely dynamic. I have been running into cases where the AI agents will almost always get stuck running to a waypoint because the path that it calculated has become invalidated. At the moment, AI agents are using a combination of pathfinding and steering behaviour. This kind of works but I still need fallbacks incase something wrong happens. Some suggestions have been given to me from peers, Darius, and Jon, our new GD Tutor and resident go-to guy. Here are the approaches that I will be trying over the next few days:
- Keep track of waypoints that have been successfully traversed. If the AI agent takes too long to get to its next waypoint, have it backtrack. Add a working memory fact that will change the cost of the edge that could not be traversed so that future AI agents will avoid going that way when pathfinding. Once the fact has expired, reset the edge cost back to the correct cost again. By setting a time limit on how long that edge cost can stay modified, it should stop the edge cost from being invalid for too long (NB: The time limit probably would not be needed if the environment was not dynamic....then again, the agents would probably not get stuck either).
- Place trigger areas around the map that could be problematic for simple pathfinding. If the agent gets into this area, have them perform some action to minimise the possibility of it getting stuck. For example, there are stairs in the area where agents tend to get stuck. I could place a trigger area at the bottom of the stairs that could make the agents jump to the top rather than just walk up it.
- Have designated areas in the map where AI agents can return to where they can easily get to certain areas in the level. If the agent gets stuck, have it try to get to one of these areas where it can begin its search again.
At the moment, I am leaning towards the first one. I'll be back with my progress in the next few days. Keep posted, later days.
Michael Bastiaens -Friday 15th May
"Captains Log 15/5/09"
This week ive been working on creating LOD groups for the enemies and their weapons and such. This process also included creating different resolution textures which was a relatively straightforward task. Once I finished this, I started working on improving the current sound library in order for me to start editing and creating new sounds next week. The last thing I worked on this week was a last minute request to create a new and improved spawn marker which has since taken up a higher priority and so I was working on the spawn marker for the better part of today. So the following are images of this weeks work and next week there should be a textured spawn marker and some new sounds which means that there wont be that many pictures next week. So until next week!
-Michael
This week ive been working on creating LOD groups for the enemies and their weapons and such. This process also included creating different resolution textures which was a relatively straightforward task. Once I finished this, I started working on improving the current sound library in order for me to start editing and creating new sounds next week. The last thing I worked on this week was a last minute request to create a new and improved spawn marker which has since taken up a higher priority and so I was working on the spawn marker for the better part of today. So the following are images of this weeks work and next week there should be a textured spawn marker and some new sounds which means that there wont be that many pictures next week. So until next week!
-Michael
Thursday, May 14, 2009
Jason Bunker
For the past several weeks i have been working on creating LOD versions of all my assets, all assests now have two levels of LOD, which are all ready to begin being exported.
I have also been building several test levels for programmers, and making changes to them at the programmers requests, which i enjoy because it gives me a chance to get some experiance with the Gamebryo Scene Viewer, but the asset viewer can get annoying.
Screenshot one is of the shotgun with three levels of LOD, the left is 1000 tri's and a 512x512 texture, LOD 2 is 500 tri's and 256x256 resolution texture, and LOD 3 is 25o tri's and a 128x128 resolution texture.
The second screenshot shows one of the quick levels i have created for programmers to test stuff.
Tuesday, May 12, 2009
Tim Bewick - Week 18
During week 18 I worked on tooltips, I added made the avatars use more of their animations, I made the avatar's character controller change its size when the avatar is crouching.
Friday, May 8, 2009
Michael Bastiaens -8th May 2009
"Captains Log 8/5/09"
Ive just been working on finishing off the weapons. So now they are textured and I set up the Level of Detail groups on the third person weapons as well. Next week ill be working on creating level of detail groups for the enemies.
-Michael
Ive just been working on finishing off the weapons. So now they are textured and I set up the Level of Detail groups on the third person weapons as well. Next week ill be working on creating level of detail groups for the enemies.
-Michael
Wednesday, May 6, 2009
Animator Entry
From the last post theres just been a lot of cleaning the rig and animated files, adding the new up-to-date meshes and tweaking the rigs to fit these changes. This has had some annoying additional work to be done, including adding bones to fingers to create a less "star fish shape" hand, as well as having to tweak the rigs in general...but oh well its all done now.
With that out of the way, there were a few more animations added including standing_idle, crouch_idle as well as some Endorphin animations done today.
Check them out here: http://www.youtube.com/watch?v=7B82QsxvPI0
Chur chur
With that out of the way, there were a few more animations added including standing_idle, crouch_idle as well as some Endorphin animations done today.
Check them out here: http://www.youtube.com/watch?v=7B82QsxvPI0
Chur chur
Tuesday, May 5, 2009
Beta Time
So its beta time and its coming along nicely. All features bar about 2 are present. very little has been cut and we are working on fleshing out the core game play experience better than it currently is.
Monday, May 4, 2009
Some Update!
Last week aside from finishing the Texture,Normal and Specular Map for both Scientist and 1st Lieutenant, I worked with Tim with some UI stuff including the loading screen and images of playable characters for the Character Selection Screen. I'll post some more later so watch this space :) Cheers!
Hello E!
On Friday was Alpha hand in and everything went really well, so off to celebrate for a drink! Tho we are not where we want to be at this stage I feel we can work hard and get a really good game out the door at the end of it all. At the moment our game runs really slow (1 frame/s!) with the actual level we want to use so profiling must be done and the slow parts of our program reworked. Since pre alpha milestone I have been working mostly on the game menus with a little bit of game logic tasks to do here and there. Sum screen of the current menus are below...
Subscribe to:
Posts (Atom)