Quote from Lukavian on May 21, 2011, 12:32 am

The end goal for this, btw, is that the player will have to work their way back up to the "exit," the door they see almost immediately after starting. The process of getting back up will involve several smaller puzzles, some of which might be interconnected. Hence, it's important to note with v1_1 that this is NOT a final look for this drop. Much of it will likely be non-portable surfaces, flipped with panels and such later to provide puzzle elements. It'll also be much longer, perhaps "wormholing" (architecture term meaning that a tighter hallway space opens up into a much larger area, creating an amplified feeling of space) into a much larger basic chamber. The purpose of the glass is really just to keep additional runs from exploiting any portal placement angles that the rest of the level doesn't provide. A later version may also have a much longer glass shaft, accompanied by a larger alcove. That all depends on how the level finalizes.
glass mover
[spoiler]In case anyone is curious, the two-part glass movement is the result of a dual-arm process that I sort of hacked together, not really expecting it to work. The trigger pad just under the glass sends the initial arm movement signal, then sends a signal after 2 seconds for the glass assembly to unparent from the first set of arms and parent to a second set, deeper in the alcove you see when you first start dropping. The large sliding panel itself is just a func_door set to a slightly higher speed.

For those who don't noclip around, I actually did a bit of optimization at this point. Once the sliding panel is in place (or, rather, after about 6 seconds, which is the approximate time it takes for all the movement to resolve), the glass and all four arms inside the alcove are removed from the world. It's a small element, really, but it's a few less entities for the system to track. I'll likely use similar methods elsewhere in the map.[/spoiler]

Quote from Ruien on May 21, 2011, 1:56 am

I think this is really cool. [spoiler]I had to play it a couple of times to really even realize the glass was there though, because the initial drop catches you completely off guard and you're more interesting watching to see where you fall to. But I do see the purpose and think it's a good idea and well-done.[/spoiler]

Quote from Lukavian on May 21, 2011, 3:42 am

Ruien wrote:

I think this is really cool. [spoiler]I had to play it a couple of times to really even realize the glass was there though, because the initial drop catches you completely off guard and you're more interesting watching to see where you fall to. But I do see the purpose and think it's a good idea and well-done.[/spoiler]

"God is in the details." It's kind of necessary, too, for the final product. Eventually, the player will be coming back through this space, and generally there will be need for some explanation of where the glass went. Just having it disappear is a bit crude. I'm not sure if the differently-colored panel will be enough for the majority (like you said, the initial fall catches you off guard, and the glass isn't exactly the first thing you think about...in later versions the glass will probably be extended further).

Thanks!

Quote from kwp21 pitts on May 21, 2011, 7:36 pm

Just a quick suggestion, I would reccomend putting up a screen shot of your map. It would encourage more people to download your map.

Quote from Lukavian on May 22, 2011, 5:33 am

kwp21 pitts wrote:

Just a quick suggestion, I would reccomend putting up a screen shot of your map. It would encourage more people to download your map.

Thanks for the suggestion. I've considered it, and probably will tonight, but I just haven't had an idea of what to "shoot." Really isn't much to this map yet, nothing that would make a good screenshot at least...
I'll poke around, see what I can find.

EDIT: Good enough for science. Not that a full screenshot can compress down to 178x134 without losing almost everything it had. At least with my lack of photoshop/image polishing skills. Oh well.

Quote from Lukavian on May 25, 2011, 7:40 am

Somehow, v1.1.2 seems to never have actually registered here. Not sure what happened or why, but oh well. I have this next update anyway.

Now, some may criticize (if they're tracking this project) that my updates are mostly very small and pretty unimportant. I can't disagree. What I'm doing, for the most part, is testing some of the more experimental elements of the map itself, most of which are in the introduction, and seeing if there are ways to make it better. cont.
[spoiler]The trapdoor element and the glass tunnel retraction were in the first upload, and were mostly there just to see how people liked the idea itself of a map starting with a simple hallway and ending in a deep pit. The glass was there to prevent exploits for people who had run the level before, and will continue to be an element in the level, even if I make the glass structure larger as a whole. The sliding wall panel was also in the first upload.[/spoiler]

Anyway. This update exhibits a short, ludicrously simple puzzle that makes access to the exit possible. This is, after all, a test. What good is an (actually) impossible test? [spoiler]Basic flinging in two instances, plus a simple button-affects-arm/panel construct. All of which has guidance lighting, making each of the elements very obvious. There's a scripted event to activate a spotlight on one of the vital walls.[/spoiler]
There are also a number of cosmetic/lighting changes, and the shift from a big portable-wall pit to a big non-portable-wall pit. Not sure how people will like the wall textures in the main pit room, happy to get any feedback on that.

For posterity, terminal velocity seems to throw you approximately 950 units out of a portal. That was important in my development process, so anyone else who builds maps and is interested, now you know.
mechanics
[spoiler]This is mostly for other mapmakers, anyone interested in knowing my process for this.

The sliding panel I think I've expounded before, just a func_door. This presented a problem with portalling, however, as door brushes are not portable. I ended up just putting a nodraw-portable brush overlaying the thing. I will probably parent said brush to the sliding wall later, not that there are many ways to exploit it...mostly just looks odd if you have the experience with the map to watch the door shut, and make a portal on the open space before it finishes sliding. There are a few other options for how to make that work, may explore them, but parenting so they move together is obviously the simplest, and Occam's Razor leads me thence.

The light cast on the panel/wall was actually one of the trickiest, most frustrating elements of this iteration. I tried using triggers on the door (OnFullyOpen; the door has a weird quirk where it thinks it is closed at start and must open, as the other way around started with the panel covering the space and jumping around strangely), and telling the lights to toggle. When that didn't work, I then tried simply killing the red lights in the falling shaft, also to no avail. Finally I just abandoned them and decided not to worry about it. A bit of research showed that naming lights causes additional compile times and problems anyway, so I just ditched it all. The spotlight is good enough, I decided...despite not actually having an apparent world source (a problem ALL my lighting has so far...one issue at a time, like the elevators).

I noted the distance that terminal velocity will fling. Finding this number was kind of an interesting process, one I did using some very soft lights (created in a static pattern of colors and given a slow flashing fade pattern), which were set at vertical intervals of exactly 100 units, starting at the ground level. I then flung myself at terminal velocity, and activated noclip when I reached my apex. Noting which colors I was at/between, and about how far between them. Then it was just a matter of going back and counting how many lights I'd gone up and calculating the total number of units. My findings actually contradicted other findings on this site; one person, using the original Portal, found that terminal velocity flung approximately 1260 units. Perhaps it was an engine update, perhaps it was my/his testing method, I don't know. It isn't vitally important. What I know is what I found. The Source developer wiki didn't actually have information on how far terminal velocity would fling, which I found interesting given how often flinging at high velocity is used in the Portal series. Not even in a side or footnote.[/spoiler]

Updated the screenshot as well, to reflect the new pit textures.
Thanks for playing!