Screenshots of "Try Anything Twice"
This is SO GREAT.
Work harder and faster. NOW.
(Also, I saw that you're online. Maybe to release this?)
Hi, thought I'd post a short status update in here, since I haven't been around the site lately. (Vacation and stuff.)
First beta release is still a long way off. I'm now working on the laser mechanism for the fourth chamber, which is a lot of work. The first version was pretty limited, I had basically restricted portal placement to a few pre-determined spots so that I could map out every possible path for the lasers, but that would take away a lot of the free-form nature of the game.
The current version will use a series of templates (one for each straight beam) that can bounce off of mirrors, go through a portal, perhaps bounce off some more mirrors and then hit a target that activates something. If I can pull that off, it would add an entirely new dimension to the game.
Also, I'm happy to report that I managed to reduce compile times for all of my maps to 1/10th of what they were before. That will sure help to get this thing done in a reasonable amount of time.
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
Best of luck; from what's described, it sounds like you've got a bit of a fight ahead of you. Out of curiosity, how are you planning to make the laser work (I understand if you want to keep it under wraps until the map's released, though)? The only way I can think of to make it work involves a BOATLOAD of func_portal_detectors, env_lasers/beams, and logic_autos; it's insanely complicated, even worse, it gets exponentially more intricate as it is made more realistic and dynamic.
On another note, do lasers carry through portals? I know the rocket turrets' lasers do, but that might be a coding trick... If env_lasers/beams carry through portals, it might make the entire chamber much easier to construct. Unfortunately, I remember hearing somewhere that they couldn't. Ah well. Once again, good luck; I look forward to the map coming out.
Now with 100% more inline comments!
Nope! That's the main problem. The turret lasers are coded into the game engine so that they traverse portals, but the regular env_lasers just ignore them. Another problem is that there is no way to detect what a laser is hitting, except for setting the laser to deal damage, and I don't want that.
For those who are curious, here is how my current system is (hopefully) going to work:
- Each laser source spawns a template, which consists of, indeed, a boatload of entities. Each template instance, when created, fires off a tiny invisible cube (a func_physbox) that travels in a straight line along the beam. (The whole map is wrapped in a trigger_vphysics_motion that disables gravity for these tracers.)
- When the tracer hits something, it teleports the laser end point to its location. It also has a tiny trigger volume attached to it, so it knows when the obstacle in question moves out of the way. If that happens, or if something else crosses the beam, the template instance is destroyed and replaced by a new one that traces a new beam.
- Special things that re-direct the beam, like mirrors and portals, have triggers in front of them that stop the tracer, activate the beam and then send another beam out in the proper direction. For the portals, there is a func_portal_detector enveloping the entire map, that moves two trigger volumes around to follow the blue and orange portal. (I'm not sure yet what's the best way to create proper reflections for the mirrors. I'm debating whether to limit the lasers to orthogonal directions, that would make things a lot simpler, also for the player.)
- Lastly, the origin of each beam has a trigger volume that detects the tracer of the incoming beam, if any. When a beam section is destroyed, its tracer disappears and causes any following beam segments to disappear as well.
I don't intend to keep this secret, but I left a lot of details out of this description to keep it understandable. I probably won't release a separate example map, as there are still many uncertainties that I'll resolve as I build the test chamber itself. (For example, I'm not sure if players will be allowed to place portals on floors and ceilings, as their arbitrary rotation messes things up.)
I will include the source files with the final release, so then everyone who wants to use this in their own maps can do so.
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
You can set it to deal damage, but damage setting should be zero. Would it show up as a damage?
I have posted a beta version of the first three chambers on myApertureLabs. Check it out!
Please post any comments either on this thread or the related comment thread on mAL. (I'll be monitoring both of them.)
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
Downloading.
I like your style, just by the way.
Okay so here are my preliminary observations.
Before I start to sound too critical I'd like to say that this is the first time I've ever played one of your maps and I admire the visual style. It's true to the overall feel of Portal but still unique enough to feel fresh and different. 
Just a note, you should place a quicksave if possible after the first test chamber. It's not too big a deal, because once you work out how to do the first chamber its very quick and easy to do again but it's still an unnecessary exercise.
I actually got stuck on the next chamber. I'm pretty sure I know what to do but I'm finding it hard to meet the time constraints of the puzzle. Actually the major issue I see with this chamber is that we've gone from chamber one with two buttons to a chamber with at least 3 buttons, 4 ball sockets, 3 switches, a moving platform, etc, etc. (and that's just in the first half of the chamber). I think it's a bad idea to suddenly hit the player with a puzzle with that many elements especially when there doesn't appear to be any noticeable order in which each element should be addressed (in Portal you may remember the little signs with the dots on them). Your goal when designing a puzzle should be to make the player think without getting them overly confused and frustrated.
I noclip'd ahead to test chamber 3 and was delighted to see the concept behind it. I'm not sure if it has been done before in the Portal mapping community - and I won't spoil it for those who haven't played the map - but it seemed like something very clever and new, which I liked very much. The whole chamber was pretty short so I got it done quite quickly, but I would love to see more of this kind of refreshing gameplay.
Speaking of finishing the chamber, I used a fling to do that, and it didn't seem like the most appropriate solution, just the most apparent. Though, for all I know, it may be exactly what the your intended solution is. However, I bring it up because I'd like to quickly make a comment on unsupervised playtesting of beta stage Portal maps. Because you're testing a map to see if it's working correctly you need to know how the puzzle should be solved. If a playtester is not informed of the puzzle's solution and runs into a problem, there's no way for them to know if this is one of three things occurring:
- There is a bug in the map which has broken gameplay and needs to be addressed by the level designer.
- The problem is a red herring, inserted into the map to distract the player from what is important.
- The player is stalled because they don't understand what to do with the current gameplay element in focus.
Obviously this problem doesn't occur if you do the testing yourself but that's less productive and it's better to have a fresh set of eyes when testing the level. This is why playtesting on WIP maps should be supervised (and usually is in the games industry), especially in a game such as portal where the problems of level design and the problems of puzzle design become tangled together. Just a thought for anyone looking to do public testing on their pre-release maps. If you can, grab some friends you know and quietly watch them play your level in person. This lets you observe how players are likely to approach the level - which may not reflect how you thought they might behave - and will immediately highlight any issues for you to address.
Hi Nacimota, great post!
Before I start to sound too critical I'd like to say that this is the first time I've ever played one of your maps and I admire the visual style. It's true to the overall feel of Portal but still unique enough to feel fresh and different.
Thanks a lot! Many people liked the design of my first map, so I decided to keep doing it that way. (I originally intended to go for a more "classic Aperture Science" look.)
You're right, I didn't think of quicksaves yet. I should put some in before any public beta, even if they're not in the most ideal spots yet.
Many people on myApertureLabs found that chamber hard too. I'm going to rework that to make the solution a bit more clear (dot signs are an option there) and I'm also going to re-order the chambers to provide a better difficulty curve.
It has; RenTest. But to my defence: I only played that after making that chamber 
Speaking of finishing the chamber, I used a fling to do that, and it didn't seem like the most appropriate solution, just the most apparent. Though, for all I know, it may be exactly what the your intended solution is.
Yes, that's the way to do it the second time. The change that occurs for the second round makes it possible.
- There is a bug in the map which has broken gameplay and needs to be addressed by the level designer.
- The problem is a red herring, inserted into the map to distract the player from what is important.
- The player is stalled because they don't understand what to do with the current gameplay element in focus.
Obviously this problem doesn't occur if you do the testing yourself but that's less productive and it's better to have a fresh set of eyes when testing the level. This is why playtesting on WIP maps should be supervised (and usually is in the games industry), especially in a game such as portal where the problems of level design and the problems of puzzle design become tangled together. Just a thought for anyone looking to do public testing on their pre-release maps. If you can, grab some friends you know and quietly watch them play your level in person. This lets you observe how players are likely to approach the level - which may not reflect how you thought they might behave - and will immediately highlight any issues for you to address.
You make a very good point. I usually try to get a friend to play first and watch how they go about it, but even that doesn't always catch everything. If there's one thing I learned from the beta testing process of Manic Mechanic, and also from this one, is that there are huge differences in how people think and approach puzzles. Reactions run the gamut from "Nice, didn't have any problem at all" to "How the **** am I supposed to ****ing solve this ****?" At some point you just have to take the plunge and release it, even if it won't appeal to absolutely everyone. (But i'd like to make it so it appeals to as many people as possible 
)
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
so, i tried the beta, it's a great map, but i got stuck on the second level and the retry of the third, i've got the ball but cannot put onto the button