First prototype

I'm happy to announce that first playable prototype is finished. Al of the "must" mechanics are in place and are working.

Must
- level initialization v
- player spawn point v
- enemy spawn v
- enemy drops weapon when killed v
- level win state (door opens) v
- Rocket launcher spawn point v
- Rocket launcher destructible v

With Toms help, I also managed to add a system that lets the enemy bots patrol between multiple waypoints. The system only works with one bot now, should be compatible with multiple bots soon.



Note: The current prototypes function is to prove that the mechanics are operational en playable. There is no actual leveldesign yet.

To physics or not to physics

Yesterday I tried to figure out how to crush the player with a physics object but did not manage to find a way to cause or take any damage by this object type. I decided to choose the easy way out and fake it. If you cant make it, fake it. Right?



To fake a physics object I converted the box to a mover object and animated it falling in matinee. The animation is triggered by the use function (press "e" when in range). Luckily there is an event in kismet that can hit test a mover what makes it possible to add damage.
















I'm now trying to create a (kismet)script that traces the bots in a the level, zero bots should open the door to the next level.
The second option is to make the bots guard a key that opens the door to the next level.

Mock Exam coming up

Next Monday (13/12/10) is the Mock Exam which is a evaluation of my project. During the Mock I'm expected to present my research subject, my findings and my progression on my prototype/game. Unfortunately I lost some valuable time last week (see the last post) which means that crunching season is officially opened.

I plan to divide each day in two parts,
- morning/afternoon (9.30 - 16.00) Prototype building
- afternoon/everning (16.00 - 20.30) Writing Supportive narrative


Prototype

Although the physics behavior is not satisfactory yet, I can't permit to get stuck on one mechanic. This will week I build the other mechanics and ground rules first.

To build list (for this week, the build list for the final product has other priorities)

Must
- level initialization
- player spawn point
- enemy spawn
- enemy drops weapon when killed
- level win state (door opens)
- Rocket launcher spawn point
- Rocket launcher destructible

Should
- level lose state: player re-spawns and the level resets
- reset level function

Could
- Improved physics behavior
- UT double jump and dash mechanics disabled
- Rocket jump

Luckily I have build most of the must be mechanics before so that should rule out the possibility of a show stopper.


Supportive narrative

Although I have taken a lot of notes and did some writing the over the last period I didn't start writing my supportive narrative yet. I plan to use the layout of my old supportive narrative and will be rewriting it of course. This weeks writing should cover the introduction chapter and the first part of the first chapter. More details on that later this week.


Presentation

I will be making the presentation itself during the following weekend. I plan to make the presentation very visual and visual like a pecha kucha, although i don't intent to use a 20 second per slide time limit.
The presentation should include:
- an introduction to my research subject
- research question(s)
- current results
- prototype introduction
- prototype concept render movie
- prototype UDKdemo movie
- planning? (end date is still unknown)

That's all for now. I'll keep you guys posted.

Last week

Due to my broken central heating I had to stay home for several days be be able to open the door for the mechanic. Working at home wasn't really a possibility because of the cold (frozen hands and a mouse/keyboard don't really get along) so I lost some valuable time. What I did manage last week was to setup a working visual studio environment in visual studio 2010.

I also got the physics cube to work in such a way that it collides with the player so it can be moved now by walking against it. Unfortunately the physics behavior isn't satisfactory yet due to much bounce and because it rolls. I would a prefer a heavier cube that does not bounce and doesn't roll over. There crates in half-life 2 are a good example.

Hardware upgrade

My hardware request just got answered. Got a newer XPS now with a faster cpu and more powerful video cards. I also got an extra monitor waht can be a life saver in UDK.

The downside is that I need to reinstall all of my software again, including UDK, Visual Studio and nFringe.

Visual studio + nFringe

Last night I finally got nFringe to work properly. nFringe is an add-on for visual studio that allows the user to write, debug and compile unreal script. Most of the manuals are outdated what makes the installation so troublesome.

I also got to do a little scripting, nothing in depth though. Just an exercise to learn about the code structure.

Moving the crate (update)

UPDATE:

I just read on the UDK forum that it is possible to move the crate by adding a custom pawn class.

Since I don't have to much experience outside the UDK editor I'm trying to work through some tutorials that should help me to setup a good folder structure and to learn a bit of unreal script.

A notable problem is that a lot of the tutorials out there are based on early released UDK clients and a lot has changed since then.

Lets hope for the best.