Post by PurpleSloth in What's your gender? comments

Viewing post in What's your gender? comments

There are a couple of different mechanics we use for the effects.

For one we spawn and despawn copies of each room in relative positions to the room the player is currently in based on triggers set in this room. This allows us to have rooms that would intersect with each other or repeat endlessly.

The portals work by placing a second camera in the same relative position to the "portal exit" that the player has to the "portal entrence", rendering it to a render texture and then use a custom shader to istead of cropping it onto the portal plane cutting out the part of the fullscreen texture that intersects with the portalplane.
The main problem with portals is that having multiple of them active at any given time can really drag down the performence so its key to deactivate them whenever they are not actually rendering anythign and avoid "portal loops".

For the queer room tunnell we project the player position onto a single axis and then rotate the room and its neighbours depending on a 180° Lerp with the projected player position as progress value.

The basic concepts arn't that hard to impliment in a limited amount of time (although the code is quite a bit messier than it needed to be due to the time constraints). It's the setting and testing of triggerboxes, anchorpoints etc. that takes most time. It should also be said that some of the rooms currently in the game were not present in the original jam release, but added later on.

divVerent2 years ago(+1)

Ah, you can spawn/despawn entire rooms in Unity. That of course helps and also allows some things to be done easier than the original Antichamber way (having native portals and enabling/disabling them at will).

Was rather curious as I was the one implementing the portal mechanics into DarkPlaces Quake engine + Xonotic and it was a lot harder there - well, none of these primitives were there though (except some existing engine code for rendering a scene in the same map to a texture which was used for water reflections). E.g. dynamically spawning entire rooms including objects is not possible even today, and the hacks that would allow sort of similar things are extremely slow as they would lose precomputed visibility information.

How I did it in the combination of DP + Xonotic was twofold: in DP I just provided "cameras" where game code can set the view origin of the camera, and in Xonotic I made all the other primitives (e.g. collision) aware of the portals.

In my game AAAAXY (which is 2D and thus I had no even remotely portal-capable engines available, but created my own) I went with a different way, to ensure portals have no glitches whatsoever; that way is however rather incompatible with multiplayer and thus I cannot generally recommend it. I basically decided to support portals in the tile loader itself and nowhere else, meaning everything else, including player movement, distance computations, tracing etc. work precisely the same whether portals are in the way or not. This approach may be applicable to 3D games as well, although as you describe portal tech in 3D is not particularly hard anyway, ESPECIALLY if given the primitives "Camera" and "copying rooms together" (in fact, with just copying rooms together and without cameras, you could already do portals the AAAAXY way and it will all be one render pass, although it may be slow to add/remove room parts at runtime and doing it like that everywhere also puts some annoying constraints).

While doing this, I also had the issue that third person portals are even more broken in general, as the typical way done in 3D engines only works for a first person view. To some extent this can be worked around, of course. What I ended up doing was introducing the same visibility mechanism as you know it from 3D games but applied to 2D - so anything the player cannot see is just black. Personally I got the idea from Among Us, but I must highlight https://alxwest.itch.io/kitakombs which discovered and released this tech independently on Itch before I finished my game.

PurpleSloth2 years ago(+1)

There are a few ways to spawn/despawn full rooms in Unity. Given that this was a jam originally we took the simply road and made them all into prefabs, provided each room with a reference to each prefab that could spawn from it and the appropriate anchor points. The Trigger zones then call on the current Room to spawn/despawn them accordingly.
Similar things can be done by treating rooms as seperate scenes and spawnnign them additively, but this does not work as neatly with having several copies of them and a few other thigns we do.

I'm allways happy to see different solutions for implementing non-eucledian levels. Will take a look at the ones you mentioned for sure =)
Using similar mechanics in 2D is something I've always wanted to do but havn't gotten around to yet. I think this could be especially fun for sidescrollers, where having branching paths (other than having a bunch of background doors) can be a challenge.

- radow

divVerent2 years ago(+1)

BTW I think I forgot to mention - there is one way to do non-euclidean geometry in a 2D sidescroller without the visibility shadows that I did: if an entire screenful matches on the two ends of the portal, i.e. if overlaps are one screen away from the respective portal from which they are entered, then this can be done by transparently teleporting, as nothing on the screen would change during this.

A game that does this technique is none other than the original Super Mario Bros. in some of the castle levels (those where going a wrong path transparently brings you back to the start of the level). However in there the teleporting was not entirely transparent - they didn't clone some firebars to the destination side of the portal. This would have had an easy fix, of course; however due to how spawning works, it might have been tricky to put the "new" firebars in the same angle as the "old" ones, so this may be why they didn't.