Steam общност :: Дискусии

Portal 2

Всички Дискусии Снимки Худ. творби Предавания Видеа Работилница Новини Ръководства Рецензии

Community maps. For science.

Welcome to Aperture Laboratories, home of the Perpetual Testing Initiative. Easily create, share and play test chambers authored by and for the Portal 2 community. Do your part! Contribute to Science!
Научете още

Начало

Дискусии

Относно

Работилница> Portal 2> Всички дискусии

Тази тема е прикачена, така че сигурно е важна

Keyserson

17 май 2012 в 10:34

How To Make Great Maps

This post was originally posted in the Steam Users' Forums

A great map is well-lit, clearly laid out, appropriately sized and properly tested.

The Puzzle Maker tools are awesome, but they do need to be used with some common sense! So after playing a whole bunch of custom maps recently, I just wanted to point out some things you should/shouldn't be doing, and I've split them into Map-making and Play-testing.

Please note that this refers primarily to Puzzle Maker maps being released to a general audience in the Steam Workshop. Therefore these are the rules and principles you should work by in order to get the best reaction from the Community as a whole.

Many of the principles, however, still apply to Hammer-enhanced/built maps and concept maps.

Map-making

Always have a clear entrance (obviously) and exit. Don't be too cruel.
Light your maps. Just a simple strip light here, an observation window there...
That said, don't over-light your maps, or they might become ugly and even harder to solve.
Enough with the ma-hoosive empty chambers! Yes, it's impressive that you can create space now, but if you're not going to use that space for dramatic or puzzle effect, keep it smaller. Map after map of temple-sized chamber gets REALLY tedious.

At Aperture Science, test subjects don't have 'Restart' buttons.

Portal 2 has a story, a setting and characters. Whenever a player goes to the main menu, or is forced to manually restart their map, they are taken out of that story, and this ruins the experience. It's a fundamental game design basic: never force your players out of your game. It's sloppy. Kill them if you have to, but keep it within the world of the story. If you've allowed them to get stuck somewhere (see Play-testing below for how not to), then just kill them. Deadly goo is the best way.
A player should only die because they made a mistake. Don't force them into sudden, unexpected death, expecting them to 'learn from their mistake next time'. They should be aware of the threats before having to deal with them.

There are already dozens of thousands of maps out there. If your map is no fun, people will give up and move on.

Give players a sporting chance and show them as much as possible. Avoid too many labyrinth-like corridors, unless they are entertaining in some way. Dull stretches of nothing with little visual candy are rarely appreciated.
Don't make solutions *too* obscure. Try and at least make it that most initiators (buttons, lasers etc.) either have clear indicator lights to their target, or that you force the player to be looking in the right direction as they press a button. Pressing a button in one chamber, only for it to do something tiny four chambers away is very frustrating. Use windows to show players the results of their actions, even if you don't want to give them access to that other area just yet.
From ddrkreature: "Having [the map] hard, confusing, big, AND labyrinth like will just frustrate and bore the player. Having a simple enough looking room where they can look around without moving and see everything but at the same time have a complex solution can keep the player's interest and persevere as they don't have to continue moving around all the time to find something they may have missed. Drive the player nuts by having the solution hidden in plain sight."
Avoid forcing the player to use moves or techniques which don't fit with what Aperture would really be trying to test. Tricky feats like cube stacking, bunny-hopping etc. aren't a lot of fun for most people. In other words, keep it realistic - well, as much as possible anyway! Real-world physics puzzles are more satisfying than just exploiting what the Source engine can do.
Tests should have solutions that are challenging to discover, but easy to execute. Not everyone has a nice, smooth mouse, and there's nothing worse than knowing how to complete something, but not being able to.
Don't make players run backwards and forwards all the time; give them aerial faith plates or easy portals to transport them.
Avoid red herrings. This isn't a guessing game! This is a game of logic and puzzle-solving. Therefore, Every testing element in your map should be relevant, so that a player looks at it and goes, 'where does that fit?' One exception to this is wall panels: by all means have lots of portalable walls that never need to be used, because otherwise you'd just be creating a puzzle 'on rails'.
Don't create a puzzle 'on rails'. Give 'em some kind of challenge!
Make your maps look interesting. Use portalable/un-portalable walls to create interesting, contrasting patterns. Let bits of wall stick out and others carve into themselves. Add lights as decoration. No one likes a boring box!

REMEMBER: There's a difference between challenging and frustrating!

Play-testing

Play-test your maps. I've played so many maps where I've ninja flipped to the end, or bypassed a whole load of puzzle elements because you forgot to check your walls for portal solutions (it's in the title, guys) or just didn't think about how you were placing your objects. I've been working on just one map so far, and I must have playtested it at least 50 times already. You wouldn't want people to ignore all your hard work, would you?
Play-test every single scenario so that you know where a player might get stuck: what happens if the cube is destroyed? What happens if they forget to take the cube/take the cube when they shouldn't? What happens if there's nowhere to portal to? What happens if they go through the door BEFORE x, y or z?
Play-test your own maps, but also have other people playtest them; preferably someone new for every major update. A second pair of eyes can spot SO much more than you can sometimes, and it's very beneficial!
Playing someone else's map? Send a comment their way afterwards with constructive criticism.
Getting other people to test your maps? Encourage them to record a .dem of their playthrough:

To record demos:

Open the developer console;
Type the following: record demoname (where 'demoname' is the name of the demo);
Hit return/enter;
That file would save as 'demoname.dem' in Steam\steamapps\common\portal 2\portal2

To play demos:

Place the .dem file in Steam\steamapps\common\portal 2\portal2;
Open the developer console;
Type the following: playdemo demoname (where 'demo name' is the name of the demo);
Hit return/enter

NOTE: To be able to play the demo, you need to have subscribed to your map in the Workshop and have it downloaded in the game, as the demo needs this to play.

And finally....

If you've played the first Portal, you'll know all about the Companion Cube: a unique cube that the test subject becomes emotionally attached to, and keeps by their side at all times. In truth, you should avoid having more than one CC in a map; it should preferably be the only cube in the map, or the one required to exit the map, or a hidden Easter egg. Alternatively, you could use multiple CCs at once to achieve a particular effect, but make this very clear (such as having them all stand in a row). Don't insert random CCs without a reason for doing so; just use a standard/Franken cube otherwise!
The jury's still out on CC dispensers for damaged CCs, as a CC dispenser can actually be a joke about how devious/wasteful Aperture is.

This isn't meant to be negative or snarky or anything, it's just meant to help. These tools are great, but they're just that - tools. They need intelligence in order to be wielded properly!

Additional Reading
I've started to see some great topics crop up regarding Puzzle Making, so I'll list some great ones here:

'Too many items' error: Unable to build your puzzle because of this error message? Catsy's come up with some great tips, including approximate values for each in-game element.
List of Developer Console commands: you may not need all of these, but there are some (hide crosshair and portal gun, noclip) that are particularly useful for creating really clean shortcuts to upload to the Workshop.

Any other suggestions, drop 'em below!

Последно редактиран от Keyserson; 22 юни 2012 в 2:37

< >

Показване на 1-15 от 467 коментара

Penassa

17 май 2012 в 11:17

all sound advice,

i would like to add tho that i have made some maps that have had 1000+ downloads , only to have a handfull of comments, to a map creator/designer comments good/bad are very important , if you dont say what you like dislike how can you get more of the same!

the advice is once you play a map comment dont just thumbs up or down, explain why the thumbs up or down :)

Keyserson

17 май 2012 в 11:44

@Penassa That's in there, riiiiiight near the bottom :D Very true though - there's little point in making maps if people don't play them, and getting feedback from people is both rewarding and vital in ensuring you make those maps better, so more people play them and enjoy them. Otherwise the overall quality of the Workshop will suffer.

Geneosis

17 май 2012 в 12:13

I agree with all this points, but I think some of them can be skipped if there is a precise aim behind it.

For exemple I did this map : http://steamcommunity.com/sharedfiles/filedetails/?id=72165832
The story line is not totally respected, but the idea is there : you are in jail and will try to escape. There is not a lot of lights, connexions between buttons and objects are hidden, you can be stuck and forced to suiscide / reload, BUT all of this is expected. To balance these points, the avialable space is very small so that there is not infinites possibilities for the solution and the spirit of the game is still present (hiddens passages, guardian turrets, companion cube that you need all the time to progress...).

Oh and of course I often play-test my maps so that there is no unexpected ways to be stuck and/or unexpected ways to finish the level ^^

Keyserson

17 май 2012 в 12:26

@geneosis I get what you mean, but I doubt how well you could put an original 'story' forward using only what's in the Puzzle Maker, and without resorting to the Workshop description.

When I play maps, I queue up a whole bunch and play them at once. I won't necessarily remember what the description of each said, so I've got to just treat them as Aperture testing chambers, thus expecting the rules and conventions of such chambers to be adhered to.

Some people over the past year have done some fantastic story work in Hammer, granted (DaMaGepy's Time Travel Concept, for instance) but that's with the use of advanced environment work.

I'll play your map, though, and see if I change my mind after that!

Geneosis

17 май 2012 в 12:31

@Keyser I see your point... It's true that for the moment my maps are not designed to be chained like in the real story. Some are just for fun, others are real challenges, and the last one is a technical demo for other maps developpers X)

So yeah, maybe I will try to follow more the "do this test, for science" idea ^^

And about DaMaGepy's maps (that are really cool and well designed), I know that you can't make a really interesting parallel story by using only the ingame editor ;)

Keyserson

17 май 2012 в 12:36

@geneosis At any rate, the 'remember Portal 2 has a story' rule is just a way of saying 'keep players within the world of the story, don't let them get stuck etc...'

That said, if anyone wants to throw in some windows allowing players to see into space, as per the fantastic Cave dialogue, go ahead!

Juju Crente има Portal 2

17 май 2012 в 12:49

Loved your guide! I've used my brother as a test subject and as he played i could see many bugs i fixed later. Its veru good to have someone to etst your maps :D

Keyserson

17 май 2012 в 13:10

@Sowee Playtesting is invaluable - if you get anyone else to playtest your map, ask them to record a .dem for you.

For anyone who doesn't know about .dems, I'll update the post.

edeslash

17 май 2012 в 13:27

The part about not making players manually restart needs some re-writing.

OsboSD

17 май 2012 в 13:31

please tell us about .dem's :)

#10

Keyserson

17 май 2012 в 13:37

Have added a bit about .dems to the post

#11

Keyserson

17 май 2012 в 13:37

@Edeslash How so? :)

#12

Ammypendent има Portal 2

17 май 2012 в 13:39

Good reference, nice to see this stickied in the discussion here.

#13

edeslash

17 май 2012 в 13:46

The two points kinda repeat each other and in my opinion the story point of view is... well, pointless. Menus even belong in Aperture's Testing Initiative. The reason for avoiding restarts is that it ruins the flow of the level and all the fun.

Otherwise it's nicely written.

#14

Catsy

17 май 2012 в 14:02

I mentioned this on the forums, but I think there ought to be some distinction between things which are true design flaws by any objective measure (such as broken puzzle mechanics, solutions that can't be reasoned out from what's visible to the player, or killing the player in ways that are unavoidable without knowing about them in advance), and subjective thematic, style or gameplay preferences. Laying down rules about when one should or shouldn't use the Companion Cube element strikes me as an example of a very subjective point. Not everyone will want to play levels for the story aspect--for some people, it's just a puzzle game. Their preference isn't "wrong", it's just different.

#15

< >

Показване на 1-15 от 467 коментара

На страница: 1530 50

Дата на публикуване: 17 май 2012 в 10:34

Публикации: 467

Създаване на нова дискусия