Beta Check List

[Fidcal]

This thread is just an idea that's been nagging at me to try out and see if it's worthwhile and perhaps put it on the wiki or link to it from a sticky if there are enough items.

 

TDM has so many features it's easy for us to overlook stuff. I'm beginning to wonder how many things I might overlook. Beta testers might draw our attention to these oversights but not necessarily.

 

We're not going to forget to do the obvious things like do a briefing and I think the shop is default (is it?) but post anything you think we might not remember to consider.....

 

AI relight lights: I think by default they don't so set this on any lights you want AI to relight if extinguished. (electric as well?) You might do this as you go along but it most likely nearer beta when light positioning, gameplay, and story are finalized. [link needed]

 

Droppable Keys: Consider making non-critical (at least) keys droppable to reduce inventory clutter. I think by default they are non-droppable. [link needed]

 

Dummy doors and Real Windows: I've put these together. Even if, like me, you like all doors to look real whether they work or not then still review any especially awkward to reach doors to see if they might be particularly annoying. Not sure what you can do always though. Also check any real windows or special access are not annoyingly overlookable. For example a dozen high windows look identical but one can be opened. Maybe most players ignore them all? (this might be OK for a bonus easter egg or something but sometimes annoying for anything mission critical.) All these are a matter of individual beliefs and judgment and very difficult to set precise rules for every situation [link needed]

 

Visportal and pathing testing: Always alert a guard and have him run after you through all the visportals in the map. VP might be broken and a solid wall for the AI. There might be too deep hole beneath a patch ground so the AI cannot follow. Be sure the AI can run after you everywhere.

 

Extra SFX Adding sound effects add life to a mission - especially to city streets. A large amount of voices, creaks, bangs and crashes can lift an area as much as good lighting.

[Sotha]

I feel inclined to challenge this:

Droppable Keys: Consider making non-critical (at least) keys droppable to reduce inventory clutter. I think by default they are non-droppable. [link needed]

 

A player is most likely reluctant to ever drop any keys. A mapper knows that key is not needed anymore, but think about it from the player POW. How can he be sure he won't need that key anymore? He cannot possibly know! It isn't a big burden to carry that, just in case.

 

Instead of making keys droppable, maybe mapper should consider

A) Designing the mission in a way that it does not require hunting million keys for unpickable locks. A few of such key/doors are fine, but too many is simply poor design. (IMHO. Feel free to disagree.)

B ) Scripting work so that the single-use keys gets removed from the inventory and destroyed once at the moment when the door is unlocked.

 

For the betatesting check list I recommend:

 

Visportal and pathing testing

Always alert a guard and have him run after you through all the visportals in the map. VP might be broken and a solid wall for the AI. There might be too deep hole beneath a patch ground so the AI cannot follow. Be sure the AI can run after you everywhere.

 

Read your readables

Carefully read through you readables. Check language. Check for missing last lines in a page (dr readable editor buyg.)

[stumpy]

floating entities, either over the ground or not attached to walls, ceilings, roofs or placed against something the wrong way around.

 

embedded entities, entities too far into another entity, or objects that fall through tables, beds when you pick them up.

 

dodgy entities, where its possible to empty a safe without unlocking it first, or a locked chest, or a locked box. Or you open a double door to find a black sheet in the double door hole caused by visportal in wrong place, or a screen door with a visportal. Or two doors counted separate, but too close together, so that when you open one both visportals open and one where both doors are open you close one and both visportals close.

[Fidcal]

@Sotha:

 

Well, we'll always disagree about keys but staying on-topic, I emphasize non-critical keys so if the player loses such a key it's not mission-breaking. Anyway, my view now is that it is actually very unlikely to accidentally drop a key in TDM because drop only puts it in the carry position. Plus dropping doesn't automatically mean losing as often you can pick it up again. The point of this thread is for mappers to *consider* such things according to ones views. The auto-remove idea is a special thing and I'm not sure it fits a general check list.

 

I'll add your visportal idea. A failed patroller is obvious but failing to reach a non-patrolled area is not.

 

I'm not sure about readables though. Mappers should check readables anyway. Unless we want this to be a general beta check list? In which case the list will be very long indeed. I was thinking more of the less obvious or feature things.

 

@Stumpy:

Same here. All good ideas but general testing.

 

Now this has got me wondering maybe this thread should be general checks. I'll see what others post and probably add all these ideas to the list. It wasn't what I was originally thinking. It was just these new things like AI relighting torches I was thinking I'd likely forget because they are features but not necessarily things one would want to set early.

 

This reminds me: Suspicious objects. This is another 'feature' you might be unlikely to set early but wants considering near the end. Like the prominent crown in Chalice.

 

Add to that - suspicious doors. (I think that now works?)

 

 

note to self: consider split list in two - general check list plus forgettable features that probably want setting at the end.

[Sotha]

@Sotha:

 

Well, we'll always disagree about keys

 

Aye. It is nice that not everyone agrees on everything.

 

 

I'm not sure about readables though. Mappers should check readables anyway. Unless we want this to be a general beta check list? In which case the list will be very long indeed. I was thinking more of the less obvious or feature things.

 

Yeah, I got the impression that the list is a general betatesting checklist to aid new mappers/testers to betatest the mission. "Go through this list and your mission is most likely free of nasty bugs." Mappers could require their betatesters to read the list through to know what to look for.

 

But it is your project, so it is your decision what you want to accomplish with this.

 

To aid, I'll copy paste here my Betatesting Document, which I always require my testers to read:

 

The basic idea is to

 

1. test the mission for errors

2. log things causing unenjoyability

3. improve the mission to its highest gameplay potential.

 

 

In practice, you play the mission through like you normally would.

If you see z-fighting or any other obvious mapping errors, take a screenie. It might help to draw some arrows with your favourite image processor in the screenies to make issues more easy to spot.

 

Be critical and try to find

 

* grammatical errors

* monster_clipping errors/AI's getting stuck

* general mapping weirdness and errors

* floating objects

* or any other factors reducing your gameplay enjoyment

 

 

Keep a log of all the issues you encounter. You could also log the maps finest moments if you like: they will help me to pick up liked things for the future (and increase my general motivation).

 

In my opinion betatesting is NOT about flying the map through quickly with noclip and report few aesthetic issues: "This building is unrealistic", or "there is z-fighting in the roofs (where the player cannot get by any means but noclip)" etc

 

After playing the mission normally, I'd really appreciate it if you had the strength, persistence and courage to play it again with the evil intention of breaking things: try to do unexpected things. Be in the wrong place at the wrong time. Try to get to places the mapper did not intend the player to get. Try to get stuck in the rubble. Try to break objectives and get away with it. Try to find holes and errors in the scripts etc.

 

Then you prepare a report with your favourite word processor with embedded screenies, issue reports and improvement suggestions. Then you convert the file into a .pdf and upload it to mediafire (or some other location) so I can get it.

 

Then I go through your suggestions and improve the map if I deem the suggestions important or otherwise relevant. I do not usually make big aesthetic changes anymore in the beta-phase: it is all about fixing errors and improving gameplay.

 

I'd like my betamappers to work independently without checking each other's reports. The reason is that that way I get really good indication how critical the issue is: if everyone complain about it, it is huge. Also the things one betatester says may alter the perceptions of others and generally I am interested in Your impressions.

 

So far I've also only had one betatest run per map. So most likely you only need to do betatesting only once, so it is good idea to do it as well as you can.

 

So far I've always used only three or four testers, so this also increases the importance of you doing it right the first time around.

 

That's it, I hope I do not demand too much, but my previous betatest experiences have made me feel it is important for me to let you know what I need and expect.

 

And thank you for your help!

 

[jdude]

There was a command to view in-game where the AI are computing they can go. It would show square one the ground with numbers above them for about 2 seconds. I can't for the life of me remember what that command was but it was extremely helpful when mapping, it allowed you to easily see where AI could go and how you could easily optimize the map. Could anyone give me a hand with this, it's likely not used by much in mapping which is a shame. AI can cause big fps drops if not done right.

[jaxa]

Drop key objective -

 

To frame person X objective would have you select the key, frob the desk/bin, and have the key magically appear there, immobile. That way there's no way you could drop (or throw) the key down a drainpipe or other inaccessible area.

 

Other feats.:

 

Rope swinging

Mines/flashmines (which are almost fixed)

Water currents?

Ability to light candles/torches using object manip or fire arrows

Edited June 29, 2011 by jaxa

[Fidcal]

Well, one can extend this check list to consider every single Dark Mod feature and idea and concept so I'm more confused about what it should be than ever. It could be a reminder to check if you have considered every weapon and player tool, should you add rats? random paths? animations? archers? I'm losing my way here.

[jaxa]

Give me minutes

 

checklist.html

 

Sit down with paper or Notepad and divide the various things a mapper should look for into separate categories. Include features that were introduced in 1.06 or 1.05, etc. near the top of the list. Then send me the tips/categories or just edit the file. Simple tabbed javascript. May be possible to include something like this in the wiki, wikis do use javascript for various boxen.

Edited June 29, 2011 by jaxa

[jaxa]

Alternatively, you can give each tip/suggestion multiple categories ("tags", version numbers would be a separate category) and I could use JavaScript to render the tips. I could also make actual checkboxes that trigger a cookie update making it conceivable for a mapper to click on checkboxen for finished items, come back to the page later, have finished items hidden, and look at the remaining items and work on them as needed.

[Baddcog]

I'd say start with the most important things first:

 

1: Do all objectives work?

2: Does mission end?

 

then on to the list of things to watch for:

 

3: floating/misplaced objects

4: grammatical errors

5: stuck ai

6: general bugs

 

then impressions:

 

7: what do you think of mission overall.

a: storyline, easy to follow, etc..

b: lighting/shadows

c: ai placement

 

------------------

With testers you don't want to get too technical, keep their impressions simple from a players perspective.

 

if you need technical feedback find a mapper specifically.

[Fidcal]

After consideration I've decided to keep the first post as originally intended. Not as a review for the inexperienced but a reminder for experienced mappers. We are not going to forget to do readables nor should we need reminding to check them properly. But we get into a routine. We are not going to forget to add and set up lights well. But there are things, especially new features, we might not think of such as AI relighting torches etc. Maybe this is personal to me. I started wondering if I was going to remember all this stuff.

 

But the rest of this thread can still be used to add any other general beta tips of course and anyone who wants to add this to the wiki feel free.

[jaxa]

If you have available vine arrows, check to make sure that you control what walls can be climbed (some linearity is required).