I was writing

bye.

The site had zero credibility and no validity at all.

 

Looks like a nice archive of articles about level design.

But where are these problems you are talking about, and presumably some proposed solutions?

 

No it's fine, I misunderstood your initial post.

 

I haven't read the whole thing, but here's some feedback from what I have read.

You mention here that you have "some experience with unreal and quake", but what is that experience? I didn't see it mentioned on the site with your articles. It'll give context to some of what you're saying. For instance, if you mostly made team deathmatch levels that's quite different experience to someone who focused on linear narrative levels.

You seem to analyse everything as being "good" or "bad" without consideration for the underlying design goals of their parts of the game. I get the impression that your idea of "good" is that "the player is always able to obviously see what to do next". For some games that's true, but not for everything. Designers may be working towards other goals, and I don't see any acknowledgement of that, what they might be, or how those other goals can be achieved.

For instance, you criticise one level's design for having too much blood drawing attention to an area while obfuscating the object players need to find. However, this may not be "bad" at all. If a design goal was to have the player search for things then that design nailed it - it tells the player where to search without defeating the act of searching in and of itself. And judging by that one screenshot the clues in the search were great and included some environmental storytelling to boot - the person the card belonged to was killed while trying to use it, so there's lots of blood (explanatory + draws attention to the area), a dead body (explanatory + clue in search) and the card is in their outstretched hand (explanatory + final clue).

The other thing that stands out to me is a lack of suggested solutions to some of the issues. There's decent discussion of what the issues are, and then... it moves on. Just flipping the order of your articles could be useful for this. Show the bad stuff, then show the good stuff and explain how the previously identified issues are solved.

One example that stood out to me is the scripted event of the demon flying over the bridge in your pathing section. You say that narrative games can't use that approach because it confuses navigation, but you don't suggest anything they could have done instead.

Often in game design we're trying to solve more than one thing at a time, and may have to compromise one thing for the benefit of another. Leading players into a dead end isn't necessarily a bad thing if we want them to explore levels, using our navigation systems to call attention to narrative elements may be intentional and beneficial, and often it's a success when something is consistently solvable without being obvious. These are all valid design goals a level deisgner may have.

None of that is to invalidate what you've got there. It's all a perfectly valid take based on some context and some set of goals. Clarifying that perspective would probably be useful, though, especially for newcomers to level design who may read it.

 

You are welcome. I think the main issue is that I may very well be missinterpreting stuff and not clearling expressing myself. I'm constantly trying to rewrite things to make it better.

 

I did mention that, sometimes, having to find the path is desired because the context might require it.

The next step is going to adapt Mark Rosewater's 20 lessons from making magic to level design. He talked at GDC years ago about 20 lessons that they learned over the years and I think that all of them are true for level design as well. One of them is a mechanic may direct the players to do things that they don't want to. The same thing can happen in level design with a level that forces players to do something that they don't want to, such as standing still for too long. But that depends on the game, some games are slower than others.

 

My input is simple, you write about this alot, but how much "hands on experience" do you have?, without quoting or "riding off the back" of others?. We devs deal with issues/thoughts like this daily, really, no offence, but what have you done besides write about it?. I can write about any subject, no matter the content, show me your work 1st, then i may take validity in your writtings...

 

lol

 

There's nothing wrong with critical analysis from non-developers. In fact, I find such analysis to be really useful because it helps to understand how non-developers see things. So as long as the context is clear I don't think it takes validity away at all.