The basics Infiltrate cogs Personal tips |
Creating an Infiltrate level is much like creating any other. All the usual considerations should be taken into account; if you want people to play your level, a prerequisite is that it is technically sound and does not crash the game or cause similar problems. If you are new to editing, try the message boards at Darkjedi or the tutorials at The Massassi Temple for help on getting started. In addition, there are several specific things that an infiltrate level must possess. Much like a ctf level, the Infiltrate cogs must be present and correct, and the level must be divided into certain sections. These are the start area, where players enter the game, which must be separated from the main play area, and the main part of the level itself, which will be divided into two areas, the rebel and the imperial bases. It is up to you whether you wish to create symmetrical levels, the "flip" feature in JED (press F9 to access) and multiselect makes this very easy. It's also a good idea to make it reasonably difficult to access one base from the other, by using whatever means you like. For example, in Jason Burton's "Bespin Outlands" level, the bases are separated by a yawning gulf ready to swallow any unfortunate player :-). Feel free to make up any structures or cog traps that you think might help. Within each of the two bases there should also be two surfaces and one thing that are the team's vital points. I advise using a multi-cell mat (one composed of several textures, such as 14scondt.mat) for the surfaces, as these can show a different texture to show their damaged status.
There are five cogs that are needed to make an infiltrate level
infiltrate.cog gamecli.cog ctf_safeentry.cog ctf_respawn.cog lev_effects.cog
infiltrate.cog is the main cog for the game, just like ctf_main deals with ctf. In JED, add this to your cogs list by putting it in your project directory and then placing it in the level. There are several parameters that must be filled in.
gamecli.cog is a cog that runs on the local machine and creates most of the effects such as sounds and sparks. It makes use of triggers to cut down on lag. Again, there are several necessary parameters.
ctf_safeentry.cog is a client side script to catch the player in case he misses the marked message from the server, or the lag is too big.
The blue sectors in the picture below represent the safeentry sectors. The sectors directly above them are those that the player enters to join a team.
ctf_respawn.cog makes sure that initially the player starts in the start area, then respawns in the selected team's base. There are two necessary parameters that tell the cog which team the player has joined.
Before advancing to the last cog, it is worth looking at the placement of walkplayers. If you open ctf_respawn.cog, you will see that it reserves walkplayers 16-31 for players joining the game, 0-7 for the red team and 8-15 for gold. Therefore, make sure that your walkplayers are placed correspondingly. Before starting a level, I like to insert 32 walkplayers, thing no. 0-31, so that it's easier to handle, but you can just think of it in terms of the first 8 walkplayers you place must be red, the next 8 must be gold, etc.
lev_effects.cog is a client side cog which handles any level specific effects on the damage or repair of vital points that you might want to implement. Examples in the initial release are the turbines and floodgates at Barons Hed, or the disabled Rebel doors at the Rebel River-Gate Outpost. You may not wish to use effects, which is fine, but if you do, then you will have to edit the cog. In its basic state, it merely has a trigger when any vital point is damaged or fixed. It is up to you to insert the code. Here are some examples you might like to use:
play a sound when the rebel thing is working, stop it while damaged:
startup: rebchan = PlaySoundThing(workingsnd, thingreb, volflex, mindistflex, maxdistflex, flags); //make the sound play on this channel. Reference parameters in symbols. panelthing: //something has happened! If(GetParam(0)==0) //damaged! { StopSound(rebchan, 2.0); //stop sound on the int channel } If(GetParam(0)==1) //fixed! { rebchan = PlaySoundThing(workingsnd, thingreb, volflex, mindistflex, maxdistflex, flags); //make the sound start again. } Return;
Shut a door when an imperial surface is damaged.
targetone: //something has happened If(GetParam(0)==0) //damaged { MoveToFrame(impgate, 1, 16); //shut the door } If(GetParam(0)==1) // repaired { MoveToFrame(impgate, 0, 16); //open the door } Return;
These are just two simple examples to help you along.
This is the file that produces all the text messages you see on screen when an infiltrate event occurs. You will need to edit this to personalise the messages. Remember the msgbase int that was in the cogs? This is where it comes in handy. If you open any cogstrings file, you will see a series of messages which all begin with a number.
"COG_04020" 0 "The Rebel turbine is back online." "COG_04021" 0 "The Rebel floodgate is back online." "COG_04022" 0 "The Rebel cooling duct has been repaired." "COG_04023" 0 "The Imperial turbine is back online." "COG_04024" 0 "The Imperial floodgate is back online." "COG_04025" 0 "The Imperial cooling duct has been repaired." "COG_04026" 0 "The Rebel turbine has been disabled!" "COG_04027" 0 "The Rebel floodgate controls have been shorted!"
In this case, the msgbase int was 4000, to correspond with these messages. So for you to have your own messages, change all the numbers to make them match your msgbase, for example if your msgbase was 6000, the first entry would be changed to
"COG_06020" 0 "The Rebel turbine is back online."
to match up. Then you can change the actual message on the right to correspond to what had happened in the level.
This section is one that you may choose to read or ignore. It certainly doesn't contain any technical data on making infiltrate levels, just some of my thoughts on how to make better levels. I'm not claiming to know everything, but as someone who plays levels as well as making them, I know what I like to see. Gameplay is clearly the most important factor. This can be affected by a poor framerate, so try not to make your architecture unnecessarily complex, or cut the players view off using screens, walls and corners so the engine does not have to render so much detail. For smooth gameplay moving around should be easy. Don't make corridors too cramped, and consider that most people will be playing over the internet, so reduce frustration by making bridges and girders wide enough so that a little error is allowed. After gameplay, it's nice to be immersed in the level. This can be created through textures, sound and architecture. The fundamental architecture must be considered at the earliest stage, but small details can be added right up to the end to add interest. Consider the underfloor pipes at the Waterworks level or the many alcoves at Bespin. These are all addon sectors that can be added at any time. Also consider the location that you are trying to recreate and use corresponding architecture. For example, my level was meant to be a pumping station, so Included a lot of pipes and flowing water (although I must confess I was pressed to make the thing in a shorter time than was ideal, so not everything's there). Anyway. Sound is important as well, make use of ambient sound to create atmosphere, for example running water near a pipe, or an electric hum in a room full of computers.
As you'll have noticed, these are very basic tips, second nature to many editors by now, but just things to think about when creating your level. If you do decide to make a level, please notify us on its release, as we are considering an addon level pack
Raptor, ICQ 12603394, Feel free to mail me