My issues with custom 'Quake' maps design

I am not a mapper myself, as for now, but I do make my observations while playing some of the content available here on the ‘Quaddicted’ portal. There are certain recurring design patterns that I see present throughout the creations of various mappers; the patterns that I personally, deem flawed - albeit, it is only a case of personal opinion. Here are some of these patterns, mentioned in random order:

  • Key following key. What I mean by that, is; in case there are two gateways, both requiring keys to be opened with, respectively; the second required key - in the issue discussed - is available right behind the doorstep of the first gateway unlocked, as if proclaiming: no further content here. It makes bad impression, questioning the purpose of the two gateways altogether, as apparently, one would already suffice - since the second key, is nearly just a “bonus” to the first one. The essential problem, is that of redundancy in design.

  • Dead-end puzzle. Progress throughout the map, should have certain momentum - ideally speaking. It ought to be intuitive or easy to spot in terms of what to do next for the player. That means, the player, is not to be stopped with an impression of a situational deadlock. Common fault in this case, dwells in overt distance between the trigger and the effect; such as a button unlocking an oddly placed gateway, with long backtracking in between. Other fault, may emerge from an overt complexity of a map, making the player confused about what exactly has happened in the aftermath of an action. Occasionally, a deadlock, may be generated by resources insufficiency - which equals improper difficulty balance; but this, is a separate world of problems.

Sometimes, in order to progress, one must find a passage that is hidden as well as an conventionally proper secret location, which leads us to another fault-pattern:

  • Crucial secrets. Secret areas, are meant to provide boost to the gameplay progress, not to make the progress doable altogether. If the gameplay progress, is a hostage to the player effectiveness at finding secrets, then we deal with a severe case of “dead-end puzzle”. The stage, should be doable without finding any secrets, at all. That is how I see it, at least on the “Normal” difficulty.

  • Obscure narrative feedback. The narrative feedback, is the text one would see in the middle of a screen display, while playing ‘Quake’ - not to be confused with the engine feedback, appearing in the upper left corner of the screen. The narrative feedback, is a tool in the hands of a mapper. It is a one-sided, direct communication pathway between the mapper and the player. The mapper, may decide to entirely skip the use of narrative feedback, but then, it is mandatory to make sure the symbolic representation of map dynamics, suffices for all. The issue I want to point out, is when the narrative feedback, when used, simply does not tell anything of use, despite using even a lot of words. Likewise, announcing things the player can perfectly figure out independently, fits into the framework of redundancy faultiness. The obscurity case, in turn, may be rooted in lack of both the precision, as well as the background meaning. The background meaning, is built through adequate naming and describing of things. Instead of announcing: “the gateway has opened”, maybe it would be good to precise that: “the gateway has opened in X” - where “X”, could be, for example: “the Atrium”. What is “the Atrium”? This, is where things start to connect - first, we need to have clear information, what or where is “the Atrium”; ideally having been informed with a similar, proper narrative feedback, bestowed upon visiting of an area. If a map is vast - especially when it is vast - giving names to specific hublike locations, is perfectly fine, I imagine; as long, as the player, is not being spammed with constant text throughout the continuum of gameplay.

To summarize, with narrative feedback, aim to: (1.) be specific; (2.) build a meaningful web of notions, on top of visual layout; (3.) be adequate - too much is as bad as too little.

  • Indoable challenges. There are maps, which clearly have not been designed for simple, conventional gameplay - alternatively, maps which have not been sufficiently playtested and corrected. If a map, is not completable outside of cheating or ridiculous skill application; eventually if a map, is downright incomplete, such as lacking in functional exit portal or valid layout connections leading to an exit; it is not to be considered a map per se, but a mapping experiment and thus, invitation to play it, should come with a transparent warning. Inclusion of such maps in otherwise conventional bundles or even publication of such projects on common terms, should not be encouraged.

Final note or question, regards certain design trends, emphasizing on complexity of the layout and promoting explorative approach - which is good, to those willing - at the cost of gameplay integrity sense - which, in turn, is bad, in my view. I speak of maps that announce their exit portal at roughly 50% of the content having been seen by the player; concluding after the number of opponents persisting, in an example that I think about. Playing such maps, I feel somewhat odd at the completion - myself not being an ardent “secret hunter” - as if asking the mapper: what do you expect of me? We live in an era of information noise - take this into account. What is to assume, is that as soon as the exit route becomes legitimately available, the map, has expressed all the major owned qualities by then; which I know, is to be a false assumption in many cases. What remains, is a question of presentation - but I do get the other side of the spectrum, is a cutscene.

More observations:

  • Faulty elevator setup. This reiterates in many forms even throughout the maps of otherwise excellent design. In the case discussed, elevator is designed in such way that even slightly off a stance on the platform in one such, results in damage having been taken by the protagonist through an object collision, as the platform attempts to go. It is mostly due to overt amount of inwardly orientated ornaments in the elevator shaft - but this applies to all sorts of corridors, through which an automated platform is meant to carry the protagonist through - that causes the faulty effect. Solution I can imagine, is to either make the shafts as plain as reasonable or use closed-cube elevator types. Additional quirk to the setup, which also does summon some issues, is a faulty placement of elevator trigger button; these are sometimes placed in such way, that interaction with one, exposes the protagonist to incidental damage from a moving object, such as the elevator platform, again. There seems to be lack of consensus among the mappers, what kind of elevator trigger way works best and how it should be applied for most handy result. I consider this problem a work in progress in the concepts of design; quite a long time does it take to figure out, assuming ‘Quake’ is already 25 years old.

  • Randomness in symbolic communication. The traditional ‘Quake’ formula - ideally speaking - aimed to build or maintain certain symbolic code of communication between the mapper and the player, especially with how the secrets are being announced. Finding secret, was to be a case of pattern recognition, more than hunting down a needle in a haystack. Yes, there were needles in a haystack - like shoot-triggers placed in very nuanced locations - but such secrets, are already hard to find, since in order to find them, one must practically examine every inch of obscure architecture the mapper has built. It plays oddly with the fast paced combat and dynamic gaming style the ‘Quake’ does offer. I would rather the mappers returned to the ideal of pattern recognition, in which it is more about being able to recognize what is being told through environmental design or specific, intended quirks in that design - available in plain sight - rather than about trying to read the mind of a mapper, which could be hard for non-mappers or those not patient enough to tour every stage in great detail.


create a map

I think triple_agent a well known mapper anyway, although he says no in first post. He tried to find solution of issues interesting rather mappers not a players in general.

Hurting elevator button is an annoying issue of quake design. It causes even on maps of experienced mappers. Somewhere I see an elegant decision - buttons are located in a vertical niche. I think about decision by the next way: button should stay pressed until elevator still rising and released after it stops.

Gentlemen, I was certain someone would sooner or later challenge me to create a map, if I want to even talk about the works of others. No, I am not a mapper, have not created any maps for digital games. You have to remember, though, that art critics or art reviewers, do not have to be artists or directors themselves. ‘Umberto Eco’, a writer, once said that - as far as I remember - writers, divide between those who have great achievements in what they do and those who have great awareness or observation skills, regarding the work they either do or are interested in.

I might have profaned the statement of ‘Umberto’ a little bit, but the basic premise, is still there, I believe. Either how, respectively, the first in the example, make - understandably - for great writers. The others, make for great teachers and great reviewers. It is not impossible to be an all-merit-man, but it is not something we encounter often in life, is it? We are used to limitations and compromises, which is why, that is also what we should expect.

People naturally lean towards things they are more comfortable with. If I was to make a personal note about myself, I would rather be a modder, than a mapper in ‘Quake’-scape; even though many mappers, are modders as well - which does not negate the fact that many maps, base on already and separately existing mods.

Another analogy of the situation - even if to assume I was able to make, theoretically, some acceptable quality ‘Quake’ maps - is that sometimes, it takes to step back and zoom-out, in order to get a grander picture; so as to be able to provide more relevant feedback to those around, while they are zoomed-in; perhaps also in order to gather more relevant intel about possible next steps to take.

I am a believer in the “help-me-help-you” setup. Here, it boils down, ideally speaking, to the status of making maps primarily for my own, individual, artistic therapy. Then, resultantly, I could share those maps with others. If I have not been doing that, why would I start making ‘Quake’ maps in the first place - because of you? I am sorry, but that is just bad motivation, with very slippery terms of reward.

Finally, you are great mappers, you make maps. Do you want audience for these works of yours - or do you create only for your individual sense of satisfaction? I do believe you want to share your works, for others to create “life” around these. If this what you get, is not what you expect, tell me then, what do you expect?

When it comes to the elevator buttons, I think such “mandatory” options, would be better off, if located on the ground, on the way towards the elevator. Sometimes, one may not wish to trigger the elevator but to peek into the shaft first, so it is up to the mapper, to make room for that. I saw such solution in one map - linked - and in my opinion, having it done that way, works just fine. In turn, there are plenty of practical problems with elevator buttons placed on vertical surfaces, especially on the wall inside the elevator shaft.

Perhaps a trigger button, alternatively, could be placed on the floor, inside the elevator shaft, in a way making it part of the moving platform.

Possibly a thing more of personal preference, rather than an actual issue - is the matter of tight spaces in ‘Quake’ map design. Due to gameplay or engine related factors, ‘Quake’ appears to do much better with spacious areas, rather than with tight and claustrophobic design - the latter, primarily involving corridors and cramped rooms.

Even though tight spaces could be useful and occasionally applied; certainly good for highlighting contrast or to announce the chance of some malicious traps occurring - part of symbolic communication code, perhaps - I do not personally believe in the claustrophobic way, to be the optimum in making use of what contemporary ‘Quake’-scape, has to offer. In other words, I think there are better engines for intimate dungeon-crawling or “realism”-inspired interiors, than the classic ‘idTech’.

Minding that observation, I would call “capitalizing on the awareness of shared technological limitations”.

The issue of unsolvable combat; in which case, the player, is meant to decide for skipping an encounter and rushing past by the enemies, in order to either find a suitable weapon for later re-encounter or to entirely give up on defeating all of opponents, present on the map.

While I do understand such situational configuration, could add to “realism” factor, I do not particularly believe that majority of casual players or even players in general, find it attractive - including myself. Being fans of first person view shooter games, we are used to simply defeating all of foes, present on our path and not being able to do so, could qualify as a dead-end puzzle, already discussed earlier.

Definitely, the case of unsolvable combat, should be considered beyond difficult.

The issue, does not include actual puzzles, in which an enemy, can only be defeated with the use of environmental factors; as long as it remains a reasonable challenge.