My intention is to continue development on this project after the initial project end date. However due to time constraints i may not be able to continue with the project.
If/When i do continue Development i will continue to update this blog, unfortunately i may not be able to host the mod here on this blog for fear that students down the line may wish to plagiarise.
Thursday 18 December 2008
CSD Talk
CSD talk has become the bane of my existence over the past few weeks. It is a wonderful system, truly a work of genious, but it has many holes and flaws. to begin with, understanding its inner workings takes a bit of practice, the interface is confusing, and the documentation for it is sparse at best.
but the main flaw i have discovered, one that appears to be somewhat subjective, is that whenever i create an event that is activated by CSD talk it becomes impossible to accurately save the conversation features into a level, because of this i have had to include the CSDTalk.ini in a system folder to be installed directly into ut2004. this problem also means that the talk trees activated by CSD talk can only be accessed in build+Test mode.
While this is a limiting feature, i feel that it is still workable.
The talk trees have proven versatile, and while i have avoided using passkeys, i feel that the results i've gotten from the other features makes for an effective system.
but the main flaw i have discovered, one that appears to be somewhat subjective, is that whenever i create an event that is activated by CSD talk it becomes impossible to accurately save the conversation features into a level, because of this i have had to include the CSDTalk.ini in a system folder to be installed directly into ut2004. this problem also means that the talk trees activated by CSD talk can only be accessed in build+Test mode.
While this is a limiting feature, i feel that it is still workable.
The talk trees have proven versatile, and while i have avoided using passkeys, i feel that the results i've gotten from the other features makes for an effective system.
Matinee
Matinee, Unreal's build in cinematics generator is a wonderful thing, and relatively simple. i used the Mastering Unreal vooks tutorial to generate the cinematics within my game.
Matinee sequences consist of several different parts.
first, the scene manager, without this the cinemati can't be run, the scene manager stores the order in which the interpolation points are moved through, the actions that take place, and the subactions assigned to those actions. this is what makes amatinee work.
secondly, interpolation points. interpolation points form the paths that the camera will "fly" along. the settings for these interpolation points allow you to change how long it takes to move between the points, and whether or not the camera snaps to the path between those points, or moves smoothley along them. actions are assigned with these interpolation points.
subactions are assigned per action, in my experience all subactions you need to execute can be added to the first interpolation point only. this may not be the best way to do things but it is the quickest , and has been more accurate.
subactions allow you to fade in or out of view, shake the camera, overlay an image on top of the camera, etc.
in my game i have used subactions to overlay and fade the camera view, but in the standard UT2004 intro sequence there is camera shake.
Matinee sequences consist of several different parts.
first, the scene manager, without this the cinemati can't be run, the scene manager stores the order in which the interpolation points are moved through, the actions that take place, and the subactions assigned to those actions. this is what makes amatinee work.
secondly, interpolation points. interpolation points form the paths that the camera will "fly" along. the settings for these interpolation points allow you to change how long it takes to move between the points, and whether or not the camera snaps to the path between those points, or moves smoothley along them. actions are assigned with these interpolation points.
subactions are assigned per action, in my experience all subactions you need to execute can be added to the first interpolation point only. this may not be the best way to do things but it is the quickest , and has been more accurate.
subactions allow you to fade in or out of view, shake the camera, overlay an image on top of the camera, etc.
in my game i have used subactions to overlay and fade the camera view, but in the standard UT2004 intro sequence there is camera shake.
Mapping a Forest
Mapping a Forest was an interesting experience. there were some choices that i had to make regarding accuracy and time. i knew i would have to create a large amount of bot paths within the forest, to constitute a stealth challenge. Having shortcuts in the forest was something else i needed.
once again the forest is made out of terrain and static meshes, no building within the level. the trees in this mans forest are made of static meshes, and there are a lot of them. i had a choice between creating a lot of trees to form a real forest, or creating a deco layer where the trees would form the decoration, and creating blocking volumes to make them solid. i chose the former because Static meshes would not impact performance due to occlusion, and would look far more "real". lighting and composition make this level out to be night time, so causing cricket noises gives it an air of life.
Time however, makes fool of us all, creating a forest using static meshes takes time, time placing them, time makingsure there is space between them forming a path, and no space between the ones forming a solid wall. Placing rocks is far simpler than placing trees. Rocks are solid, compact, and have a definitive shape, trees on the other hand have leaves. leaves make placement of trees difficult, as they block the view of where the body of the tree is. in the end i decided that duplicating a series of "tree tunnels" and repositioning the trees manually after placement would be the best way to populate the forest.
once again the forest is made out of terrain and static meshes, no building within the level. the trees in this mans forest are made of static meshes, and there are a lot of them. i had a choice between creating a lot of trees to form a real forest, or creating a deco layer where the trees would form the decoration, and creating blocking volumes to make them solid. i chose the former because Static meshes would not impact performance due to occlusion, and would look far more "real". lighting and composition make this level out to be night time, so causing cricket noises gives it an air of life.
Time however, makes fool of us all, creating a forest using static meshes takes time, time placing them, time makingsure there is space between them forming a path, and no space between the ones forming a solid wall. Placing rocks is far simpler than placing trees. Rocks are solid, compact, and have a definitive shape, trees on the other hand have leaves. leaves make placement of trees difficult, as they block the view of where the body of the tree is. in the end i decided that duplicating a series of "tree tunnels" and repositioning the trees manually after placement would be the best way to populate the forest.
Mapping a Beach
Beaches are made by Water (usually the ocean) eroding cliffs, or soil banks, or even erosion of river beds, over time. the erosion causes granules of eroded stone to gather, leading to either sandy or pebbley areas.
so, by that logic, a beach requires 3 things, a water source (in this case the ocean), and source of material (in this case cliffs) and either sand or pebbles (or a mix of course, but in this case sand).
Often in games real geography is ignored in favour of smoother gameplay. and of course, like all good games designers, i chose gameplay over geographical correctness. my beach is made out of the unreal engines standard terrain editor, with a large body of water (which causes FPS problems), and some static meshes to for cliffs and collections of rocks.
My Terrain has no Deco Layers, and only has layers of texture for sand, sparse mossy stone, and stone. the mossy stone is for colour, the stone is for bedrock and the sand is for...well...sand.
The cliffs and stones are actually the same static mesh, showing the versatility of scaling and orientation.
The challenge in this level is going to be to find a number of pickups, so i decided to build a chamber under the terrain, simple to make the task a little more entertaining. the chamber consists of a simple room, and creating an opening in the terrain simply means making certain poly's of the terrain invisible. the problem with this technique is that the poly's of a terrain can take up more space than the entrance you are trying to erase, so i patched the holes with various stone static meshes.
so, by that logic, a beach requires 3 things, a water source (in this case the ocean), and source of material (in this case cliffs) and either sand or pebbles (or a mix of course, but in this case sand).
Often in games real geography is ignored in favour of smoother gameplay. and of course, like all good games designers, i chose gameplay over geographical correctness. my beach is made out of the unreal engines standard terrain editor, with a large body of water (which causes FPS problems), and some static meshes to for cliffs and collections of rocks.
My Terrain has no Deco Layers, and only has layers of texture for sand, sparse mossy stone, and stone. the mossy stone is for colour, the stone is for bedrock and the sand is for...well...sand.
The cliffs and stones are actually the same static mesh, showing the versatility of scaling and orientation.
The challenge in this level is going to be to find a number of pickups, so i decided to build a chamber under the terrain, simple to make the task a little more entertaining. the chamber consists of a simple room, and creating an opening in the terrain simply means making certain poly's of the terrain invisible. the problem with this technique is that the poly's of a terrain can take up more space than the entrance you are trying to erase, so i patched the holes with various stone static meshes.
Friday 21 November 2008
The Design Doc (redux)
Players perspective on the gameplay demo:
the player (begining playing as the male character Dick) will enter the beach level, and be greeted by a non-player character (Julian) who will proceed to teach the player how to move (in a sarcastic way, eg: "what is it dick? have you forgotten how to move? imagine a little joystick in your brain, on the left side of a little white blob or something, push it foreward to put one foot in front of the other. pushing a little green button in your head lets you talk to me.") julian will then run a little bit foreward and shout (or wave, or dance or pelvic thrust should i be unable to egenerate or find a suitable animation) to grab the players attention, prompting the player to continue, the tutorial continues in this manner as julian declares that he has hidden Dicks trophies (how he got them all and hid them all without the players knowledge is beyond the players frame of knowledge) and then challenges the player to finding them (with a few hints, by the stones, sharp landmarks or caves etc), this forms the basis for a tutorial.
i am hopeful that after this i can include a stealth challenge, wher an "enemy" will be stood turning around and the player has to hide behind rocks to avoid notice, this will form the next chllenge.
following this, the player talks to one of the others in the five, and (with a little matinee help) the story moves on. the next section involves following a figure through the dark while avoiding notice, and picking up the figures "trail" as you go.
the player (begining playing as the male character Dick) will enter the beach level, and be greeted by a non-player character (Julian) who will proceed to teach the player how to move (in a sarcastic way, eg: "what is it dick? have you forgotten how to move? imagine a little joystick in your brain, on the left side of a little white blob or something, push it foreward to put one foot in front of the other. pushing a little green button in your head lets you talk to me.") julian will then run a little bit foreward and shout (or wave, or dance or pelvic thrust should i be unable to egenerate or find a suitable animation) to grab the players attention, prompting the player to continue, the tutorial continues in this manner as julian declares that he has hidden Dicks trophies (how he got them all and hid them all without the players knowledge is beyond the players frame of knowledge) and then challenges the player to finding them (with a few hints, by the stones, sharp landmarks or caves etc), this forms the basis for a tutorial.
i am hopeful that after this i can include a stealth challenge, wher an "enemy" will be stood turning around and the player has to hide behind rocks to avoid notice, this will form the next chllenge.
following this, the player talks to one of the others in the five, and (with a little matinee help) the story moves on. the next section involves following a figure through the dark while avoiding notice, and picking up the figures "trail" as you go.
Wednesday 5 November 2008
Trophies in the water...
While my eventual idea for a famous five game involves only one, very small, miniscule in fact, use of a pickup, its important to utilise the time, and tasks, given to you to learn all there is to learn that could be relevant.
and so, not only am i making pickups, i also made a giant cube of water floating in the sky...
the giant cube of water is simple enough, its just an enormous floating water volume (and because unreal geometry and volume systems are not affected even a tiny little bit by gravity, it won't fall on our heads) after placement of that we come to having six fluid surface info's, each one dominating the side of the cube.
why do you ask? because i wanted to experiment with timings for drowning, how a character can be affected within water without dying, and the effects of fog in water.
now, pickups by themselves are simple. and therefore boring. what i wanted to do was instead take the idea of "hey you, go collect this stuff for me and i'll give you something of equal value etc" and put a spin on it. in many rpg games there are "collect" missions (go get blah me give you X) but they always seem to assume you can go and grab all of whatever it is your grabbing and keep it stored safely on your person. Instead i want my character to have to be given a bag, or some other item, which will then allow them to carry the collectibles.
the solution to this turned out to be incredibly simple, but it is a testament to how confusing UScript is that such a simple solution can evade someone for so long.
i started with an existing experimental class (to save a bit of time, and i wasn't using the original anyway) originally this pickup would allow the character to activate a lift. (or it was supposed to anyway). now however the crystal would serve as the players bag, so removing the unneccesary code i put in a simple bool variable, so that when the pickup was picked up the bool would be set to true.
Originally i had tried a convoluted route to getting this bool to allow you to pick up my simple pickup, trying to get through my examplepawn class, however a much simpler solution presented itself (after a bit of pushing and shoving from my lecturer John), a straight line. so simple, so elegant, but i hadn't thaught it would work that way.
unreal foiled me again.
and so, not only am i making pickups, i also made a giant cube of water floating in the sky...
the giant cube of water is simple enough, its just an enormous floating water volume (and because unreal geometry and volume systems are not affected even a tiny little bit by gravity, it won't fall on our heads) after placement of that we come to having six fluid surface info's, each one dominating the side of the cube.
why do you ask? because i wanted to experiment with timings for drowning, how a character can be affected within water without dying, and the effects of fog in water.
now, pickups by themselves are simple. and therefore boring. what i wanted to do was instead take the idea of "hey you, go collect this stuff for me and i'll give you something of equal value etc" and put a spin on it. in many rpg games there are "collect" missions (go get blah me give you X) but they always seem to assume you can go and grab all of whatever it is your grabbing and keep it stored safely on your person. Instead i want my character to have to be given a bag, or some other item, which will then allow them to carry the collectibles.
the solution to this turned out to be incredibly simple, but it is a testament to how confusing UScript is that such a simple solution can evade someone for so long.
i started with an existing experimental class (to save a bit of time, and i wasn't using the original anyway) originally this pickup would allow the character to activate a lift. (or it was supposed to anyway). now however the crystal would serve as the players bag, so removing the unneccesary code i put in a simple bool variable, so that when the pickup was picked up the bool would be set to true.
Originally i had tried a convoluted route to getting this bool to allow you to pick up my simple pickup, trying to get through my examplepawn class, however a much simpler solution presented itself (after a bit of pushing and shoving from my lecturer John), a straight line. so simple, so elegant, but i hadn't thaught it would work that way.
unreal foiled me again.
Subscribe to:
Posts (Atom)