First of all, let’s think about the teleport “feature”. How many games have teleports among them? There’s no MMORPG without teleports, for example. Or this big amount of times in which the transition from level to level or from room to room is a loading screen.
Portals would be a very cool option for developers to make these transitions much cooler. And I can think of more than one game designer with portals in their dreams.
My idea of the Portal object is very simple:
Visually based on a 3D quad.
Transformation matrix from portal source to portal destiny.
Every camera with a portal in its frustum will need a duplicate transformed by the previously stated matrix.
The quad just renders what’s in that duplicate camera, with a shape mask (usually an ellipse).
In the case the destiny is in another map/level we’re also going to need some level streaming.
The pawns, once they intersect with the portal, will start to be rendered also in the other side (using the transform matrix).
The pawns’ positions will be modified with the matrix only when their center intersects with the portal (or when they finish crossing it, up to your choice).
I’m aware of the big amount of possible problems that will strike during the development of this, as well as I’m aware that such a feature in such a complex engine could become a nightmare to whoever is assigned the task, but consider the outcomes of having this in your features list.
In my opinion this is totally game specific. It’s also not hard to do. But for an mmo it’s just not suited because you need the loading screen to connect to a new server and to load all objects, so seeing the other side would be too inefficient.
I was talking about in-server gameplay, and wether it’s worth the computational cost or not should be up to the developer. But indeed, it’s very game-specific.
I have done portals in my own engine, but here I have no idea of where to start, I don’t even know if it’s possible or not without touching the engine (I’m a complete UE beginner). All I’ve seen are some tutorials to make “portals” which visually are just particle effects or whatever, not showing what’s “behind”.
Anyways, it was just an idea. For the moment we won’t need that in our game
I don’t get it.
There is “Teleport” function and you’re talking about specific little additions which are 100% handled by developer, what do you want from Epic?
Anyway, check out this video http://www.youtube.com/watch?v=Gt3NLTnCUTk
@: I’ve seen exactly that happen inside Minecraft of all games, though it was the same server it still had to load a completely separate dimension. The scene capture was rendered as part of the UI layer, sure, but note the world still rendered in the background, taking it the extra step and transforming the capture to in-world coordinates wouldn’t be that much harder.
@: It would be nice to have this on the marketplace, but I’m pretty sure it has to be done through C++, which means it’s not possible just yet.
That’s how it’s usually done, but getting the math right and making it look smooth is just going to lead to duplicated effort from multiple developers doing the same things independently.
Things that were in the engine before?
Nice video, that’s the smoothest UE4 implementation I’ve seen yet.
EDIT: Forgot to draw this as I had initially planned: (Please excuse the mouse-writing)
@: Not unviable for an MMO at all:
So, first, to the mmo, it is unviable if you want to see the players on the other side from the other server. If not, or if it’s the same world/server then it’s ok.
Also, as far as I remember, it’s just 1-2 material nodes that do the math. Check out the udk tutorials, it was a pretty trivial thing to do.
Why can’t you send player data to the preview node as well? Sure you have to do offsets and such, but that’s not a huge deal. And since the preview should be a deceptively small area anyway, I think you could pull it off…
You could. But it’s super expensive because you would have to sync two servers at the same time. Basically you’d be connected to two game servers. That is theoretically possible but costs you so much. Because the issue is not that the client has two servers to connect to but exactly the other way around. Suddenly every server with a portal in it has twice the load in that area.
In a town with potentially hundreds of player that’s huge. Though the result would be rather neat since you could dynamically switch between those citys in real time and just load them in the background on your way between the gates of a city and the teleport location.
You could probably also load the place to your first server and replicate the users like below the current level and simply show this. That would get rid of the connection for every user but you would again have a loading screen.
For a neat little feature it’s way too much work. A simple portal like in guildwars 2 works exactly as well gameplay wise and is so much easier to create.
Anyway to the topic directly.
I think that function in UE3 was a left over form Unreal Tournament 3. It had it’s purpose there with a default mesh and everything. But you still had to do the destination and everything. Since there were no prefabs in that way and Kismet couldn’t handle both it was a good way to have a mesh and do the destination and other (simple) logic via kismet for your specific level.
With UE4 this problem is not there anymore. We can code the behavior, destination and everything neatly into the actor itself.
The teleport node really provides about everything you could wish for. Everything else is done in an hour or such. And like this you have all different cases covered (an area or plane which should trigger teleport, timer before teleporting, the mesh around, on top, below the teleportaiton area. Or no mesh at all.
A material which displays something a camera is recording and the target camera.
It’s fairly simple to do that in BP.
TLDR: I don’t think there is a real need for a specific actor which acts as portal only.
Skewed and alternate projections onto render textures, as well as clipping planes, would solve the rendering part of this. That would also allow proper mirrors.
Having actors “poke through” the portal, though, is a lot more trouble, because you’ll need two separate physics bodies for the same actor, and they could end up fighting against each other and lead to instability and bugs.
I’d be OK with just having an on-touch event, and initiate the teleport/effect/warp at that point. If you want to support shooting through the portal, then spawning a second bullet is a lot less trouble than trying to physically simulate a second rigid body.
