| UltraKill | Дата: Thursday, 04.04.2013, 16:54 | Сообщение # 1 |
 Main Developer.
Группа: ADMINISTRATOR
Сообщений: 59
Репутация: 665
Статус: Offline
| Hey guys!
So as some of you are aware I've been developing a Story gametype for Killing Floor. It dawned on me that there's currently no documentation on how to actually use this mode in a map. So i'm here to shed a little light on that  Please note - this is not an unreal mapping tutorial. I am assuming that if you are reading this you already understand the basics of using the editor and putting a level together (bsp, playerstarts, etc)
Things you'll need :
1. The StoryMode code/content. you can find the latest version in this thread. Extract it to your root KillingFloor folder.
2. You'll need to modify your KillingFloor.ini file to get it to load the story scripts in the editor. To do this, open up the afformentioned file and scroll to the 'editPackages' section (beneath Editor.EditorEngine) You should add an entry for KFStoryGame. it would look like so :
Code:
EditPackages=KFStoryGame
Last step would be to delete your 'User.ini' file (after making sure the DefUser.ini from the StoryMode zip file is in your system folder. This will enable key-binds necessary for story mode.
Done all that? Alright! You're now ready to start story mapping! 
The main components of a story mission
Story mission gameplay is built using several different actors to create a web of conditions and events that can tell the game when to spawn enemies, open doors, save player progress, and so on . The main actors you will be using in your missions are as follows :
- KF_StoryCheckPointVolume
- KF_StoryZombieVolume
- KF_StoryObjective
- KF_LevelRules_Story
KF_StoryObjective
This is the most important component of a story mission as it defines what a player's goals are and what is required of him to complete the mission (or fail it). Every story map should have at least one of these actors. You can find them in the actor browser under 'navigation point'
KF_LevelRules_Story
This actor defines some broad gameplay rules in your map . Things like the maximum number of zombies that are allowed at once... or the amount of cash players lose when they die. Every map should have ONE of these actors, no more.
KF_StoryCheckPointVolume
This volume is used to save players progress as they work their way through the mission. If they die, they will respawn from the last activated checkpoint, and the game state will reset itself to closely resemble what it was at the time that checkpoint was reached. Most story maps will have multiple checkpoints. Note that it is possible to stack checkpoint volumes on top of one another, if you want to save progress without having players actually move through the level. More on that later.
KF_StoryZombieVolume
This one should be fairly self explanatory. It is a modified version of the default 'ZombieVolume' used in the Vanilla KF Game mode, with additional features to give level designers control over when and how zombies should spawn.
Creating a Simple Mission
Now that I've covered the boring stuff, i'm going to skip right ahead to practical application of these actors. We're going to be putting together a simple map with a type of gameplay quite similar to the regular KF survival GameType. The twist is - As you defeat specimens new areas of the map will unlock and you will have to progress through each area to the final one before you can win.
Let's get started
 This is the map you will be making
This tutorial map is very simple. it is 3 long corridors separated by doors. Players spawn at one end and progress to the other end. The doors unlock as each 'wave' is completed. All of which is triggered by the Objectives you will be placing.
The very first step in making a story map should be to place a starting checkpoint. You must ensure that there is at least one playerstart inside any checkpoint you place or it will not function correctly. In my example, I have added six (because it is the KF max player count).
Next you need to adjust a few properties. in the 'StoryCheckPoint' rollout, set 'bStartEnabled' to true , and then give the checkpoint a name. bStartEnabled means that when the match begins your team will spawn at one of the playerstarts inside the checkpoint volume. If your team dies, it will restart from that spot. Each story map should only have *one* checkpoint marked bStartEnabled, otherwise the game will get confused about where to place you.
The next step is to add a levelRules actor. Story maps require these to work correctly. You can find this actor here :Code:
Info-->LevelGameRules-->KFSPLevelInfo---->KFLevelRules_Story
The level rules actor has a bunch of cool properties, but the most important one by far is the 'Objectives' tab. Open that one up and you will see an empty array. This is where you will be setting up a list of all the objectives in your map and the order they must be completed in. An Objective at index 0 is to be completed before an objective and index 1, for example.
This map will have seven objectives. They should proceed in a similar order to what I show in the above screenshot, with a wave timer followed by a wave, followed by a progression into the next area.
So let's take a look at the very first objective in that list - 'WaitForWave1'
The first thing you will notice is that there are *alot* of properties in objective actors. Don't worry about it. 90% of them won't apply to the objective you are making. I have highlighted the key ones in Red. ObjectiveName is important because this is how the LevelRules actor identifies it and puts it in the Objective que. Whatever you enter for 'ObjectiveName' *must* match what you put in the LevelRules , or it won't work.
The next important property would be the 'SuccessCondition'. This is what determines how this objective must be completed. For our 'WaitForWave1' objective, it's nothing too complex - We just want abit of time to pass before the first wave begins, so we set the Success condition to OBJ_Timed, and the duration to 10 seconds (in the OBJ_Timed rollout).
Next, note the 'SuccessAction'. This is what tells the game what should happen when this objective has been completed. The default behavior is to just proceed to the next objective on the level rules list. We'll leave that unchanged because the next objective is the first specimen wave, and we want it to start immediately once the time is up.
Finally, there is the 'HUD' rollout. This is not crucial, but it provides the player with some idea of what the objective is all about, so it would be a good idea to fill it in. Here's how I set mine up :
So after all that, here's how the first objective would look when we start the mission up.
Alright, so that's it for the timer - But now we need to figure out how to spawn some zombies and start the 'wave' for real.
To do this, we first need to place a KF_StoryZombieVolume.
Again, lots of properties here. By default any zombie volume you place will just spit out zombies automatically. to prevent this, you need to set 'bTimerStartsDisabled' so that it can be activated at an opportune time. The 'SpawnTypes' array controls the type of ZED this volume spits out, and the chance of it being one type of ZED or another. I won't get into that in too much detail ... suffice it to say, you need *something* in there for the volume to spawn.
Next , take a look at the 'Tag' and 'ZombieEvent' properties in the Events rollout. These are very important. To get your volume to start/stop spawning zombies you need to trigger it & that's what the tag is for. The 'ZombieEvent' is an event any Zombie spawned by this volume fires off when he dies. We will be using this event to increment our second Objective, a way of letting it know that we're killing stuff and completing our goal.
Speaking of that second objective - Let's take a look at how it's set up.
Our 'SuccessCondition' for this objective is a 'Counter'. Counters are used for ... you guessed it, counting. Each time an objective with that type of success condition is triggered, it will increment the counter by one. So we match the tag of our counter objective with the 'ZombieEvent' property from our ZombieVolume ... and suddenly, killing zombies will bring us closer to completing this objective.
The Objective Events tab is also relevant here. There are separate arrays of events you can fire off at different times. the 'Activation Events' array is fired off at the moment when that objective becomes your goal in the mission. The Completion events fire off when the objective is successfully finished. As you can see, 'Wave1Zombies' (the tag from our zombie volume) has been added to both arrays. This means that when the Counter objective starts, it will activate the Zombie volume, and when it finishes it will shut the Zombie volume off.
Here is how the finished result looks in-game.
I'm going to skip over the part about the Door Movers , because I'm sure everyone here knows how those work. The Completion event from our counter objective causes the door to lower so you can move to the next area.
Which brings us to the next Objective in the list 'GoToNextRoom'. This objective has a 'Triggered' Success condition - which means that it will be considered complete whenever it is the recipient of an event. We will be using a second Checkpoint volume in the next room to fire off that event and tell the game that all the players are inside.
This is how the second checkpoint in the map looks :
As you can see it spans the entire length of the corridor. This was intentional. When you enter the second room the door will close behind you so you can't escape the next wave. But in a multiplayer game it would be possible for one player to enter the next room while the rest of his team stayed in the first room. They would then be locked out. That's where the large volume size and 'bRequiresWholeTeam' flag comes in handy. A checkpoint with that flag will not activate until all living members of a team are inside the volume's bounds.
When everyone is safely inside the second checkpoint's bounds, it will activate and trigger the event 'GoToSecondAreaObj' (this is GoToNextRoom's tag). At this point the team's progress will have been saved (if they die they will now restart from this checkpoint, not the starting one) and the next wave timer objective will be starting its countdown in preparation for the second attack.
The methods I have been describing are more or less duplicated in the final corridor of the map, so I won't go into much detail on that. There is one notable difference however.
With the final wave, I wanted to add abit more difficulty (other than including harder zeds) so I added a 'FailureCondition' to the final wave's counter objective. Failure conditions are the counterparts to Success Conditions. Essentially, they represent a way in which the player can screw up an objective. A common FailureCondition is a Time Limit. I decided that for the Final wave players would have to kill 60 Specimens in 60 seconds, or they would fail the entire objective and be forced to restart from the last checkpoint!
Here is how the failure condition looks for the final wave objective
It is important to note that Objectives do not need to have Failure conditions. In fact, most of the objectives in the maps you create probably won't. It's simply a way of putting abit of additional pressure on players and possibly creating a more interesting type of objective. Failure conditions and Success conditions can be mixed and matched without any problem. The only exception is that you can't have a TimeLimit failure condition with a Timed Success condition. I hope it's obvious why that wouldn't work :P
Here is how the final objective looks (with failure condition) in-game
When the last objective in the level rules list is completed, the game will end in victory. Unless that objective is not marked MissionCritical, or it has a SuccessAction of DoNothing. As you will probably notice (if you manage to kill 60 zombies in 60 seconds!) you will win the mission.
Anyway, I hope that all made some sense and I am really looking forward to seeing what kind of cool story maps you guys can come up with using these methods. If anyone has any questions at all, don't hesitate to add me on Skype (A_Jim_Quick) or leave a post either here, or in the main story mode thread. The more feedback I get and the more people who use my code in their maps, the more awesome I can make it
Note : You can find the map used in this tutorial in the latest story mode .zip file over here
it is called : "KFS-TestmapB" ( super imaginative, I know)
|
| |
| |
Main 
Downloads 
Test 
Forums 
