Quote from rendermouse on July 15, 2011, 2:17 pm

There are some issues where I would love players' input: (hidden in spoiler tags for those who haven't played the map yet)

One:

[spoiler]I don't like it when the replacement cubes "pop" into existence. I used an entity spawn instead of a cube dropper because these cubes have to be kept within their ComfortZone, and the standard cubedropper takes up a lot of room. I would love to have some sort of "fizzle in" spawn transition.[/spoiler]

Two:

[spoiler]If the partner cube (the one you're NOT holding) is released within its ComfortZone while it intersects a physical brush or entity, it will be ejected by the physics system with some force. This is because when picked up, the partner cube is parented to the held cube, and is therefore removed from the physics system until it is released. I wish I could simply add the partner cube to your collision box, so it would never pass through a surface. This is why they currently explode outside the ComfortZone, to prevent you from pushing them through a wall and dropping them out of the map.[/spoiler]

Quote from Brainstatic on July 15, 2011, 3:38 pm

Nice map, especially for you first one. The entanglement cubes are also very clever. By allowing limited access into the area where the partner cube is, I'm sure there are some even more potential puzzle applications.
As for the cubes spawning suddenly, you could parent lights to each cube that flash brightly as the cubes spawn. It's not a perfect solution, but it is an easy one until you can make something better.

Quote from xdiesp on July 15, 2011, 3:54 pm

Concept map for an original testing element, but despite the best of intentions the result plays kinda glitchy. First, the partner cube does only obey being carried around or falling, not other movements such as rolls after being thrown or being pushed on the ground, which brings the cubes out-of-synch fast. Second, narrow spaces seem to make cubes explode all the time while banally looking around (made the last test frustrating): I think this one needs vast rooms to work comfortably. So, tighten it as much as you can and we'll have a winner.

Quote from FourthReaper on July 15, 2011, 4:44 pm

I think this is a great idea with some puzzle potential, it just isn't getting much help from hammer's capabilities, making it all a bit glitchy. Also, instead of allowing the cubes to explode, I'd create some sort of forcefield forcing them in their Comfort Zone.

If this was (more) bug-free than it is, this would be an amazing addition to portal. Oh, and a nice name you gave it, too. Now you're thinking with comfort!

EDIT: Oh wait, I see you explained why the cubes explode in the first place. Guess the forcefield 'll have to wait...

Quote from rendermouse on July 15, 2011, 5:12 pm

Thanks a lot for checking it out, and for the constructive feedback. People are definitely used to working with the standard cubes by picking one up and then looking about. This, of course causes the partner cube in my map to rotate through a large arc, leave its ComfortZone and explode. There are times when you have to be careful to strafe when placing the cubes.

Do you think there is a way I could better message this or teach this to the player? I have considered placing a custom sign in the first room to remind the player not to allow the cubes to leave their ComfortZone. But the first explosion is actually a fun surprise, I think.

As for keeping the cubes in sync, I decided to use the physics/SDK parenting limitations and try to work them into the puzzle. So yes, the cubes are only entangled/linked when held by the portal gun, otherwise they are independent physics objects. When I kept them parented together all the time, the child would always pass through all geometry. The cubes are spawned with a known XYZ offset, but the player can force the partner cube to get repositioned by world physics (portals, dropping, funnels, platforms, etc), changing the XYZ offset. Then you pick up your cube again to "lock" that partner cube's XYZ offset. This was the prime reasoning behind the second and third rooms, which require you to let something external change the vertical offset of the partner cube in order to solve the puzzle.

I could definitely use some advice on how to present these concepts to the player in a simple way to prevent the frustration you experienced.

Quote from quatrus on July 15, 2011, 7:12 pm

Nice to see new effects tried. This one needs a bit more work or capability from SDK but it definitely has potential. Agree that would be neat in a bigger chamber (but then I love big rooms) and something other than exploding all the time... the last chamber was the best and the earlier ones were like training sessions. Well done... Thanks for creating.

Quote from Enigmaphase on July 15, 2011, 10:39 pm

I don't know if it was just me, but I was having incredible difficulties getting the cube to stay on the button - it kept popping off when I dropped the cube in my hand.

Like the others are saying, great idea, just needs some more work.

And isn't it more like macro entanglement than quantum entanglement?

Quote from Constructor#8 on July 15, 2011, 10:59 pm

this is awesome and I gave it a 5 just for the idea but like the others said it needs some polishing. The biggest problem is what you mentioned about the partner cube being ejected with force when it touches a brush or entity. Like enigmaphase I had trouble getting it to stay on the button in the first room. This can be solved however by dropping the partner cube directly in the middle of the button. When you do that it works perfectly. If you put an orange light directly in the middle of the button this might help the player grasp that but that's not really a great solution. Also in the last chamber every-time I got in the tractor beam to move the partner cube up it would explode when it reached the button. I finally had to get through it by portaling the wall next to the tractorbeam and jumping through so I could get under the tractorbeam and go up it. Then I just grabbed the partner cube and threw it onto the button. Good luck with this concept i'm gonna mess with it myself and see if I can find some solutions to these problems.

Quote from xdiesp on July 16, 2011, 2:25 am

rendermouse wrote:

Do you think there is a way I could better message this or teach this to the player?

You could also scrap the exploding idea save for specific destructo-areas, imho it's far more important the physics are airtight first (cubes being always in synch).