Map creation workflow questions

Discuss map ideas, techniques, and give help.

Map creation workflow questions

Post Apr 19th '14, 23:37

Hi there. There are plenty of tutorials and advice about map creation, texturing, lighting and such. But how does one, nay, how do you go about creating a scenario?

- What comes first to you, a story or a set of map ideas?
- How do you embed the story in the level's terminal?
- How do you come up with the topography of the map? Is it more important for it to look functional or to be gameplay-friendly?
- Have you ever worried about pacing, both in terms of shooting stuff in the face and delivering the storyline to the player? How do you approach potential issues?
- How do you go about creating the map, paving, texturing...? Do you do lighting at the same time? Do you playtest without textures in?

That last point is what has me more intrigued. I wished Bungie made videos not just on how to use Forge, but also on what workflow to follow.

Anyway, enough rambling.
Johnman

Post Apr 20th '14, 02:33

This isn't really necessarily my area of expertise, since almost all my released maps have been netmaps. However, I'll toss in what's 'worked' for me, even though almost all my solo maps are sitting around on various harddrives as parts of unfinished projects. To an extent, I think your workflow will depend on what comes naturally to you, but here's what works for me.

What comes first to you, a story or a set of map ideas?


Either. Sometimes a set of map ideas inspires the story, and sometimes the story inspires map ideas. I think it's generally important to have some idea of where a map will take place in the story as you work on it, but if you have a map idea you really like then it can be just as helpful in progressing the story.

How do you embed the story in the level's terminal?


I can't really speak on this. Just... do it. Well.

How do you come up with the topography of the map? Is it more important for it to look functional or to be gameplay-friendly?


Different people seem to have drastically different opinions on this. I think it's best not to try too hard to make an environment seem "real"; leave things to the player's imagination. I just try to make spaces fun to explore and fight in. I don't think it matters if anyone would "really" design a space like that. I wouldn't necessarily say the same thing about "modern" fps engines, but you aren't going to replicate any real-life environments in Aleph One.

Have you ever worried about pacing, both in terms of shooting stuff in the face and delivering the storyline to the player? How do you approach potential issues?


In terms of combat, I like to pace things so that the player is often switching between small fights/exploration and periodic larger fights. I think it's generally best to save plot-progression for the beginning and end of levels (or in the middle of an exceptionally long level), and use in-between terminals to tell the player how to progress through a level. Don't spend too much time worrying about pacing before you start working. It's more important to just get things done.

How do you go about creating the map, paving, texturing...? Do you do lighting at the same time? Do you playtest without textures in?


I generally keep drawing out a map until I'm either not sure how to progress, or have finished a section of a complicated/overlapping area. Then I fill everything I've done up to that point, set heights, and pave. I then do textures and lighting for everything up to that point at the same time. Then I'll add liquids, and repeat the process until the entire level is drawn, textured and filled. I generally add monsters, objects, sounds etc. at the very end. I think this is because I used to find myself redrawing large sections of maps that I wasn't happy with, which deletes all the objects etc. in those areas. I don't find myself doing that often anymore, but that habit has stuck.
User avatar

$lave

Post Apr 20th '14, 02:55

Sadly, if you want advice from successful Marathon scenario creators, very few people are qualified to answer.

You're right that Marathon takes a different blend of gameplay and story. It can't just be a sequence of Doom levels, but it can't just be a sci fi novel, either.

However, the fact that the player has to stop what they're doing to read the terminal makes things easier. It's okay to take a few paragraphs of exposition before you get to the practical gameplay instructions. Until recently I was writing mission dialogue for a modern game, where all text is spoken remotely into the main character's ear. It was a significant adjustment, since all mission text pretty much had to be structured as, "Go here. I'll explain on the way," and the explanation couldn't last longer than it took the player to get there.

Anyway, assessing the pacing can be as simple as playing through like a new player, and seeing if you've been doing the same thing too long. For instance, the first terminal in Eternal is too long. The story is great, I've read it many times, but it's too much to digest in one uninterrupted chunk when you're ostensibly playing a game. Too much combat back to back seems to be less of an issue, but you can still go too long between pattern buffers, between shield rechargers, or too long fighting the same types of enemies or having to use the same weapon.

The topography is probably what I spend the most effort crafting. I mostly work on netmaps now, but my workflow is to have Weland and Aleph One open simultaneously. I run around in the map, find something to change, and then go back to Weland and change it. The most common changes are things like: I need more space here; this doesn't feel the way I though it would when drawing it out in 2D; I'm banging against this; I need another way to go from this point; this is too plain; this path isn't obvious enough.

I just pave the level until I'm happy with all the topography, because any texture alignment will have to be re-done as soon as I move some points. Plus, there are fewer steps when you're not saving the textured level and loading it back into Weland at each iteration. I get liquids, platforms, and other polygon types in and working early. I might texture doors or teleporters, but I don't bother saving these textures until the geometry falls in place. I add player starts first, then weapons, then ammo. Then I texture everything. I get the basic lighting in using a combination of VML and EasyShade. Typically, I end up making minor changes that don't change the topography in order to make texture or lighting changes at precise points (like to make a sharp shadow in the middle of the floor).

I jump back into A1 often, doing my best to imagine how it'll play with other people (again, my focus has been on netmaps). Once I've polished everything I can find that needs it, I start hosting it on the metaserver for real-world testing. Eventually it's good enough to call finished, and I release it.
User avatar

Crater Creator

Post Apr 20th '14, 10:40

Thank you for your answers. This is that kind of thing you pick up along the way more than you learn about from a tutorial, so I'm glad I got your insight.
Johnman

Post Apr 20th '14, 16:16

Johnman wrote:- What comes first to you, a story or a set of map ideas?


In my case, it's usually been a story that comes first. I write down the story plot with the idea of separate levels with objectives already in mind, so that I can easily break things up into a certain number of maps. However, once I have it down, separate, non-level-specific map ideas will occasionally pop into my mind, and I'll try to fit them into the story I already created.

Johnman wrote:- How do you embed the story in the level's terminal?


That's kind of a tricky and strange question. I'll approach it in terms of "How do split your story into different terminals?" Here's what I would do. Once I have my story outline down and separated into a series of levels, I lay out a series of quick 'Level Notes' (inspired by the Original Level Notes for M1, which you can find here: http://marathon.bungie.org/story/original_level_notesM1.html ) which contain not only some simple facts of the levels (level number, what monsters to use, what texture set to use, etc.) but also lists of the terminals, written in rough form, that will be on the level. I title these terminals based on their role. So, the first terminal you're supposed to read will be titled 'ENTRY', a random terminal you're supposed to just find some place and that will contain just extra little messages to read as you go about completing your objectives will be titled 'AESTHETIC', and the terminal that's supposed to take you off the level will be titled 'EXIT'. Entry and Exit are where the core of the story should be unveiled, but Aesthetic terminals should also convey depth and detail within the story. So, bureaucracy humor terminals a la Where Some Rarely Go would fall under the category of Aesthetic.

Johnman wrote:- How do you come up with the topography of the map? Is it more important for it to look functional or to be gameplay-friendly?


For me, it's a mixture. I like an appearance of functionality - it helps suspend disbelief - but if I need to make the level more than just shooting aliens, I'm willing to forgo aesthetics for pure gameplay. In most cases, however, it's an in-between. Rubicon X is a lovely example of such an in-between, as everything looks and feels realistic, yet the gameplay is not detracted from in the process.

Johnman wrote:- Have you ever worried about pacing, both in terms of shooting stuff in the face and delivering the storyline to the player? How do you approach potential issues?


Pacing should vary based on what each level should be. You want a level that's supposed to take it easier on the player? Okay, then just design it to provide a slow trickle of enemies. You want a level that should convey the sense of being in a warzone? Okay, then have a number of large battles in specific places, with only a small number of enemies lurking in-between.

Johnman wrote:- How do you go about creating the map, paving, texturing...? Do you do lighting at the same time? Do you playtest without textures in?


Usually, I start by coming up with a design idea. Then, I draw it out with just the lines in Weland, all the while keeping an image of what I want in mind. Once I think I've drawn it the way I want it, I fill it in with polygons. Then, I do the heights and liquids. Now the architecture is done, I do all the texturing at once. I go back and forth between architecture and texturing at this point, making all sorts of tweaks to get things just right, and then, once I'm satisfied with both, I'll start placing items, monsters and scenery. Then, playtesting. Then, tweaking. Then, playtesting again. Finally, it'll all be over and you'll have your map.
User avatar

PerseusSpartacus
Somewhere in the 19th Century...

Post Apr 26th '14, 23:10

Johnman wrote:- How do you come up with the topography of the map? Is it more important for it to look functional or to be gameplay-friendly?

A similar question was asked here.
User avatar

Ares Ex Machina

Post Apr 30th '14, 10:27

Johnman wrote:What comes first to you, a story or a set of map ideas?


Personally I don't care about story in old school FPS'ers. The Marathon Trilogy had a fantastic story (at least the first two games, I'm indifferent to the overly convoluted plot to Infinity) but most all scenarios released I only half follow. For example, I could recite the basic plot to Evil (crash on planet, find new alien Mystic things, try and stop them), but I couldn't name to you a character or any sort of interesting plot developments...because I didn't really follow it. In fact, I just finished a run through of Tempus Irae, and while skimming the S'pht and Pfhor terminals, I just could care less about the Earth-based "books."

That being said, I think you need to have map ideas before you start. Some levels I've recreated where on a whim - just built one room after the other. But I find all my personal best maps have always been created from the very beginning with having a specific mission in mind. Just staring at the blank grid doesn't provide inspiration, but going in with a plan that's some like, for example, shutting down the central core of a Pfhor ship and then flooding the reactor with goo (which is such a cliche anyway) makes the map creation process so much easier.

What got me back into Marathon mapmaking, honestly, was playing Doom on my 360 last year. They have very similar engines, and as I was playing it I realized, "I could build this map in Marathon!" Then I realized, hell, I could built waaaay better levels than most of these. So in a lot of ways I feel like I'm making Doom levels in the Marathon engine. (maybe that's why I always use uplink chips - a stand in for the skull keys!)

That's not to say you shouldn't write a good story if you're capable. One of the things that makes Marathon so unique is that you can satisfy multiple creative inspirations at once - map making, art, and story. You can't say that for other games (the latter, at least)

Johnman wrote:How do you come up with the topography of the map? Is it more important for it to look functional or to be gameplay-friendly?


This question has always driven me crazy. I may make Doom maps in Marathon, but I still try and build a functionality behind the locations. Maybe not every single room, but try and make it make sense. I am not a fan of the monster placement after I've created a level - that is always the last thing I do. When running through a level in visual mode (or the A1 lua script or whatever) I want it to be smooth and visually interesting and have a realistic flow to it to the point where it's nearly just as interesting to run through without having a single monster to kill than it would be if you were under constant attack.

That being said, I think as a level's creation progresses, in a lot of ways what you've already built will guide you towards what to build next. To show off what a huge nerd I really am, I will tell you that I always related map making to what one of the writers on Star Trek once said about digging the characters into a seemingly inescapable situation: that going in, he had no clue how our heroes would find their way out until the natural flow of the dialogue allowed the characters he was writing to tell *him* their solution. In other words, after you have a few rooms built, you start to see your own design pattern and it just becomes obvious where next to go.

Johnman wrote:How do you go about creating the map, paving, texturing...? Do you do lighting at the same time? Do you playtest without textures in?


I usually built at least half of the final map before I fill a single polygon. Since I am a Forge/Infinity veteran, sometimes I will have to fill a room just to make sure I am within engine limits (I know, I know...take advantage of A1 already!!) I will set my heights and platforms and polygon types and such before I ever enter visual mode (overly complex lighting or height structures notwithstanding) In a lot of ways, texturing is the task I dread the most. Particularly when you do wait until the second half of level construction to start painting. There are just *so many rooms* to do... you look at the grid of your level and think, sweet I'm almost done I can't wait to play test this! And then you're stuck texturing for another 5 hours.

After having said that, maybe I'm realizing this is *not* the way to go. If I built and textured one or two rooms at a time, and placed monsters and items and sounds and lighting as I went, maybe I wouldn't have been so burnt out by the time my level was completed to get so lazy about the aesthetics. Aesthetics are important, but game flow and fun factor are of paramount importance. Harkening back to my Doom comments, I will say that growing up I always thought (and still do, in many ways) Marathon was vastly superior in almost every way, but I have realized that while Marathon's aesthetics are infinitely better, Doom is just more fun to play. The levels might not be as interesting, the sprites are way more ugly, but the flow and gameplay is just so much better. I'm sorry - I said it. The 14 year old in me is humiliated that I admit this, but from a historical/nostalgic perspective, I think I can honestly say it's the truth.

Anyway, keep at it. Map making is a great joy, even with these engine limitations. Hope to see some results.
doctorbenjiphd

Post May 1st '14, 02:07

doctorbenjiphd wrote:...I think as a level's creation progresses, in a lot of ways what you've already built will guide you towards what to build next. To show off what a huge nerd I really am, I will tell you that I always related map making to what one of the writers on Star Trek once said about digging the characters into a seemingly inescapable situation: that going in, he had no clue how our heroes would find their way out until the natural flow of the dialogue allowed the characters he was writing to tell *him* their solution. In other words, after you have a few rooms built, you start to see your own design pattern and it just becomes obvious where next to go.


You know, I've heard that writer's technique before, but I guess I'd dismissed it as writers fawning over how deep and relatable their characters are. I think it's only recently I've come to appreciate it. You can have a story in mind, but writing the actual dialogue line by line can force you to confront any lingering holes, and cement how this is all going to work. When I let characters respond naturally to each other is when I write them asking questions that didn't occur to me. "Why don't we just..." "Wouldn't it make more sense if..." "You shouldn't do that, because..." etc.

It doesn't apply as much to Marathon since the protagonist is silent and there is no voiceover work, but I've taken to writing dialogue in two passes. The first pass is strictly functional: the information that must be conveyed for the player to know what's going on. For instance, if I were writing the first conversation in Deus Ex, the first pass might look like this:

Paul: Hi, brother. I’ll use your codename, JC, from now on.
JC: What’s the situation?
Paul: The terrorists are inside the building. Also, they’ve taken Agent Hermann hostage. We’re sending you in alone.
JC: I’ll need a good weapon.
Paul: Do you want a sniper rifle, a rocket launcher, or a mini-crossbow?
JC: I want the sniper rifle.
JC: I want the rocket launcher.
JC: I want the mini-crossbow.
Paul: Okay. Here’s a map, too. You can get a key to the front door from the informant at the north dock. You could also find a back way in.
Paul: The primary objective is to get to the top of the statue and talk to the terrorist leader. The secondary objective is to rescue Agent Hermann on the ground floor.
JC: Got it.


From this brain-dead outline, I can start quantifying how many conversations are needed, which characters are in each, and what the minimum number of lines and duration is. If the story is still awaiting approval, and/or it'll be a long time before voiceover work is recorded, I have workable placeholder lines to record, hook up, and use to prove out the gameplay, so everyone testing or working on the game in the meantime isn't left in the dark.

There's deliberately no personality, no character, no nuance, and no story exposition. Those are added in the second pass. "I'll need a good weapon" turns into "All I've got with me is a pistol and an electric prod. I don't mind a test, but UNATCO better issue some hardware." It's easy to adapt the first pass later to accommodate story changes, or to hand off to another person to write, so they know the critical information to keep intact.

In a lot of ways, texturing is the task I dread the most. Particularly when you do wait until the second half of level construction to start painting. There are just *so many rooms* to do... you look at the grid of your level and think, sweet I'm almost done I can't wait to play test this! And then you're stuck texturing for another 5 hours.

After having said that, maybe I'm realizing this is *not* the way to go. If I built and textured one or two rooms at a time, and placed monsters and items and sounds and lighting as I went, maybe I wouldn't have been so burnt out by the time my level was completed to get so lazy about the aesthetics.


You don't have to put time into texturing before you play test. You can pave the level in Weland, save, and jump straight into Aleph One. I typically do this while VML is already active. I might texture a a handful of surfaces, like a door, a teleporter, or the sky, to help get a feel for things. But to the extent possible, I get the shape of the level down before texturing or lighting anything.
User avatar

Crater Creator

Post May 1st '14, 16:42

Crater Creator wrote:You don't have to put time into texturing before you play test. You can pave the level in Weland, save, and jump straight into Aleph One. I typically do this while VML is already active. I might texture a a handful of surfaces, like a door, a teleporter, or the sky, to help get a feel for things. But to the extent possible, I get the shape of the level down before texturing or lighting anything.


The problem is, some texture sets are not so accomodating in this respect. The main one I'm thinking of is the Pfhor texture set, which replaces all the walls with the red liquid stuff, which makes it really difficult to see. I'm not sure about you, but I think I'd rather have my texturing done before I go running around in there fighting monsters.
User avatar

PerseusSpartacus
Somewhere in the 19th Century...

Post May 1st '14, 17:26

Does Weland really use that texture when it paves?
User avatar

treellama
Pittsburgh

Post May 1st '14, 21:13

Confirmed. A map made in Weland 1.4.1 paves walls using the red Pfhor slime texture if the environment is set to Pfhor. That just happens to be the 6th texture in the set. Forge does the same thing.
User avatar

Crater Creator

Post May 2nd '14, 01:05

It could be a useful feature to be able to "Pave with…" a specified texture.

(Especially if you could also pave specific surface types with specific textures. "Pave ceilings with…" one texture, "Pave floors with…" another, "Pave walls with…" a third, maybe even "Pave platforms with…" or, if there's some clear-cut way to distinguish doors from other platforms, "Pave doors with…", etc).
User avatar

Pfhorrest
California

Post May 2nd '14, 12:38

Crater Creator wrote:Confirmed. A map made in Weland 1.4.1 paves walls using the red Pfhor slime texture if the environment is set to Pfhor. That just happens to be the 6th texture in the set. Forge does the same thing.

Yuck!
User avatar

treellama
Pittsburgh

Post May 2nd '14, 16:56

treellama wrote:Yuck!


Yeah, tell me about it. [MTongue]
User avatar

PerseusSpartacus
Somewhere in the 19th Century...

Post May 3rd '14, 06:16

Work Flow is as follows:

Doesn't matter, because all that matters is where the flow ends:
LIGHTING. You will never release your scenario.

Notice how it stops at lighting? You make several 1000+ polygon maps and realize you need to light them all.
You need to remake all the lights for each map, then you realize that with 10+ levels that's about 18,494,978 polygons to light, and people TEAR OPEN YOUR ASS if you have sub-par lighting. Then your life becomes tedious, you start questioning how you're spending your free time, then your dream DIES.

Who knows how many scenarios are out there that will never be released only because the designer doesn't want to light the levels.
Shocktart

Post May 3rd '14, 06:40

Schopentart wrote:life becomes tedious, you start questioning, then you DIE

noooooo.jpg
don't disappoint him
noooooo.jpg (3.96 KiB) Viewed 3433 times

Please finish lighting your levels.
Last edited by patrick on May 3rd '14, 20:12, edited 1 time in total.
patrick
末法

Post May 3rd '14, 09:03

Have you tried EasyShade, Shocktart? It's made the lighting stage quicker than the texturing stage for me.
User avatar

Crater Creator

Post May 3rd '14, 21:24

Crater Creator wrote:Have you tried EasyShade, Shocktart? It's made the lighting stage quicker than the texturing stage for me.


How do you designate rooms? So that lights only affect the room you are currently in?
Shocktart

Post May 4th '14, 00:55

The function you want is roomlight(). If all you specify is the first parameter, the brightness, then the light will spread out until it reaches a polygon whose floor or ceiling is 0.5 WU off from the adjacent polygons.
Code: Select all
roomlight(80)

This is a decent approximation of a 'room' in many cases. If the default of 0.5 doesn't work, specify your own value by adding a second parameter.
Code: Select all
roomlight(80,0.75)

If you need to specify the floor and ceiling thresholds separately, use the second and third parameters.
Code: Select all
roomlight(80,0.75,0.25)

Finally, if the shape of the 'room' EasyShade makes is just too weird to manage, add a fourth parameter to limit the effect to a radius around the player.
Code: Select all
roomlight(80,0.75,0.25,5)


There's also the next & previous weapon keys, which step up or down the brightness in the room by one level. Because I added that as an afterthought, it uses the default calculation for a room.

The Read Me that comes with EasyShade describes these and all the other available functions, but I'll be happy to help if you have more questions.
User avatar

Crater Creator

Post May 5th '14, 07:25

I'll need to make a proving ground map and experiment with this tool.
Shocktart


Return to Mapping



Who is online

Users browsing this forum: No registered users