PDA

View Full Version : Alternative gametypes


yurch
7th Aug 2003, 09:41 PM
In attempt to revitalize discussion, here begins a series of possible gametype descriptions. They are mostly finished, but some input is of course welcome... just don't try to change it entirely. ;)
Writing it up helps to visualize what exactly needs to be done and what problems will occur.
We will most likely have 2.9 for a long time, extra gametypes introduced later after it's release will help the game interesting far longer than any single mutator can.

Fortitude, mk 2:

Goal: To create a gametype where territory is the main commodity.
Something similar to bf1942 or domination, but further improved.

For a realism game, territory-based games are a perfectly realistic and lend themselves to a fun game.

Fortitude's main downfall was that it often had more points of conflict than there were availible players, which caused a long, disorganized, and circular gameplay that was often too chaotic for teamplay, particularly with low playercounts.

Obviously, limiting the (relevant) points of conflict is what needs to be done. This can be done with a networked node approach(attached pic), Green nodes on the boundry between the red and blue are the only nodes now capable of being captured. In the case of extreme shortage of players, we can 'blank out'(are not capturable, second pic) any number of nodes in order to reduce the points of conflict further. The game then becomes more like the "push" gametype, but this is not nessisarily a bad thing.

Rules are mostly the same as fortitude. Players wave spawn at friendly uncontested nodes, using an algorithm that wieghts each node in terms of safety and distance from combat. Nodes with large quanities of enemies nearby will be passed up by the algorithm except for extreme cases. Notes at the far edge of the map away from all combat will likewise be wieghted against in order to keep players in the action. Spawns are unlimited, this is for both a gameplay alternative to normal inf and a nessesity for the gametype. Note now that contested nodes are determined not by player proximity, but by neiboring nodes. This may require a higher amount of nodes to keep the games from being too short.. and thusly larger maps overall. Nodes of one team not connected to another friendly node or an unclaimed node will be or will become contested(and therefore will not be able to spawn players) and will automatically fall to the opposing team. This will place obvious stratiegic value on certain nodes, and will prevent that annoying end-game scenerio where a dominating team is converging on (and spawnkilling) the last remaining hostile node. Nodes will be captured with the proximity of approximately 40% of the team's players for 10 seconds. If nessesary, the ability to capture with less people but with a longer time will be provided.

Barring specific mapper support, I believe this network can be created using nothing but the botpaths of ordinary maps, using an algorithm that uses the angle of the triangles created in order to create paths, with the nodes seperated using a percentage of total map space. There may be a few situations where you need to pass through enemy territory in order to even reach the contested areas, so this obviously isn't perfect.

Optional extras include:
Hud with node layout/map, or a compass with contested nodes marked (or possibly all of them)
Weapons only become availible at certain nodes. (you can only get PSG's if you own the center node, ect.)
Wave spawn timer increases or decreases depending on node ownership and/or total game time.
Mapper support for node placement, pathing and other above options.

A second gametype will follow shortly. Feel free to invent thy own.

-=SDS=-Coop
7th Aug 2003, 10:02 PM
sounds interesting... but is this fortitude also only going to be selectivley on at the administrator's discression.... when there was a time when i was active and fortitude was on, i've only played it twice... which doesnt give me all too much experience with fortitude. I dont think the whole weapons on or off depending on locaiton thing will work. sure it can be implimented, but it just doesnt sound like something that would appeal to people... it sure is a turn off to me thats for sure. i wouldnt want a favorite weapon taken away from me, likewise, i wouldnt want a weapon i dislike being my only option. unless if i've misread you, of course. editor placeable capture points. now thats a maybe... thing is, i for one have stopped editing untill the new version comes out, so i can make any maps im working on/previous maps compatable with the new game type. if someone wants to go ahead and make showshoot compatable with this game type, by all means go ahead, its just that snowshoot is too small for what is being planned, and servers that decide to run fortuitude2 will have to change their map lists to large/custom modified maps, which means even more downloading (DM-INF-DogtownFORT.unr will be what, the 5th version of dogtown for inf?) and we all know downloading is overall a general pain in the ass.

*Cash Register* $0.02

Keganator
7th Aug 2003, 10:10 PM
How about the o-so popular Team Fortress (and other games) VIP, where you have one VIP with little to no health and weaponry who must be transported safely from one point to another. Those points could be randomly created, even with waypoints.

How about "dual Shock" missions, where two teams must compete to accomplish the same goal, while preventing the opposing team from doing the same? Have three or so different objectives, randomly chosen: 1) get the 'object' (CD?) and return with it to your spawn, 2) arrive at and secure a point (TAS style), or 3) destroy an object at the point.

How about a 'destruction' gametype? An object of some sort (a downed nuke?) is laying someplace. One team must destroy it, and the other protect it. As a variation, make multiple defensive objects. As another variation, allow the defenders to be able to 'rebuild/fix/repair/unhack' the object. Make it so you have to actually walk up to it and 'use' it to demolish / fix it.

That's it for now, more brain spasms later.

jaymian
7th Aug 2003, 10:19 PM
Since your idea of Fortitude is similar to DOM, why not just improve on the DOM gametype itself? Start off by having the teams spawn together in a random location. Once DOM points are captured, you then can spawn there. Also, make some sort of timer for capturing, like 5 to 10 seconds. But when someone from another team is in the control point waiting to take it over, don't allow the other team to spawn there. Once each team initially spawns from random locations, only allow respawns at the control points, so teams need to have at least one point to get respawns. A team wins by either hitting a point limit, or by killing all of the other team and having all the points so they can't respawn. Respawns would have some sort of limit also. So when you die, you just don't instantly respawn. Instead you wait for others to die so they can respawn, and/or a set time limit like 10 to 20 seconds.

Fortitude was nice, but like you said, you needed a full server. And it was also nice because it uses the gametype with the largest selection of maps. But it also used those UT CTF flags, and a lot of times, flags would end up in odd locations. With DOM maps, you have set points and with newer DOM maps, you have more realistic points.

I remember you saying you didn't feel DOM was realistic enough or something like that. Well why not try to help make it more realistic? You code the mod, I make the maps;)

yurch
7th Aug 2003, 10:19 PM
(yes, I'm rehashing old ideas)

(yurchian) Entropy:

Goal: To create a gametype with an extreme(if not perverse) emphasis on player and team survival.
Original idea is based off the Descent3 gametype of the same name.

My most intense games are the ones where I want to survive. CS does this by making you purchase your weapons, CTF does this by placing the flag, and your team's fate, in your hands, other games do this with complicated respawn processes, ect. The goal of this gametype is to allow player to earn privilages which, of course, they don't want to lose.

D3's Entropy was a team game, which had 'bases' for each team, with various abilities for the bases, which also served as safe areas from the majority of enemies. There were health bases, ammo bases, and virus bases. Bases were taken by getting 5 viruses into an enemy base for 5 seconds. The catch was, that you could not hold the required number of viruses if you did not have 3 kills in a row. Yes, this means that the player had to have survived a number of engagements already, picked up these viruses, and most likely has refilled his ammo or health at least once. That's quite a bit of time to stay alive, and when the player gets to the point where he is capable of taking a base, he is then a mission critical item for teammates to keep alive. This is, with a decent team in constant communication, outright crazy in intensity. Important also is the bases themselves - losing your last ammo or health station is a bad prospect indeed.

An Inf conversion of this gametype could be laid out somewhat like fortitude descirbed above, but with bases designated as ammo, health, virus, ect - with maybe any base capable of being taken. It's possible the health of the players might need to be doubled or more to allow for a greater chance of survivability (realism be dammned!). Perhaps stick 2.9 laptops at each node for the capturing player to access.

Scoring could increase expoentially for successive kills or captures. Long streaks will be rewarded heavily.

Maybe even bot bodyguards for the nodes you aren't supposed to be at.

yurch
7th Aug 2003, 10:26 PM
Fortitude was nice, but like you said, you needed a full server. And it was also nice because it uses the gametype with the largest selection of maps. But it also used those UT CTF flags, and a lot of times, flags would end up in odd locations. With DOM maps, you have set points and with newer DOM maps, you have more realistic points.

I remember you saying you didn't feel DOM was realistic enough or something like that. Well why not try to help make it more realistic? You code the mod, I make the maps;)
Using DOM as a codebase isn't the grandest prospect, but adding the ability to use the maps (or even all maps) might be quite possible.
The problem with small existing DOM maps is that they only have a few points to start with, and the 'contested' archetecture of fort is something required if you want to have spawns that aren't camped to hell by a few annoying players.
It might even be possible to create a set of ini's that place the nodes/paths at mapper/admin defined areas, allowing you to bypass fort's random node generator and define your own routes and bases for any existing map, no matter it's original gametype.
Tell me THAT doesn't sound sexy. :mwink:

GenoOfTheCrayon
7th Aug 2003, 11:12 PM
I've got a concept for a mod, and Yurch has given me permission to post it here, although it doesn't really make any sense, and I don't think it'll be for INF. If anyone wants *cough*Keganator*/cough* they can move this to a different thread or something since it doesn't really match the general forum thing. Now to the mod!

While explaining it yesterday, various people on IRC told me I should just play UT on acid, since the outcome will be pretty much the same. My idea is what I call MorpBall, or you could call it Acid UT. It all revolves around one objective, getting the most points to win.

And then you ask, how do I get the most points? Why, simple! Complete little quests such as "Kill 10 cows!". How do you get these quests, you ask? Well, there will be a ball bouncing around everywhere. If you touch it, everyone will get a mission objective. It can be anything from the above mentioned "Kill 10 cows!" to "Commit suicide without using your weapons!". If you do so, then you get points. But here's where the fun begins. You see, not everyone will get the same objective, at least not usually. Some random guy may get "Defend the 10 cows from death!". Of course, they won't know whether or not everyone else got the same objectives. They could be the only one with "Defend the 10 cows from death!", or they could be one of the many people who do. You never know if that's what you're REALLY supposed to do.

The entire gametype/mod is based off of randomness. There might be a chance when you touch the ball to get an objective that everyone else but you suddenly has 3 or 4 suicide nali spawn near them. Or you could be the only one. Matter of fact, the objective may even be "Run away from the suicide nali!". For another unfortunate person, it may be "Run INTO the suicide nali!", you just never know. It'd take TONS of coding, I know, and lots of random factors, but at the start we could just implement the objectives, and then the randomness in them, and then the enemies, and finally weapons.

The weapons I plan for this gametype would not be seen anywhere else but an insane asylum if you gave them a piece of paper and a pencil and told them to draw something. Suicide-Mini-Titan launcher, which launches a mini-titan (like 2 feet tall) that explodes like a flak grenade (but with gibs) when it touches something. A gib gun, that takes your own body mass and launches it at the enemy. Everytime you shoot it, you get thinner and thinner, until you suddenly disappear (IE, die, but you have no corpse). Whoever you hit keeps inflating and inflating, until they finally explode, with gibs shooting everywhere. A dig-dug style pump, which you shoot at someone, and pump them up until they explode. The gibs, of course, will do entirely random things, no matter what gun you used to kill them in order to get gibs. Some gibs might ricochet off of walls, razor-style, until they hit you. Others might bounce around and randomly explode with biorifle sludge, or flak in every direction. Yet others might even turn into random UT monsters, with a bit of insanity added to them (like insanely thin skaarj that explode like a flak grenade (meaning, flak shoots everywhere) every ten seconds, but don't die from it). Of course, whoever made the gibs appear in the first place, whether they were from someone who shot someone else with a gib gun, or from gibbing someone, get's the credit. Gib gun gibs act like regular projectiles, doing damage and such, so they don't do random things like other gibs, unless they miss and are dormant for 10 or so seconds.

More ideas for objectives and such:

-When you touch the ball, a message saying "ALL ABOARD!" comes up, and everyone lines up behind a nali stuck in the running backwards animation in order of points, highest in the front to lowest in the back. It goes around the entire map, following the bot paths, and stops at a random moment. After it does so a message saying "TRAIN WRECK!" or something comes up, and everyone tries to kill the nali. The first one to kill the nali gets jumped to the back of the line. The train then continues, and it will stop again. This time, the first person to die gets booted out of the train, and must wait for the objective to end. Whoever killed him gets moved to the back of the train. It keeps going until there's only one person left, where they will get a number of points.
-An enemy, the suicide nali, of course. Touches you, goes BOOM!
-Another enemy, the gasbag of DOOM! It flies around, and launches a rocket at you. If it hits you, your controls get reversed, and your view turns upside down. If it hits you again, you go back to normal.
-Weapon, a gun which shoots a vacuum ball. Everyone within around 30 feet gets sucked into the center, and they lose body mass like if they had shot a gib gun a few times. They will stay there for 5 or so seconds, losing body mass, and then get shot out like a cannon. If they get completely drained, then the kill gets awarded to the one who shot the ball. All the gibs that got drained get shot out along with the people sucked in. The gibs act like "normal" MorpBall gibs, in whatever way normal applies to MorpBall. If the gibs kill anyone, points go to the shooter.
-A regular deathmatch, simply with random monsters and weapons and such, but with no objectives or ball. This mode will be called Acid UT, named after what erehwoN once told me this sounds like, UT on acid.
-Randomly changing lights, if it's possible.

That's all I've got to say. Any ideas would be nice, although I doubt anyone will say anything other than "What the HELL were you smoking when you thought this up?!"...

(SDS)benmcl
8th Aug 2003, 12:16 AM
yurch
I was wondering about the nodes. You explained the bot paths well and pointed out the problems. You also suggest that mappers may also place nodes. The problem with that of course is conversion of old maps, downloads etc.

Wold it be possible that the game type reads an ini file associated with the map. In that file you can use the grid refrence in UT to mark out the areas for lets say spawning, nodes etc.

By doing that it would be very easy to convert an older map, just create an ini file for it. You may still may have problems with path nodes such as that on Sicily which is unplayable with FORT.

Also this will allow you to create mre interesting tactal situations.

Edit: All right all right. I know. Don't tell me. I did NOT read yurchs other post. I am tired sorry. Anyways I suggested the idea a long time ago anyhow. ;)

Edit: Geno. Tommorrow I will come home, take out my bottle of vodka, get some mix, log on and try to read your concept again. ;)

keihaswarrior
8th Aug 2003, 06:12 AM
I really like the idea of fortitude mk2. The .ini file idea would be an awesome feature that could make almost all the maps playable. I also like all the option extras EXCEPT for the weapon selection depending on different nodes.

jasdave
9th Aug 2003, 09:06 PM
What about that black hawk down game type? All it needs are the same sort of bots from the zombie mutator.

DamienW
9th Aug 2003, 09:43 PM
A "black man down" gametype would get old pretty fast. And you couldn't give a lot of AI to the opfor. Not worth trying in my never humble opinion.

Chow Yun-Fat
10th Aug 2003, 01:43 AM
i still think there should be a zombie game type....


but that may be just the jack i'm drinking right now at this time of night...

Crowze
10th Aug 2003, 05:13 AM
The zombie mutator doesn't work online - no way can us 56k (or 64k)-ers cope with over 100 zombies in a map. The zombies aren't really 'bots' in the same sense as your regulare UT bots, and the way they are written doesn't make them work online anyway.

I like the sound of entropy, although not having played D3 I'm at a bit of a loss as to what the different types of bases are for (especially the virus base).

Geno: What the hell were you smoking...?

yurch
10th Aug 2003, 12:53 PM
Bases were taken by getting 5 viruses into an enemy base for 5 seconds. The catch was, that you could not hold the required number of viruses if you did not have 3 kills in a row.
Viruses (Virii?) were basically just little spawning thingies to pick up in order to take bases. More was better (2 virus capacity per kill), as you could eventually take several bases in a single trip.
The other bases provided health and (primary)ammo to friendly players.

Keganator
12th Aug 2003, 12:52 PM
Okay, here's another gametype idea, ambush.

One team consists of about one third of the players on the server, and the other team consists of the remaining two thirds, taken care of by gametype autobalance. The larger of the two teams, team A, must escort an 'object' (whether it be a large truck, VIP, or anything else that is slow to move) from their starting point to a finishing point, aka, extraction point. Team B's job is to stop them by any means necessary. The catch? Team B has infinate respawns, while team A does not. Team A could survive, if they advance slowly, cover each other, and work together, but will loose if they do not make good use of every person they have available. Team B, at the same time, can win easilly if they set up ambushes together, but by themselves, a 2:1 ratio will get them wiped out every time (we can only hope).

kungpaosamuraiii
12th Aug 2003, 03:16 PM
Hey, I like that one. In 2.9 it could use the specialist for the VIP.

I think the attackers should be restricted from using body armor and grenade launchers while defenders can use whatever they want. That way gameplay is prolonged a little bit because it'd be pretty easy to nail the VIP with a gl and win from a lucky miss.

GenoOfTheCrayon
12th Aug 2003, 04:31 PM
That's saying if the VIP is out in the open, which is when you deserve to lose :p

Conglomera
12th Aug 2003, 05:12 PM
The beast (Predator) :
The first player who join the server will be the predator, using monster model, this beast will have super human strength, high jump, extra health, super speed, ability to cloak and to kill with one slash from its claws... other players must team up to kill the beast... the beast constantely loose health and need to kill humans to regenerate (a way to avoid camping predators)...
the game is score based, a player-human get points from shooting the beast, not only killing it... so the more a human player damages the beast the more points he'll get, the beast gain score by staying alive like (number of humans) points every second... and the one who has the smallest score when the beast is killed becomes it for the next round. That's the idea.

kungpaosamuraiii
12th Aug 2003, 08:52 PM
Yurch expressly asked that we not TOTALLY change the idea ;)

Keganator
12th Aug 2003, 09:04 PM
Team games is what we're looking at, I think :)

-=SDS=-Coop
12th Aug 2003, 10:30 PM
TDBAS? Team Dynamic Bunny Assault/Assainate Squad

its like BAS but with teams and team scoring, and its dynamic, so the teams spawn randomly. everyone has to kill as many bunnies and enemy team members as fast as they can. the winner of the round is dictated by teams with total bunnies killed. to make it more interesting, if someone kills someone else, they get half of the total kills the person they killed had (but the person who was killed's total bunnies killed is still counted towards the team's total.)

c'mon keg... you know you wanna

Bloodhawk
13th Aug 2003, 07:01 PM
Wat about a gametype that focuses on avoiding the enemy.

call it 'Reconnaissance' or something.

Ex:
Team A- Has to defend a base containing something of high inteligence value.
They are also responsible for searching for the enemy.

Team B- Must start far away from their objective and stealthily make their way past the search parties and into the enemy base.

conditions for winning:
Team B: must take a picture of the item of intrest and then upload the data using a laptop. (or something along those lines)

Team A: (this is where things get interesting)
Must 'detect' the enemy by killing one or more of them. Once that happens, two things are set off.
1. A countdown timer starts(5-10min?).
2. Setry bots begin to spawn as the timer counts down (every 60sec 1 bot will spawn,then 2, then 3, and so on)
If team B fails to reach their objective within the time limit, team A wins.

This would probably work best in a dense jungle setting.
What do ya think?

Puncher
13th Aug 2003, 07:32 PM
What's to stop Team A from simply camping around the objective?

Might be better if Team A cannot get within a certain distance of the objective (unless alarm is sounded).

kungpaosamuraiii
13th Aug 2003, 09:08 PM
For TDBAS, I think it'd be really cool if a bunker is spawned somewhere and all the players work together to secure the bunker from some bunnies and then get attacked and have to hold off hoards and hoards of bunnies.

For Recon, the bot sentries would have to be restricted to walk or jog because they are uber hip shooters/sprinters. I like that idea though. Only problem would be finding suitable maps. These would be maps with many paths and low lighting and the attackers need to be able to detect guards though because human guards will be actively searching for the attackers. How about assigning a player to a guard radius and if defenders leave they lose points or something.

Keganator
14th Aug 2003, 12:02 AM
I know you were all looking forward to DBAS, TDBAS, whatever...but that may not be possible with some other projects I'm working on right now :) Sorry :o It would be neat, though...

keihaswarrior
14th Aug 2003, 07:27 AM
Wat about a gametype that focuses on avoiding the enemy.

call it 'Reconnaissance' or something.

Ex:
Team A- Has to defend a base containing something of high inteligence value.
They are also responsible for searching for the enemy.

Team B- Must start far away from their objective and stealthily make their way past the search parties and into the enemy base.

conditions for winning:
Team B: must take a picture of the item of intrest and then upload the data using a laptop. (or something along those lines)

Team A: (this is where things get interesting)
Must 'detect' the enemy by killing one or more of them. Once that happens, two things are set off.
1. A countdown timer starts(5-10min?).
2. Setry bots begin to spawn as the timer counts down (every 60sec 1 bot will spawn,then 2, then 3, and so on)
If team B fails to reach their objective within the time limit, team A wins.

This would probably work best in a dense jungle setting.
What do ya think?

1. There should only be a few alarm panels where the alarm can be activated. In addition, the specialist can turn off the alarm from the panel, --but needs an alarmOff key to do so (option 1)-- --also, regular soldiers can turn the alarm off, but need an alarmOff key to do so (option 2)--.
2. Leave out the bots, once the alarm sounds the defenders will start to respawn at timed intervals indefinately (or until alarm is turned off).
3. When a defender kills an attacker, a one-time-use alarmOn key shows up in his items, the defenders can't sound the alarm w/o an alarmOn key. A defender may never get more than one alarmOn key, nor may he/she receive alarmOn keys while the alarm is sounded. When defenders die, they drop an alarmOff key, --but only the specialist can use the alarmOff key to turn off the alarm (option 1)--.
4. The objective should be something like --a missle or aircraft that can be viewed from many angles from inside the base, but not from outside (option 1).-- --Or instead of pictures, there can be several different places to download the CD from inside the base. If someone other than the specialist downloads the CD, the alarm sounds automatically (option 2)--.
5. The attackers must spawn randomly very far away, out of sight from the base. The base will be in the middle of the map, so the defenders don't know which direction the attackers will arrive from.
6. There will be several extraction points for the attackers. The attackers choose one by throwing a signal flare.
7. There can be booby traps, and IR sensors that only the specialist can disarm. If triggered, they sound the alarm.
8. The map should be very large, but the LOS should be very broken with lots of cover. Nighttime would be best (map could include spotlights!). Also the spotlights could act as trigger and target zones for sniper actors armed with m2's.

Bloodhawk
15th Aug 2003, 02:55 AM
Yes! spotlights would be awesome!
Mabye you should have to hold the light on your enemy for something like 3 seconds before the sniper fires.

keihaswarrior
15th Aug 2003, 03:40 AM
I was thinking that the spotlights could have a maximum speed at which they can turn to prevent someone from wipping it around all over the place with a high mouse sensitivity. Also, the longer the spotlight was held onto the enemy, the more accurate the sniper actors with their machine guns would become (their first few shots would usually miss).

-BTW I think most of what I posted is possible with EAS as long as the mapper has skillz. I might need a small mutator for the alarm keys and the spotlight operation.

Keganator
15th Aug 2003, 02:24 PM
Quick, code related question: what 'class' is the sniper actor? I'm looking for an answer along the lines of is it a pawn, trigger, ... etc. :)

Freon
15th Aug 2003, 03:24 PM
it's a KeyPoint

keihaswarrior
24th Aug 2003, 12:48 AM
so yurch, what's happening with Fort markII? I reeeelly want to play it on TigerHunt and DesertTactics. BTW, it might be good to include a new flag image that looks like an actual flag. If you really want to make it look cool, the flag could have the owning team's camo on it.

yurch
24th Aug 2003, 03:34 PM
"database" issues. UT has some nasty data limitations on it's ini's that I'm trying to get around. (I can currently only hold one map!)

(SDS)benmcl
25th Aug 2003, 09:55 AM
I know it is cumbersome, not even sure that if it would work, but if you can't get around the limitation could you do one for each map. On map change the correct ini is used.

You may get the added bonus in that if there we would not have to update the ini file for newer maps. Just copy the correct ini file. May be easier for mappers to.

Not sure if it would work or just create more problems.

Keganator
26th Aug 2003, 11:22 PM
yurch, I'm curious...how much data are you storing? An array...per map? I don't think UT can support multidimensional arrays, so what about having an 'internal' array for the map...then storing each 'array' as a series of points in a single string?

Uh...does that make any sense to you? :)

yurch
27th Aug 2003, 12:09 AM
yurch, I'm curious...how much data are you storing? An array...per map? I don't think UT can support multidimensional arrays, so what about having an 'internal' array for the map...then storing each 'array' as a series of points in a single string?

Uh...does that make any sense to you? :)
Yeah, I may have to resort to something like that, but that'll suck when you try and edit it.
The only sort of 'multidimensional array' you can store are arrays of structs.
[fortitudemk2.FortitudeMutator]
CPLocations[0]=(X=44,Y=7348,Z=63)
CPLocations[1]=(X=14123,Y=-2380,Z=26)
CPLocations[2]=(X=124,Y=-2430,Z=15)
CPLocations[3]=(X=-3125,Y=456,Z=24)
CPLocations[4]=(X=-1134,Y=3548,Z=4577)
CPLocations[5]=(X=-031,Y=350,Z=41)
CPLocations[6]=(X=-1421,Y=-159,Z=-136)
CPLocations[7]=(X=-5132,Y=-198,Z=430)
CPLocations[8]=(X=1856,Y=-5789,Z=395)
CPLocations[9]=(X=0.000000,Y=0.000000,Z=0.000000)
numFlags=9
CPTeams[0]=1
CPTeams[1]=-1
CPTeams[2]=-1
CPTeams[3]=-1
CPTeams[4]=-1
CPTeams[5]=-1
CPTeams[6]=0
CPTeams[7]=-1
CPTeams[8]=-1
CPTeams[9]=-1
FlagMatrix[0]=(A=1,B=8,C=-1,D=-1,E=-1)
FlagMatrix[1]=(A=0,B=2,C=-1,D=-1,E=-1)
FlagMatrix[2]=(A=3,B=7,C=1,D=-1,E=-1)
FlagMatrix[3]=(A=4,B=8,C=7,D=-1,E=-1)
FlagMatrix[4]=(A=3,B=5,C=-1,D=-1,E=-1)
FlagMatrix[5]=(A=4,B=6,C=-1,D=-1,E=-1)
FlagMatrix[6]=(A=5,B=7,C=-1,D=-1,E=-1)
FlagMatrix[7]=(A=2,B=3,C=6,D=-1,E=-1)
FlagMatrix[8]=(A=3,B=4,C=0,D=-1,E=-1)
FlagMatrix[9]=(A=-1,B=-1,C=-1,D=-1,E=-1)
(yes, the data is made up)
Locations, teams, and networking information. Ten nodes with maximum of five connections each.

This sucks. Especially because everything inside the array CPLocations, CPTeams, or FlagMatrix is considered to be a single variable, which brings many of these dangerously close to the 255 byte(?) limit of UT.
So even if you did save them as big friggin' strings instead you still probably couldn't list the maps together.
As for seperate ini's for each map, no dice from what I understand. One ini per .uc class, and it's 'hardcoded' if you will.

The data might just have to be compiled into .u's.