No announcement yet.

Modular Maps

  • Filter
  • Time
  • Show
Clear All
new posts

    Modular Maps

    Hi all

    I know this subject crosses over many different forum categories, but hopefully it’ll still garner appropriate feedback.

    Anyway, here’s the deal:

    The Problem

    Many Unreal maps have relatively limited playability, because of their static nature. Even though certain Power Nodes / Destroyable Objectives / etc. can be altered slightly, it’s still mostly up to the map-maker to incorporate these differences (with the exception of certain mutators, of course).

    The Proposal

    So, instead of laying the majority of the work in the hands of the mapper, why not make more “modular maps” that have interchangeable special objectives?

    Now, by "special objective", I mean an Actor of Significance -- like a Power Node, a Destroyable Objective, etc. . Each could be created and interchanged with ease, given a set of standard parameters (imagine a standardized flat "foundation" of a specific size in each map where the Special Objective would go).

    Each Special Objective could do just about anything -- be a respawn point for players, spawn vehicles, have weapon lockers / powerups / etc. . Lastly, each Special Objective would have a set "point value", which again can do just about anything depending on the gametype. For example, in a more Onslaught-ish gametype, the Point value of a Special Objective would slow down the drain of the main core after the time limit is up.

    In this way, mappers and coders have MUCH MORE flexibility -- a mapper can make the base map for the game, and the coders can each make their own little Special Objectives that get laid selectively or as mutators. Lastly, it's up to the GameType to determine what the "point" value translates into. Example: the more points your team has, the faster vehicles respawn back at your Power Core.

    Each Special Objective could have its own specifically designed meshes, special secrets / activation conditions, etc. . This allows designers to focus a huge amount of energy on a small, standardized, modular piece, which would allow for much greater quality of work (no more spending 10,000 hours on just one map of one gametype).

    If all of this is still super obscure or abstract, here's a silly example:
    A Mayan statue mesh, with a weak spot that must be shot out to expose the hidden power up spot inside (re-seals each round). Once captured, it would function as a respawn point for players, spawn health pickups, and spawn some minor wandering monsters that defend it against the other team. +5 points to the possessing team, which does whatever the game type says for 5 points.

    In addition to this summary, I'm going to do a quick write-up of some standardization ideas and post it up on my site. I'm very eager to hear from the creative minds here.

    However, I'm still at a bit of a time crunch at work, so I can't commit a huge amount of time to this concept. I'll do my best to keep up with the thread, and make some sort of standards document.

    Thanks all! Have a great one!


    Even though certain Power Nodes / Destroyable Objectives / etc. can be altered slightly, it’s still mostly up to the map-maker to incorporate these differences
    Leaving it "up to the mapmapker" is necessary because many post-compilation changes would be ignored by the game at runtime. There are many "behind the scenes" considerations -- things like team-based volumes (encompassing each node/objective) and AIscripts to govern bot (defend/attack behavior within each volume, based on team assignment) -- which the runtime game engine depends on.

    There was a "builder" mutator released a while back that enabled you to walk through a map, command "place a such and such item here"... and later, when you "played back" the map while the mutator was active, it would spawn the "added" items where you specified. Even if someone modified this mutator to "drop in place" DestroyableObjective actors, I can't imagine how it could handle setting up the necessary triggers (must clear Obj1 before Obj2 is available etc) for them. In any event, the navigation network is "baked" when the map is compiled; regardless where you relocated a node/objective, the game would still try to use the existing triggeredPlayerStart locations.

    Based on what you've described, perhaps the "Conquest" mutator would interest you: