That's right, you fuckers. ESTkv1.5.4 is done!
Combined Terrain and Object Sheets
The first thing you will notice is that there is only one GIANT ASS tilesheet per level. The distinction between tile and object layers is a thing of the past. There are only tiles. The new joint sheet is 512x1024 and has 512 entries.
New Layering Scheme
There are no longer top and bottom layers. There are three general-purpose layers that can all be elevated and used exactly however you want and one lighting layer, which is not implemented yet.
The 3 general-purpose layers have no inherent elevation, just draw priority. If a tile on layer 2 has an elevation of 1, while a tile on layer 1 has an elevation of 2, layer 1 will actually be rendered above layer 2. However, if the layers have the same elevation, layer 1 will be on bottom, 2 above, and 3 ontop. There is only priority within the same elevation level.
With this new scheme, you can do whatever the hell you want with the layers... You can use every single one of them as ground decorations the player walks above, or ceiling decorations above him. This is the most versatile system we can possibly implement.
In the first screenshot, the grass is all layer 1, trees are layer 2, and the barrels are layer 3. Notice that some barrels are in front of and some are behind the trees... It's based on elevation.
Solidity Rendering
Made no fucking sense previously. MapView was rendered the combined solidity between the two layers when representing solidity... So what happens if the two layers weren't at the same elevation? The engine will not combined the colliders, because they are separate pieces of geometry on two separate planes. Collision rendering has now been changed from being combined to being rendered on a per-layer basis.
UI Modifications
I'm sure you already noticed the Layer Dock. Obviously quite a few modifications had to be made throughout the entire Toolkit where UI distinctions were made between terrain and object layers. LayerView changed, many dropdown menus changed, and Sheet Manager had to change. Note that the LayerView UI in the first screenshot is not really that ugly... I just stretched it and zoomed out on the sheet so you can see how damn huge it is.
Old Areas/Maps are Broken
Because of the drastic changes to the file formats, any level created prior to 1.5.4.SA will not be compatible with this build (and vice versa).
Bugfixes
I can tell nobody has been using the Toolkit, because I found several bugs nobody had reported.
- Asterisk by area signifying modification did not go away after saving. It does now.
- Could not make a selection from the destination sheet in sheet manager. You can now.
Stability
Every feature that I knew I broke while implementing this has been fixed (along with other bugfixes). In theory, this should be the most stable build yet, but I did modify PLENTY of things, and some especially low-level core functionality. I will be very shocked if I don't need to release an SB build within the next week or so. As always, report bugs here.
Now What?
Now I need you guys to start making levels using the new elevation scheme. I want to see Patryk able to do whatever the fuck he wants with these layers. I want to see Tyler making tech demos showing off Chrono Trigger scenes that we are now able to achieve with these layers... This is some extremely powerful shit, but we currently don't have any levels using this functionality.
As for me, I broke the living shit out of the engine by doing this. I will be fixing ESGamma (which shouldn't take long), then I will be implementing the z transitional tile property to allow the character to change between elevation levels. I expect this to happen fairly quickly as well.
Get the Fuck on my Level
Code has been checked in. Windows build of ESTk1.5.4.SA is sitting in the DropBox. Now that I'm not a depressed, pill-popping mess, there are (once again) going to be some serious changes going on here. Carry on the righteous path, my brothers.
Okay, you fuckmites. As promised, here is the 1.5.4.SA Gamma build along with some more sugar in ESTk1.5.4.SA. The Windows build is already in the DropBox.
Layer toggles are back (and better)
Had to redo these after our layering scheme changed. They are still toggled with buttons 1-4, but the debug notification is more informative.
Collision toggles are back (and better)
If you think about it, the collision toggles in ESGamma and ESTk didn't make any fucking sense before. You cannot have a "combined solidity" view without having an elevation reference point. I have changed the way these toggles work in both pieces of software.
ESTk
Toggling solidity renders a decoration on each tile for the current layer. This means you are seeing solidity at every elevation level, but only for one layer.
ESGamma
Pushing '5' will now "cycle" through solidity views: DISABLED, LAYER_1, LAYER_2, LAYER_3, COMBINED. These are all rendered [i]with respect to the player's elevation[/i]. So everything you see is what can currently be interacted with. Here is a screenshot:
As you can see, there is collision set along the edges of the pillars going all the way up in ESTk. However, since the player is currently on the ground level, he cannot interact with these (they are above him). So they aren't rendered in Gamma.
Renderer and CollisionSystem both honor elevation
By pressing the 'Y' key within ESGamma, you can elevate the player (emulating a z-transitional tile).
once the player is at elevation level 2, he is no longer rendered underneath that segment of the pillar, and he interacts with collision placed higher up.
Z-Transitional Tiles
Are not implemented within ESGamma yet, but I went ahead and got them modifiable and representable within ESTk. Simply make a selection and push the 'Z' key to toggle on and off the "z-transitional" property for a group of tiles.
You can also view z-transitional tiles by toggling on their tile decoration from View->TileEntry Decorations->Z Transitional.
I will now be adding these to ESGamma. Now we really fucking need a level that makes full use of our elevation and new layering scheme. Even if I haven't fully implemented z transitional tiles, you can still transition manually within Gamma using the debug key I implemented. We can already begin testing.
Alrighty, you sacks of shit... I give you the fruits of my labors: Z-Transitioning.
I built myself a little demo sandbox level in ESTk to do all of the testing. The complexity of what we're able to do with our levels now is astounding... It's not about laying simple tiles anymore. This bitch made full use of flip/rotation, collision geometry combinations, elevation, z-transitionals, three layers, and the combined terrain/object sheets. I know this is not "visually appealing," this is a feat of gnitty-gritty programming implementation. Please entertain your imaginations and visualize Patryk's fine pixel art here instead of these placeholder graphics. I am presenting concepts to you, not a finished product.
Z-Transitional Sandbox
Here is the sandbox scenario that I constructed within the Toolkit. This is with all layers enabled with elevation decorations being rendered for the second layer. The entire structure is elevated so that the player should theoretically be able to navigate below and ontop of it. The entrypoint to the left is supposed to simulate a ladder, where the player is free to exit mid-climb (it is not bound by solidity), the entrypoint on the right is a standard staircase with collision boundaries on the sides to prevent the player of entering and exiting mid way up. There are also holes in the top to show the player underneath the structure and to allow him to fall down from the top of the structure.
This is only half of the picture, as you really need to enable z-transitional decorations to see the magic. Here are the z-transitional tiles for layer 2. Note that both enterypoints are flagged as z-transitional all the way up into the structure, as the player's elevation must change at each step up the ladder/staircase. The z-transitionals surrounding the holes in the structure are required to allow the player to fall through.
And here are the z-transitionals for layer 1. Note that there has to be one in front of each entrypoint to allow the player to transition from elevation 0 to elevation 1 (to begin his ascent).
Now a few screenies to prove you can walk behind the structure and that I'm not full of shit...
Now to climb up the ladder:
I have also beefed up the collision and elevation debuggotry to take z-transitionals and elevation changing into account. As the player moves up the bounded staircase, you can see the collision primitives within his local elevation proximity change.
And finally, the top of the structure... I have taken the liberty of modifying the CollisionSystem to mark every tile location without a walkable tile at the player's elevation as unwalkable. This will bound our elevated structures for us and prevent the player from just walking off (and floating above the world). 
The Audacity of the Z-Transitional Algorithm
This was actually an extremely complex feat to pull off, and I still have some fine-tuning to do. There were a few goals that we had in mind with this, and some extra obstacles we had to maneuver through (that games like Chrono Trigger were able to avoid, because they only had 2 levels of elevation).
- We wanted to flag z-transitionals with a single bit - which means we couldn't encode other data into it such as source and destination elevations and directions
- We didn't want to require contiguous elevation levels when transitioning. We decided early on that elevation should only be used where necessary, not for every structure to be elevated realistically. Because of this, it is conceivable (and sometimes preferred) to have elevations that don't match the structure's visual tile elevation level
Because of these restraints and requirements, the algorithm has some additional complexity requirements, as it must be far more presumptuous than it would have to be if we could encode things like source/destination elevations and entries/exits. This will place some restraints on level designers, but I haven not been able to think of any scenario where these restraints would be an issue (usually they're even desirable). Even CT's z-transitionals were pretty restrictive in nature.
The algorithm prioritizes the player's next elevation as he exits a z-transitional tile as such:
- higher elevations - chooses closest higher elevation to player's elevation
- same elevation
- lower elevations - chooses closest lower tile elevation to player's elevation
Once you start invoking the engine and screwing around, I think this will all make sense to you.
A New Chapter...
While I definitely have some tweaking and cleaning up to do, this marks the end of a huge chapter in the engine. All of the map format modifications, rewriting, and layering decisions that we have made worked up to this point. This tiny little demo showcases an enormous amount of power from the engine. As I mentioned earlier, this is tile flip/rotation, dynamic geometry combining (and reorienting), elevation, z-transitionals, three layers, and the combined terrain/object sheets with the rudimentary mass-aggregate physics engine still running. I am extremely excited to see the possibilities that this additional complexity unleashes for our future level design and artistic endeavors...
As for my sorry ass... Once I get this shit all polished up, I have decided that it's time to get Lua back into the engine.
