Revision as of 14:24, 17 September 2008

Introduction

It is necessary for the map editor to contain some information that, if stored in the scheme, might mess up the game when the scheme is used with other maps. For example, you might want a scheme that inserts a crate into specific co-ordinates during the game. This might work for one map, but could easily fail for another. The map editor allows maps to store information that will always be used unless a scheme specifically disables it (see Map Editor Over-ride).

Map size would be derestricted, or have its limits increased for Worms Unlimited. The only good reason for restricting map size is for file transfer rates on WormNET, but this argument is flawed as the physical size of the maps have far less to do with file size than the content of the maps.

There would be two map editors: one advanced and one simple. The simple editor would include all the current abilities of the Worms Armageddon map editor, with a few improvements in efficiency, interface and some extra options. The advanced map editor would be capable of this plus everything listed below. The advanced editor would not be accessible from the host-join scheme, for reasons discussed in the introduction to this webpage.

Structure

Worm placing

One could decide where the worms are placed. Being able to change the number maximum of minimum of worms that there can be in a map would be a nice feature for avoiding too many worms in a small map or very distant worms in a large map.

Animation

Maps would use .gif files with parts of it moving and appearing/disappearing. When a part of the map is destroyed, this part is destroyed only in the "frame" of the map.

Graphic

A background showing in the map and a intouchable layer that is ahead the worms (So when the worms goes trough the layer, the worm is not shown)

Destructibility

Being able to edit the degree of destructibility of parts of the map map so it is destructible or indestructible. Also there could be intermediate grades of destructibility, configuring the times a part of the land needs to be hit for being destroyed and how destroyed it gets everytime it gets hit.

Scripting

And why not? Each map could have a set of scripts that would allow to control behaviour of certain elements, to customize the game settings for this map (e.g. initial worm placement for RR maps), enforce some schemes or define new weapons (perhaps, merging the notion of "map" and an expanded "mission definition" would be similar).

Dynamic elements

Examples:

• moving or spinning pieces (transportation, or traps)
• area teleports
• a volcano that continuously spits fire

Defining new game objects

A map's script would be able to define new Worms objects (like mines / barrels / crates etc.) and customize their behaviour. Everything you've ever wished for can appear in the map!

Weapons

Maps could contain in-built Weapon Modules. The game would load those together with the map script, which could "enforce" them later to the worms' inventories.

Layer-Based Information

All layers and their corresponding abilities would be accessible and editable within the map editor.

Variable Terrain Destructibility 

An extra layer stores information that determines which parts of the landscape are indestructible, and which are not.

Defined Object Placements 

When not disabled by the scheme, placements of all objects are pre-set to specific co-ordinates (see Object Control).

Game-Winning Crates 

Crates can be placed on the map at specific co-ordinates, the collection/destruction of which wins the game. They can be destructible or indestructible.

Game-Modifiying Crates 

Crates can be placed on the map at specific co-ordinates, each with an identity, the collection/destruction of which triggers an Event (see Event Control). They can be destructible or indestructible. Also, when a crate is collected, a setting of the scheme may be changed.

Game-Winning Flags 

Pre-placed flags are colour-coded to the teams that are involved in the game. The destruction of an entire set of flags corresponding to one team wins the game for that team. The flags operate in the same way as the "targets" in Worms Armageddon training missions do.

Automatic Spawn Points 

Worm placements for each team involved can be pre-defined.

Zones 

Invisible 'Zones' of any shape and size can be drawn over the terrain, each with a specific identity. These zones will trigger an event when they are entered. (see Event Control)

Types Of Maps

The map editor would be capable of producing three map types:

Regular Map

Nothing out of the ordinary here, just a regular map. With no - or less limited - size restrictions, of course. The current size restrictions on Worms are unnecessary and there is plenty to do with larger maps. Many schemes would benefit from bigger terrains, and even if they didn't, small maps are still an option. Very tall maps would also be possible.

Unlimited Cavern

Imagine for a moment a cavern map with no water at the bottom or open space at the ends, just simple borders like at the top. A cramped hole in the Earth. And imagine every time you get too close to a border, that border retreats a little bit, expanding the map and revealing more solid ground.

What you'd have is effectively a map of infinite size, only most of it is a repetative pattern of solid ground neatly tucked out of sight for safe keeping, waiting to be discovered and, ultimately, blown up. You could have epic adventures on such a map. There'd be no limits. If you were on the run you would never get cornered- just keep moving and the map will expand to accommodate you. With a large frequently used arsonal the map would quickly extend downwards as random shrapnel submits to gravity, and gigantic canyons would form.

There are some obvious problems with such a theme. The finite game is at stake here - games could easily never end. But no more so than when infinite health is used on an indestructible map. Still, there would have to be restrictions in place.

First off, weapon limits would be a good idea. Any infinite weapon is a means to never-ending excavating, and pursuits could last forever. Teleports would become more and more powerful as the map expands. Infinite teleports are a big no-no: teleport pursuits are the most boring of them all. Even teleports in limited numbers can be horrendously advantageous if a player has one and the other player doesn't. By teleporting miles away, you're forcing the enemy into using vast resources just to reach you by land. There are two solutions - either limit the range of teleports or don't have them at all. Range limiting could be done in the same way as with the Girder; by adjusting a 'Power' setting in the weapons options menu. This would force players into using a succession of short hops to reach far away places instead, and at each hop they might be leaving themselves vulnerable to a nearby enemy.

All weapons would have to be somewhat limited, but to prevent the game ever coming to a standstill a plentiful supply of crates would allow the game to continue on.

It's harder to navigate vertically than to navigate horizontally, so a good restriction that will prevent excessive expansion would be to limit the terrain to a vertical column, yet still have it expandable at top and bottom. Players would find it difficult to expand upwards due to the nature of the land, and at risk from massive fall damage on large maps. Players at the bottom would find themselves vulnerable to attack from above though, especially with gravity ensuring that enemy fire reaches the right place.

Some weapons would have to be adapted for larger-than-usual maps. Players would need to be able to throw them further, and fuse weapons would need greater fuse times for long throws. Some weapons would naturally be obsolete, like the Indian Nuke and all airstrikes. Map-wide weapons like Earthquake ought to be more useful than usual though, expecially on a columnar map. Also, jetpacks would require greater amounts of fuel, turn times would need to be greater (perhaps increasing throughout the game, proportional to the area of active map or distance between worms) and fast-walk utilities would have to be more abundant. Well, they wouldn't have to be. But it would be a good idea.

Last but certainly not least, a zooming feature would be critical for this type of game. Excessive scrolling is not something a player will want to do on a huge map, so either a mini-map could be provided scrolling in from the left of the screen on demand, or a zoom function not too dissimilar to that found in the original Worms game.

Wrapped Map

This feature would mean the map would have no edges yet a finite length. Scroll off one end of the map and you'd land up on the other - yet you'd never know when you've done so. It would be as if there were an infinite number of identical maps lined up to make one supermassive map, a perfect repeat of every object, worm and movement every so far.

It sounds surreal, but it isn't. It would perhaps seem a bit surreal one a huge monitor with a massive resolution, as you'd probably be able to see the same part of the map twice. Other than that, it's something you'd soon get used to. There'd be no edge of the cavern map to fall off, possibly making things easier for the player whose first turn it isn't. There would be no huge stretch of water for a worm to fall in on an island map, rendering the baseball bat and a few other weapons less useful. I suspect there'd be slightly more strategy in the game as well, as a player who is about to embark on a journey can choose to go either way to reach the same destination. Same goes for those who are trying to set up some sort of stronghold - they'll have to defend from both sides. And there's fun to be had too on such a map: throwing a holy hand grenade with low gravity just for the randomness of where it will land, roping endlessly in one direction.

The downsides may mean confusion in scrolling, and since some weapons can be heard when your screen is over the other side of the map, you may be able to hear the same weapon being fired several times. Unless you silence all but the nearest one. That is assuming there is more than one, depending on how it would be programmed.

Mixed Map

You could set the types of border of the previous map types so, for example, the top border can be infinite and the right border regular. The wrapped border would be an exception: if you set it in a vertical border, it would appear in the other vertical border, and if you set it in an horizontal border, it would appear in the other horizontal border.