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.
Thursday, December 9, 2010
Tuesday, December 7, 2010
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.
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.
Monday, December 6, 2010
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.
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.
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.
Subscribe to:
Comments (Atom)