Designing Levels/Missions

[technomage]

Hi all

I have a (hopefully) thought provoking topic.

What is a good way to define a level/mission.

I'm working on project where I would like to have the missions defined in an external file, so I can add to them later. I was trying to think of a nice way to define the following

1) Enemies
2) Good guys
3) Map
4) Events/Triggers
5) win/loose conditions

I got to this point and thought , "wow that's quite complex". So I thought I'd throw done the challenge.

Can anyone come up with a nice generic way of defining a level/mission
:?:

[WILL]

Hmm... well I've always liked the object oriented structure.

Basically make all your defined enemies into their own 'files' so you can mix and match any way you like durring level design. Same wit hyour good guys so that you can dynamically load them depending on if the player has a choice of which character to choose OR how they are required in each part of the game.

Maps can be seperate files containing events and triggers that can then point to your good guys and/or enemies, items, etc... and of course include your win/loose conditions in the map files so that it's all tied together.

Of course this is all up to interpritation since I don't know how your game will function. It can varry a lot depending on how the gameplay will work.

[Sly]

If you have a script system in your game, you could execute a script that contains all the details about a mission. The script could spawn props at certain locations around the world, and also specify win/lose conditions. Or it could be a collection of scripts. The first script would create a trigger box at a certain location and tell it that if the player enters it to execute a second script.

Therefore, all your mission-specific logic is contained in scripts which can be easily added to your game data.

[cairnswm]

Indeed there are many ways fo doing this. These are the two methods I find I keep reusing.

1. Map is the Mission
I create a map file - typically in the format:
Lines0-X - map tile data
Lines X+1 to end - object data
Each character in the Map tile data represents a tile.
Each line in the Object Data defines he information needed to create an object. This could be its name, stats, weapons carried etc.

Related to this would be details about the weapons etc (usually in a seperate file for each item).

2. Map is not the mission
Basically very similar but the Map file only contains map information. This allows the same map to be used in different mission contexts.
Then a mission file is created that links the map, and any objects together.

I have previously included AI as a seperate file that can be linked into the objects as they are created - for example I could create a line like:
Blue Knight, 100, 100, [Sword, Bow, Heavy Armor], Clever Hunter
When the game reads this line it creates a Blue Knight Object - In the Blue Knight character file it lists his hit point,s image etc - at position 100,100 - carrying a Sword, Bow and Heavy Armor - using the AI file Clever Hunter.

I have not yet done Mission Objectives and Win/Lose conditions like this.

Another Thought - I feel that the standard old Ini file format is very underutilised. There is no reason why you could not achieve a database structure using an Ini File. (In fact this is what I used for Run-A-War)

Another Thought - same applies to String Lists. Create a string list in a file where you use the Values method to load/store data. I create a key structure as follows <TableName>.<RecordKey>.<FieldName>=<Value> So I could do
Character.1.Name=Blue Knight
Character.1.Pos=100,100
Character.1.Items=Sword,Bow,Heavy Armor
Character.1.AI=Clever Hunter

[Sly]

Another Thought - I feel that the standard old Ini file format is very underutilised. There is no reason why you could not achieve a database structure using an Ini File. (In fact this is what I used for Run-A-War)

We use it all the time here at Krome. Here's an excerpt from one of our level files.

[ExplosiveBarrel]
{
  pos = 0.00,-200.00,2139.96
  rot = 0.000,4.683,0.000
  color = 1.000,1.000,1.000
  ID = 0,"none"
  zone = 1
}

[P0042_A_straight]
{
  pos = 90.51,-61645.37,116708.33
  rot = 0.000,-1.571,0.000
  color = 1.000,1.000,1.000
  ID = 0,"none"
  zone = 1
}

Some props get a lot more complicated with subsections and so on.

[technomage]

Hi good ideas.

I had a look at the way Air Blast did it's missions and it was a simple command based system.

I think I'll go down the xml route (the rest of my app has) with a combination of scripting where needed.

<level name="Level1">
   <teams>
       <team name="Player"/>
       <team name="Enemy"/>
   <teams>
   <objects>
       <object name="Item1" team="Player">
          <controller></controller>  <!-- define who controls the object here -->
          <position x="" y="" z=""/>
       </object>
   </objects>
   <events>
      <event name="">
         <conditions>
            <condition></condition>
          </conditions>
          <actions>
            <action></action>
          </actions>
      </event>
   </events>
</level>

That looks about right. I know people are sometime against xml for games, but I think it's a nice easy format to edit and update.

Dean

[Traveler]

I haven't really looked into xml based lvl design, but aren't you afraid people might change the files?

[technomage]

There are ways around that, I would store all the files in a packed archive so they would need to extract them first. You could encrypt the files as well there are some good units out there to do still like encrypt streams.

I like xml because it does mean you can tweek the files.

then again I was always hacking the Command andConquer Red Alert unit files as they were just plan text as well.