This member has provided no bio about themself...

Report RSS Behind the scenes of a small level: Chapter four - Kismet (part 1)

Posted by on

Well, this chapter is gonna be tough.

First of all, here's the entire thing, I'm going to go through it in 3 different parts, which I color coded, and you can see it here.

The red bubble is what's going to happen at the very start of the game, the blue one is basically how the game works, like the key pickups, and the green blob is the last part, where you teleport to the 3 different places.

So... yeah, isolating the red blob we end up with this. Now let's dig into that.

As you can probably figure out by now, I like color coding :3, so that's exactly what I did, and you can see the result here.

Well, imagine kismet as little logic blocks (not the kid's toys, other kind of logic blocks). Everything has either an input or an output, and you connect those to make basic functions in your game.

You basically tell UDK: IF this happens, THEN that happens. For an example, IF you touch a trigger, THEN a light turns on. Here's the kismet version of this example. IF you touch an object called TriggerVolume_0, the game toggles on a light called PointLightToggleable_17.

I hope this brief summary is enough to understand the rest of this blog post, if not, I recommend you read the official Unreal Engine 3 Documentation on Kismet.

Now to my game.

Again, here's the part we're going to analyze today, and here's it color coded.

And here are images of all the smaller parts zoomed in:

RED
YELLOW
GREEN
BLUE
BLACK

Let's focus on the RED image.

Here it is, and also, color-coded.

As you can see, the condition is "Player Spawned" this means, that everything connected to that output is going to happen as soon as the player spawns. And there are 3 things connected to it.
The first one is the green path, which is a console command, the command inside it is "setSpeed 0.2", because Unreal Tournament uses ridiculously fast characters, and that would kill a horror game, so that's why as soon as the player spawns, the speed is lowered.

The red path is to turn UDK's default HUD off, because it wouldn't make sense to have it in my game.
Here's a screenshot with the HUD and here's one without.

Again, the HUD is turned off as soon as the player spawns.

The blue path disables all the player inputs (keyboard and mouse controls), and after 2 seconds, enable them back.

That isn't exactly necessary, but it's a nice touch to have just a black screen for 2 seconds before the lights turn on and you can move.

That concludes the red part, now to the green one! =D



Here's
the base image for it, and here's it color-coded.

As you can see, here the main condition is "Level loaded" this means, that everything connected to it will happen as soon as the level is loaded and visible. It's very similar to the Player Spawned, don't put too much though into this.

As you can see on the image's comments, this part turns off the light I was using for development and turns on the game's lights.

I had to do this because the game starts as a complete black screen for 2 seconds, as we saw on the red part, and I didn't want to develop the game with the 3d view in complete darkness, so I made a light so I could see what I was doing, and told the game to turn it off as soon as possible.

Well, the green path basically does that. Turns the light I was using off.

And the red path waits 2 seconds before turning the building's lights on.

And basically that was the green part, now to the blue!


Here's the base image, and here's it color-coded.

As you can see, here the condition is TriggerVolume_0 Touch.

What's TriggerVolume_0 you ask? Well, it's the blue-boxed trigger from the previous part!

This means that when the player touches that area, something happens.

And as you can see, two things happen =D

Also, please note, that here instead of using the delay block, there is a simple annotation, for example "Delay 0.50" at the end of some blocks. It works exactly the same as the other alternative, but you don't need as many blocks.

And the toggle boxes are smaller, well... they are the same boxes, but I hid the unused connectors, making them smaller, and easier to look at.

The red path toggles on a sound, waits 0.2 seconds and then turns it off. The sound is just a *click* from a light switch.

And at the same time, in the blue path turns off the main building lights (all three of them, as you can see), and then there is a sequence of toggles. That is your flashlight flickering.

As you can see, it turns on, waits 1 second, turns off, waits 0.10 seconds, turns on, waits 0.30 second, turns off, waits 0.50 seconds, and then turns on again, and stays on. Please ignore the last "Delay 1.0", it isn't connected to anything.

Now go back to "Behind the scenes of a small level: Chapter three - Game Logic" and read the 6th paragraph. You are gonna see this:

After you touch the blue-boxed trigger, the white-circled lights would turn off, making the blue-circled sound (which is very similar to this one: Youtube.com, and after 0.2 seconds, your flashlight would turn on and flicker a little bit.

Starting to see the connection between the two posts? Good.

As you can figure out by now, the white-circled lights are the office's lights and the blue-circled sound is the light switch

Now to the black part! =D


Here's the base image, and here's it color-coded.

The condition here is when you touch the TriggerVolume_3. And that is the green-boxed trigger from the last blog post.

Here there's only one path, but with one "trick" which is why I used a second color.

Ok, when the player touches the trigger, it will turn on a heartbeat sound, wait 0.2 seconds, turn it off, wait 0.10 seconds, then turn it back on, then wait 0.20 seconds and turn it off, then wait 1 second and start again. The blue path is basically looping everything.

It creates that cool *thump thump* ... *thump thump* from a sound file that is just a simple *thump*.


Aaaaannnndddd.... Finally, the last part... Yellow.

Here's the base image, and here's it color-coded.

As you can see I used 2 "Player Spawned" connectors, there is absolutely no reason for that. If I had used only 1, there would be the same result. It's all the same.

The red path is an "Attach to Actor" block. As you can see, "All Players" is the target, and a point light is the attachment. This means that that light will be following the player around.

The blue path is an "Give Inventory" block, and the inventory which is gonna be given to the player is an empty one. I had to do this because in UDK the player starts with an Unreal Tournament gun, which I didn't want in my game. So that block just cleared the inventory.

The green path is getting the player location, sending it to the white-circled variable (which is a vector, but that's for another tutorial) and then and sending the flashlight to that location. And then looping. That is basically the flashlight system. At each 0.001 seconds, UDK gets your location and teleports the flashlight to that location.


MOTHER OF GOD, this post is bigger than what I expected.

Well, there are 2 more parts remaining, and this one was the easier one, so... yeah.
Until next time.

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: