This the introduction to the new Quantum Entanglement cubes. A love story of two companions, forever separated by destiny.

Edited to work with the Steam Workshop.

Click here to download Quantum Entanglement 1

Click here to download Quantum Entanglement 1

&

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

One:

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.

Two:

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.

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.

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.

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...

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.

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.

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?

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.

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).

Thanks to everyone for the feedback. I'm glad people seem to like the concept, and I do agree that the cube linking still needs some work.

I guess I'm going to have to look into some way to link the cubes without using setParent.

That is the root cause of these collision glitches, since it is what disables/enables physics on the partner cube.

rendermouse wrote:
Thanks to everyone for the feedback. I'm glad people seem to like the concept, and I do agree that the cube linking still needs some work.

I guess I'm going to have to look into some way to link the cubes without using setParent.

That is the root cause of these collision glitches, since it is what disables/enables physics on the partner cube.

< Also had problems in the Funnel Room.

But your map Reminded me of my actual [WIP] Map which I should finih some time, but curse you Firelands !

I Loaded it Up for you (vmf included) so you could see how I did mine. They are a little different, but the concept is quite similar.

http://forums.thinking.withportals.com/downloads.php?view=detail&df_id=1084

But some things are still Problematic:
Portals+Multiboxes (or QuantumEntagledCubes if you wish) don't like each other much
How to Spawn Multiboxes (or QEC's) so it doesn't look unnatural.

Keep up your work

How about a Reset button in case of complex setups, to replace explosions?

I'm playing custom maps and record my first time of playing them. So the run is not perfect and may not use only intended ways, but maybe it can let you see how other people may understand the map or you could just enjoy someone playing this map for entertainment.
Anyways, here is the recording:

5KxrIblKZy8
(Link: http://www.youtube.com/watch?v=5KxrIblKZy8)

Also note the video description for more feedback and my signature for additional project information.

what the ...???
awesome idea!

Sometimes a little inaccurate (room one) and therefore difficult to control.

thanks!

Djinndrache wrote:
I'm playing custom maps and record my first time of playing them...

I have watched many of your vids on this site, and I want you to know how very helpful this is for you to post these first-time runthroughs.

It gave me a much better idea of what the player DOES NOT know when they enter the 1st room. I definitely need a clearer way to teach the basic concept.

Domathan wrote:
But your map Reminded me of my actual [WIP] Map which I should finih some time, but curse you Firelands !

I Loaded it Up for you (vmf included) so you could see how I did mine. They are a little different, but the concept is quite similar.

http://forums.thinking.withportals.com/downloads.php?view=detail&df_id=1084

But some things are still Problematic:
Portals+Multiboxes (or QuantumEntagledCubes if you wish) don't like each other much
How to Spawn Multiboxes (or QEC's) so it doesn't look unnatural.

I took a look at your map. Wow, those puzzles are TOUGH! You did a great job building puzzles around the concept. and I LOVE THAT BEAM. Looks great!

You're using phys constraints to link the cubes, where I am using setParent. I started out trying to use constraints, but as you mentioned, portals make them go very crazy. I also did not prefer the "ball-and-chain" feeling of pushing and tugging the cubes around, and was going for a stronger connection between the cubes.

I discovered a new entity that is worth a try: logic_measure_movement. It looks like another way to create a linked 3D offset between two entities. I have read that there are still some issues regarding collision physics, though. Still, it's worth a look.

If it only offsets the position and not rotation, the cubes would not explode nearly as often. Right now, my cubes act as if you bolted the other one to the end of a 20-foot pole. This is not working out so well when people pick up the cube and look around, swinging the partner cube wildly around and causing it to go out-of-bounds.

Ok, so initial tests show that logic_measure_movement does work better when linking the cubes.

The position is updated without the rotation relative to the first cube's centerpoint, so they move much more predictably.

The partner cube still passes through walls, though, which still presents a challenge.

I will try to post an update to the map tonight.

rendermouse wrote:
Djinndrache wrote:

I'm playing custom maps and record my first time of playing them...

I have watched many of your vids on this site, and I want you to know how very helpful this is for you to post these first-time runthroughs.

It gave me a much better idea of what the player DOES NOT know when they enter the 1st room. I definitely need a clearer way to teach the basic concept.

I'm glad that I could help and/or entertain you