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.

Moving the crate

So I started building to today. The idea is to start with a sandbox level that can be used to test al of the game mechanics. I started in the crate that should have physics behavior but almost immediately ran into a problem.

You easily create a physics object by adding a static mesh as a Rigid body. A rigid body can be moved with the physics gun, or by shooting at it. The problem is that it can't be moved by walking at it. There also seem to be no settings in the object properties that changes that specific behavior.

Trying to look for a solution now.

Update

It's already two weeks ago since I posted my last update, and a lot had happened in the meantime. The mean problem was that I was losing focus, meanly because I was searching for a related research area that addresses a current design issue(s) or flaw(s) in current videogames. This search should result in a research subject that has more relevance to the industry. The only result I got was more pressure.

So i decided to change direction and I actually got back to my original approach which is the focus on learning mechanics. I also decided to leave the subject "Suspension of disbelief" untouched, meanly because it's to vague and hard to analyze. Though it is still probable that I will touch the subject in my thesis, but only at a superficial level.

So what now?

The most important step now is to start working on my prototype, which I intent to do in the following four to six weeks.

Oh yeah the prototype, wasn't that the half-life hazzard course.

Nop, not anymore. I decided to start building a game that has a little bit more originality to it. It's still in the save zone though, so don't expect any experimental gameplay. The concept is mainly focussed on mechanics that can be made/scripted in unreal kismet.

The goal of the game is to clear each room of its enemy's. The problem is that the player starts every room without a weapon. Enemies can be killed by crushing them with physics objects (crates) or by shooting them with a weapon from a fallen enemy. Figuring out how to kill the enemies is the puzzle element in the game and also offer me the opportunity to integrate a different learning elements

Main mechanics are:

- walking

- jumping

- pushing crates

- shooting

Weapons are

- physics (can be pushed a pun enemies)

- link gun (can be used to shoot at enemies)

- rocket launcher (can destroy specific walls)

I made a short animation that demonstrates the game mechanics. Note: The 2D camera viewpoint is used for demonstration purposes. It's probable that the final the final game will use another point of view.

604800 seconds delayed

I have to admit that blogging isn't my one of my strong points which should explain the lack of blog posts over the previous week.

So last week I had my meeting with my supervisor Karel Millenaar to present the prototypes that I produced over the last few weeks focussing mainly on the training course prototype that is shown in the video below.



Although progression within UDK seemed to be satisfactory, Karel advised me to take a step backwards to concentrate on my research outline, which I'm doing right now. The achieve a better aim to this I study need to stop wondering about and to start analysing.

This weeks goals:
- Gather relevant articles
- Do repertoire research / case studies
- Rough Supportive narrative outline + revised research questions

Prototype?

In my first post I stated the following:
"The idea is to replicate a small portion of a level from an existing FPS (First Person Shooter) that contains a single weapon pick-up".
I have a perfect weapon in mind that can be used for the encounter, namely the UDK rocket-launcher(which should explain this blogs name). And although I can come up with enough rocket launcher encounters form existing games, there is a problem. Almost all of these encounters go hand in hand with specific enemy AI behaviour that makes the encounter interesting/challenging. Replicating this AI is not only beyond by programming knowledge (for the moment), it's also not relevant for my research that is focussed on learning the mechanics. Challenge and engagement have a lower priority...for now. So had to come up with a new plan in which the standard UT_bot will suffice.

The new plan is to build a stand FPS training course that can be found in many older FPSes. Check out the following example from the original Half-Life made by Valve.



Note: Newer FPSes obviously also incorporate a training course into their design, the difference is that developers try to integrate the training into the first level(s) instead of cutting it loose from the rest of the game. Take Half-life 2 (the sequel to Half Life) for example.

I'll add a video here later.

As you see, the training course from the first video is quite long. And I'm not interested in all Half-Life's mechanics. It's especially the first part of the training that im interested in

Top Down Game

I just finished this top down game. The players goal is to collect all three keys and to run to finish afterwards. Like in my last post this game is based on tutorials by 3DBuzz. Doing al this series of tutorials should have thought me the ropes UDK and i think I have collected enough data on Kismet to make my own level encounters. So, this means that I'm finished with doing tutorials for now and will start the development of my own prototype ASAP.

UDK Update

Due to my busy schedule, I haven't been able to keep my blog up to date until now. Sorry guys.
So here's the update you have probably been waiting for.

The last few week a have been busy figuring out the ins and outs of the UDK (Unreal Developers Kit) by doing lots tutorials. And by lots I mean capital LOTS. I've been digging trough 30+ hours of video material and have also tried some written work.

Here is a video from the last prototype that I made, it's based on Matinee tutorials made by 3Dbuzz. The prototype is a small level with button that trigger a matinee sequence and spawns a bot afterwards. The bot can only be killed by a direct hit form the rocket launcher.



The Kismet script looks like this:












Today I'm continuing with the 3D Buzz tutorials, I've reached the 16th and final chapter, which is covering the creation of a simple top down game. This is my last day nosing trough tutorials and i plan to start working on my own level/prototype tomorrow. Ill keep you guys posted on the progression.

For those who are interested in working in UDK yourselfs check out the following references.
The best tutorial vids can be found on the video section of the main UDK page which are made by 3DBuzz. 3DBuzz is by far the best creator of tutorial and reference material, and has thought me many of the 3D skills I use at work today. So be sure to check out http://www.3dbuzz.com.
Another great source is Hourences made by the level designer of a just released game called "The Ball" (I still have to check out the game).
Eat3D also covers a great amount of the graphical pipeline of UDK.
And you should also check out Allar's Awesome Blog.

Here's a small tip: During the development of UDK many functions have been added/ changed or deleted, which can leave you stuck when following along the instruction You should always check the UDK version that it used in the tutorial material before you start building and build in the same version that is used.

Still stuck? Search the UDK forum or UDN blog or 3DBuzz and not forgetting Google.

Introduction

My name is Django den Boer, I’m 27 years old and I am a graduation student at the Utrecht School of Arts, Game Design and Development, Master Degree.
I’m currently employed at E-semble as 3D artist. And as you might guess, most of my free time is spent playing as much games, a good designer needs to know what’s out there. Of course I also have a social life, I own a house in which I live together with my girlfriend and have a rabbit that growls.

You might notice that this introduction sounds awfully familiar, which is true. Last year I started the Honest Sound Project (http://honestsound.blogspot.com) in collaboration with my classmate Tom van Kruijsbergen. Although the concept of the project was well received, it didn’t work out like we expected. In the end we decided to can the project and to start over, a good example of a kill your darlings moment. Looking back , the project was just too ambitious for the little amount of time that was available.

So what am I up two now?
My new project is called “Rocket Training” and is focused on teaching en learning mechanisms that are applied through level design. Tutorials basically. The project is split in two parts:

Supportive narrative
This document is a collection of learning methods that are analyzed through case studies and literature studies. The end result is meant to be sort of a guideline that can be applied by fellow game and level designers while they are building their tutorial levels.

Game Prototype
The idea is to replicate a small portion of a level from an existing FPS (First Person Shooter) that contains a single weapon pickup. In the course of the project I plan to alter the tutorial methods to be able to test my findings.
The prototype is going to be built in UDK(Unreal Developers Kit) and will probably be using the already onboard rocketlauncher.

The new project is meant to be a solo project and is considerately scaled down (compared to Honest Sound) to increase the prosperity of the project.

That’s all for now. More information will follow.