Welcome to the Aperture Science Chamber Homogenization Gallery. The Chamber Homogenization Gallery homogenizes all other test chambers, into one easy-to-access location. Via an adverse side-effect of chamber homogenization, the floor has been flooded with highly toxic and corrosive substances. This substance is completely safe.
Please put on the Aperture Science respirator you should have been given immediately before entering the Gallery. If you failed to collect your respirator, please assume the choking position now, and a party associate will be along shortly to deposit your body in the Aperture-Science-biological-waste-recycling-center.
The Gallery
The ‘Homogenization Chamber’, which homogenizes (the process of making things uniform or similar) all the test chambers together (the main room, similar to ‘The Hub’ in Portal 2) was made using the same base techniques the rest of the game had been made with. This would contain the Level-loading areas for moving to all the other Chambers. To get there, a hit box was placed at the end of one corridor with a ‘On Begin Overlap’, ‘Load Level > Level 0’ in code. The ‘Level 0’ is the game-development name for the Homogenization Chamber.
The Level Loader then spawns the player in the next level, with a ‘player spawn’ located in an identical corridor (copy and pasted from the first level), so that, after loading, the location would look as similar, before the level-change, than after.
As per the original game, a sign to introduce the area was made. This I made on Photoshop, also acquiring a number of ‘vector’ icons form the portal game. The portal sign can be recycled, with the numbers and icons being changed for every test chamber and reused.
I then wanted to make an Unstationary Scaffold for the player to access the first test area. A long and thin cylinder was created from the start to the end location of where I wanted the scaffold to go; this was then given a blue ’emissive’ texture and a static mesh was placed on top of it, given a hit box to trigger an animation, and animated it with a sequence.
The floor of the area was covered in deadly goo, so a kill volume was required above it. However, this meant that it was possible for the player to die, and so a checkpoint system was needed to prevent them from having to replay the entire game from the start.
Checkpoints
Firstly, because the coming-back-to-life of this checkpoint system would not mean the non-stationary scaffold would be rest, additional non-stationary scaffolds were added and made to continuously move across the screen. To make a checkpoint system, a new ‘Blueprint Class > Actor’, called ‘Player Checkpoint’, was given a hit box and placed where a checkpoint was wanted.
When the player would hit the hit box of this checkpoint, it would cast to the Player Character and ‘sets’ the ‘CheckpointLocation’ (a Player Character ‘vector’ location variable) to be the current location of the checkpoint.
The Kill Volume (the deadly goo’s hit box) was then modified so that, on Actor Begin Overlap (when they’d fall off the platform into the goo), the player’s input would be disabled (so they could not move), alongside a sound being played (a gurgling sound, sourced: https://freesound.org/people/Perel/sounds/173438). Input was then re-enabled, at the same time as a ‘playerDead’ variable was set to True.
In the Character Blueprint, the ‘Event Tick’ function, continuously running, (which would lead to an ‘if’ statement that depends on the ‘playerDead’ variable) is allowed to continue because playerDead then (upon falling into the deadly goo) becomes true. This then ‘SetsWorldLocation’ (of the Player Character) to become the ‘CheckpointLocation’, which was set by their collision with the Checkpoint Blueprint Actor (teleporting them to the Checkpoint location before re-enabling their input), finally setting ‘playerDead’ to false once again, because they are Still Alive.
Blueprinting Doors
With the amount of times a door has already had to have been programmed, I wanted to create something which could be dropped and would work immediately without much programming beforehand. I created a new Blueprint Actor and placed a cube in it to be the correct size and shape for a door frame.
[This is the door frame that was used. It is the component geometry pieces of a door I had already made, using subtractive and additive brushes arranged to be at the right height and shape for the door frame to exist; it includes space for the door to go, and for it to rise up upon opening.]
This actor then had two trigger boxes attached to it, one called ‘DoorSTART’ and one called ‘DoorEND’, which were placed either side of the door, and would be used to trigger the door’s opening and closing.
When the START or END box was triggered, it would fire to either ‘Play’ or ‘Reverse’ a Timeline. This timeline contains the programmed information that tells the object by how much it should move and in what direction and with what rotation. In this case, it is programmed to raise the box ‘up’ along its Z-axis by 250 Unreal units in one second. This is the ‘Door Movement’.
It then SetsActorRelativeLocation, the target (theactor_) being the cube which is being used as the door. The New Relative Location of the cube is the Door Movement (the XYZ information in the Timeline) added to the Door Start Location. The Door Start Location itself is set from BeginPlay (from the start) by SET-ing the ‘Door Start Location’ to be the ‘ActorLocation’ of the ‘Cube.
Upon testing, this system of opening and closing doors turned out not only to be more efficient in its placement and utilization, but also far more stable, with currently no foreseeable issues in the player’s movement from one side to the other — the animations played correctly, at the right time, and prevented the player from being able to get stuck in the lowering door or glitch into the curved doorframe (meaning the ‘visibility disabled’ cubes required on earlier-placed doors).
Telescopic Arm and Panels
One of the mainstays of the Portal game series is the moving panels of which the entire Enrichment Center is made (to the extent that the entire ‘building’ is mobile, as mobile as it can be inside a disused salt mine underground. They make up all the test chambers, and can reconfigure themselves seemingly endlessly, for a nigh infinite number of possible chambers.
I Opened up 3dsMax and began working on making my own version of the panel. I started off (left to right) with the base, which would be attached to the wall, then a joint with the first arm attached to it; then a telescopic arm, which would allow the panel to have greater versatility and ease of use for the animator (me). Attached to this was a dual-joint, which would give a great amount of flexibility to the design. Attached to this was another arm which connected to the ‘panel joint’ and, this, to the panel itself.
Then came the necessity to rig the panel with bones. First, I selected the entire object and applied a ‘Skin’ to it, selecting it under the ‘Modifier List’ on the right. Once skinned, it could be boned.
Under the ‘create’ tab, I selected ‘Systems > Bones’. I applied the bones in their correct places throughout the 3D object, and then tested them to see if they worked. I was then faced with an issue — many of the joints were effecting parts of the model I didn’t want it to, or were not affecting parts I did want it to (the most obvious being the first joint, which glitched and clipped with itself as it was rotated, as half of the cylinder which made the join turned, while the other half stayed the same).
I opened an option under the ‘Skin’ function to access the ‘Weight Table’, which allowed me to assign manually which bones affected which vertices, and adjusted these as needed, until the whole thing was rigged.
However, an issue still remained — the telescopic arm did not work. This would cause major issues in the design of the model, as it would break much of the versatility of the design.
To combat this, I had to rethink the design of the model — more specifically, the placement of the bones inside. Here, I also redesigned the 3D model. It was originally designed just to test the mechanics, but now I made it more accurate to the game, more complex and more detailed — also adding a second telescopic arm to make it even more versatile.
