Further Development

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.

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.

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.

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.

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.

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.

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.

a Friend in Need...

Needs a tank indeed.

Welcome to my "add a tank to your generic room" tutorial.

now, im using my generic rooms as an example of how this is done, this is also the reason that my generic rooms have not been included in my "famous five" preliminary package, something i will talk about in more detail shortly.

This post will also include information on the creation of jump pads (something that, much like editing a tank into your level, would seem pointless, however, being able to edit a vehicle into a level then allows you to add in custom vehicles, allowing for, say, a boat whose basics are a modified manta, for example, but is slower and whose model rides lower, while also not being damaged by water volumes. in the same aspect a jump pad may seem entirely useless, as a jump pad at least, but in practice it can be used for more mundane elements.)

Now then, before any vehicles can be added to your map, you must redefine your map as a vehicle gametype map (for instance vehicle capture the flag. and as a note to those who are attempting to add vehicles into their famous five maps, the current framework for our mods will not support a vehicle map.) To do this, select "view" from the menu at the top, then select level properties, this should bring up a window similar to that which becomes active when you change properties for lights, emitters, and the like.

within this window is a section entitles "levelinfo" (as you should be able to see above.). In the above image i have already changed the defaultgametype to the vehicle capture the flag gametype (you will also notice that just calling it vehicle capture the flag won't work.). in case its too difficult to see on the image, the correct information to put into the DefaultGameType box is:

xGame.xVehicleCTFGame

(not this may also need to be entered into the PreCacheGame box, but i am unsure of that, try it without to begin with) Now, you can begin slapping vehicles into the game, first off, the tank!

Bring up the actor browser, you should be able to find the "pawn" actor class, open this, and then open the vehicle actor class. from here open up the sVehicle class(the ASvehicles are turrets, and the kvehicle (if you have such a thing) is the bulldog.), and then the onsVehicle dropdown. From here, you should be able to see a window like the one below.

Now, as you can probably see, ive opened up a few more classes. ONSTreadcraft is the parent class for the Tank-style vehicles, much like ONSChopper class is the parent for the Raptor, and other such vehicles. It is important to note that the vehicles in UT2004 ONLY get called by their propper names (goliath, raptor, cicada, SPMA, Hellbender, Manta, Scorpion, Paladin, Leviathan, Ion Tank) in the main game. in these actor classes they are given generic nmes, eg the Goliath Tank is called "ONSHoverTank" (and the ion tank is ONSHoverTank_IonPlasma).

Putting a Tank (or Ion Tank) into your level (after you've changed the levelinfo) is exactly the same as putting in a static mesh, weapon pickup, etc. just select ONSHoverTank(_IonPlasma if you really want to)from the actor window, right click on your terrain, and select "add ONSHoverTank here". when adding vehicles, typically a model for that vehicle will be shown in the editor, complete with skin, however in the case of the Goliath Tank, the skin is missing, and so is the upper turret section of the tank. (typically vehicles that have a "turret" section do not have the turret while in the editor, but the Goliath tank is the only case where it appears to have a null texture.) do not be alarmed by the null texture of your tank, in the main game, the texture will be there, as will the turret.

Now, ive moved ahead and cut a large hole out of the wall in one of my "generic" rooms, which now opens up into a large arena, as shown below.




as you can see by the top screen, ive already prepared this area to have a selection of vehicles in it (just for fun mainly), but, where are they? they are up...waaay up.

hmm, how can we get up there?

Jump pads, Thats how!

Jump Pads are Actors, but before we go into detail about setting them up, we want to make sure we can see the jump pads. (NOTE: you don' have to make a marker for them beforehand, but when you are testing your jump pads it does help, as jump pad actors are invisible in-game).

select any simple, flat(ish) static mesh you like, im not making you create a coherent level right now, just giving pointers. personally i went for the teleporter base (used in a variety of places, including onslaught).

now that the jump pad cues are in place (did you put one where you want to start AND where you want to finish? again you don't have to, but i did), open up the actor class browser. you should be able to see the Navigation Point class, open this up.

From here, it is important to note that Jump Pads have two parts, the pad itself, and where the pad sends you. Open up the jump pad and jumpdest dropdowns one level, to reveal UTJumpPad and JumpSpot (JumpSpot can be opened further, but thats not neccesary) same way as usual, add a UTJumpPad actor to where you want to the jump pad to start, and a JumpSpot actor to where you want the jump pad to send you.

(NOTE: this will not always be where you land, jump pads are a useful means of getting around the Z axis, but can also be used as catapaults to give you momentum, as UT characters can move in the sky, they can move out of the projected path, meaning that a jump pad could be meant to send you in one direction, but you end up somewhere entirely different.)

go to your Jump Spot actor, and open its properties. under the object heading, you should see a read only box called name, remember the contents of this box (typically JumpSpot0 for your first spot), open up the properties for your UTJumpPad, and in the Forced Paths box (found under the Navigation Point heading) enter the name of your jump spot into field 0, like so:

you can see a little purple line coming out of my jump pad actor, this is the jump path (which you will need to rebuild before you can see it.) to see it either rebuild all, or click on one of the build paths buttons just to the left of the rebuild all button.

and there you have it, you should now be ble to leap high into the sky and get to great heights.

The room...

Generic Rooms. What can i say? Generic rooms are boring. theres no room to develope your skills with any kind of editing programme, in this case UED. It was a simple task, create some filler rooms for a 3d visual recreation of Derby's Westfield Centre. one that could have been done in ten minutes, copied and pasted a hundred times, and been called done.

No. Wrong. Fail.

Our real Task was to get used to the unreal editor, use this opportunity to get some mapping knowledge, learn something new.

And so i did.

It was mentioned during tutorials that a Dead Rising style reimagining of the westfield centre would be a fun thing to do. and this did take over my minds view of what i should do for this task. A room of horrors, a room ON FIRE!

Below is my generic room (singular, i really didnt want to just make generic rooms). As you can see, its pretty basic. almost all of this room is made up of the same object copied a few times, nothing major, some basic lighting but i really only did this as a starting point.







It's not high quality, but i think you will agree that the one thing it IS is generic. In other words, Boring.





However, taking this room, adding items on the shelves, some falling off, some not exactly what you expect to see in a shop (including a new floor texture), adding a little lighting, and some special emitters gives you something entirely different.





It was no simple thing, mind you. up until this point i had not paid much thaught to how fire works in unreal. i had assumed it was an emitter (and i was right, miraculously), but i had no idea of how they worked, what they could "emit" or if they would produce their own light (in hindsight the lights i did use were a bit bright, but they illuminate the room better like this). But, as i had already set my mind to getting fire to work, i set about trying to teach myself.

That was a bad idea, while i could have figured it out on my own eventually, and i do mean eventually, there really wasn't time for that, and so i saught out my peers advice, which after much umming and utterances of the phrase "you...what?" i garnered the advice that i should look at the "Big Red Book", or Mastering Unreal: the art of level design, a book, that in my idocy i had left at home that day. while i did do more work in uni that day, i'll avoid leaping around map making topics, and stick to this right now. Mastering unreal (hence forth refferred to as the big red book, or "the brb" for short) is a truly wondrous resource, and within its finely example pages, i found what i was looking for, a tutorial on using emmitters.

Emitters can be used for many things, but for this instance (the creation of FIRE) i needed only one type of emitter, a sprite emitter. sprite emitters, simple speaking, create a sprite, or series thereof, that have their own velocity, acceleration (along a set of axis defined coordinates), lifespan, and multitude of other variables, though the ones above are what i am going to focus on. the llifespan is simple enough, its how long a given sprite that pops out of an emitter lasts, make the value lower, and the sprite will dissappear more swiftly, make the value higher, and you will have a big line of sprites which will drop your framerate...a lot. these sprites are essentially intangible, they will go through anything, which is useful (i placed my emitters inside of an object, causing a flame sprouting from an object rather than a flame floating a little bit above an object looking abjectly silly) but it can be a hindrance, at times my flames did rise through the cielling, or shelves, or at one point when i changed the values for acceleration incorrectly, through the whole room and out the door. Speaking of acceleration, it is important to not that acceleration is NOT the speed at which the sprite moves away from its origin, this is the velocity, acceleration is the direction in which the sprite accelerates.

once set up correctly, i have a fire, that moves with liquid pace directly upwards. An object on fire, yay. but theres no smoke, boo. It turns out, that each emitter actor can actually play host to any number of actual emitters, allowing a single emitter to produce both smoke and flame from the same starting point. the thory of producing smoke is generally the same as making fire, it just has to rise higher.

And there we have it, a brand new tool for use in level design learned, now what?

"How about a tank?"


Hmm...how about a tank indeed.

a subject for my next post.

An Unreal Expression

Design Document: Done
Schedule Version 2.0 (with risk plan this time) is in the works, and the newest "get to grips with the editor" task is in.

"In your groups, recreate a public area that you all know well using the unreal editor."

Our public area: the Derby Westfield Center

my Little Bit: Generic Shops.

because of the size, and general complexity of the Westfield centre (a shopping center) it was thought that building every shop to perfection would be an impossible task for the time allotted (a week), thus the task has fallen to me to design a collection of Generic shops, with the brief of "they're shops, what do you think?".

a brief i intend to follow. to the letter. What DO i think?...






aparently, not much.

the point is, while i can sit here and describe what a generic shop is, or what my view of that is (a large building, till's at one end, the rest filled with shelves/ showrooms of goods for sale), i can instead, show you the step by step process of creating a "generic shop".

that is subject matter for a post all of its own.

edit: instead of a step by step of generic room creation, i will skip ahead, and show how i have used simple use of emitters and meshes to create something new, something bright...something on fire.

The Design Document, and working with Unreal

I have never enjoyed working on documentation, I have always tried to impliment a more "hands on" approach. while I have read a few famous five books, and made notes on them, have come up with some game idea's that would tie directly into the stories, I have avoided writing up a design document as much as possible. however, time now grows short, and I have made a concerted effort to complete the document to a high standard, though I fear it may fall far short of expectations, a fear that manages to creep in and around all my work, I will confess.

I realise of course that my lack of previous experience with programming, and games design to go with it, do hamper my ability to complete some work to a satisfactory level, however experience cannot be blamed. During the first year I took too much of my time playing games, instead of making them. I did not manage my time well, and fear I am on the verge of repeating that pattern again this year. However I have begun to manage my time more readily, and am learning from my mistakes.

Unreal Editor is something I have worked with in the past, though not for any real purpose, mainly just for my own amusement, as such it took my attention more readily than the famous five books did, I have worked through most of the 3D buzz tutorials, and continue to work on improving my editor skills. As I have stated, the hands-on approach is my preference, as such the editor holds far more interest for me, but after johns lecture on friday, I realise that I should spend less time with it, and more on my documentation, and more academic learnings.

Specifics
I have learned how to use subtraction and addition in combination with builder brushes in the unreal editor to make more interesting level landscapes.
I have learned how to create and manage movers.
I have learned how to create windows using a panel builder brush, a transparent texture and a blocking volume.
I have learned how to place and manipulate static meshes.
I have learned the basics of lighting and texturing (aswell as how to place weapons pick ups, health and ammo pickups, and how to modify existing terrain. these things will all be useful when creating my famous five level)
I have done some research into the creation of a third person point and click interface for UT2004, which has yielded some results, but still needs much more research.


TODO
My design document (as of this time) has Not been finalised, though most of the elements of it are in place.
I have yet to create my 2d level design, but this is of high priority.

Introduction To My GDT blog

While this blog's primary audience is fellow university of derby students, and the university of derby Computer Games Programming module leader John Sear, i must also understand that this blog, or developement diary, can be used as part of my final portfolio. As such i feel it is imperitive to describe what this project is about before leaping headfirst into the meat of the matter.

The Project
The Project was assigned in late August of 2008, before the official start of the first semester of my second year at the university of derby. The task set before me (and the other games programming students) was to use the Unreal Engine 2 (through the medium of Unreal Tournament 2004, or UT2004 for short) to create a game based around the "Famous Five" franchise. this game was to be a total conversion for UT2004. The Game was set to be either a point and click adventure game, controlled with the mouse, or an action adventure game controlled primarily by the Xbox 360 pad. We were also informed that extra points may be awarded if we managed to get our games to work on a modified original Xbox.

The Projects are to be based on one of the original "Famous Five" books, utilising the chapter(s) within witch the main characters solve the mystery, find the treasure, or catch the bad guy. the guideline for length of gameplay was a ten minute, or "demo length" slice of a complete game.

Everything that would go into this Tend minute slice of game was to be created by the student working on it (unless existing textures, static meshes, or character models could be used and still seem to fit in). I will freely admit that this prospect, that of modelling, texturing, adding visual content to a project, rather than simply coding it, frightens me. i am not artfully minded, i can barely draw, my skill at colouring ends at "in the lines", and i have never modelled a character before. However, while the prospect does frighten me, it will also give me an opportunity to learn, and broaden my skills, that i might not otherwise get.

I will also freely confess to not ever having read any famous five books, and of having no personal interest to do so at that, my personal distaste for sexism and racism aside, these books were simply not written for those in their late teens and early twenties. Once again, however, i will admit that the simplicity and short length of these works of fiction allow for a much easier understanding of the subject matter, and, it is my hope, a more smooth transition from page to lcd monitor.