This is one of those things I’ve wanted to have in my game since I had a second map in it. It is also one of those things I believe highlights quite well just how many systems you need in place to get something up to par in what you want. For now, I have a very basic system working. In the future when other things get built out and created I’ll need to expand this out.

For the six maps, I have right now. Along with trying to work out how to even do this. This was only a couple of hours from start to the current state it is in kind of deal. The mechanics themselves after I played around with them are quite simple. However, to have it polished will be quite dependent on a lot of future things not even built yet.

Collision Overlap

The first thing I needed was to create something for the player to have a collision with. I also wanted some kind of particle effect to denote there was something of interest in the area for the player to check.

To be able to do that in Unreal Engine 4 I created a new blueprint class called Actor. From there I added in a collision box that is invisible and will contain the code I need when I add it. I also added in a very basic particle effect around that collision box otherwise the player could walk right past it and not even know.

The graphics for now regarding this are just not important to me. Chances are in two years from now when I come back to revisits this system and upgrade it. I’ll be putting effort into the graphics side of things anyways. As such it’s not worth putting a second thought into it. I just need something in for now.

UI Widget And Portal Blueprint

The next part was the hardest part which I failed a couple of times in trying to work out how to approach it. I knew the collision box under events for “on component begin overlay” is where I needed to create the blueprint for handling moving the character to another map.

There are two basic things for now I wanted my blueprint to do.

Loading screen.
Move the character's pawn to another map I want.

For the loading screen itself that can be done with a user interface widget blueprint. Onto the canvas panel, I added a spot for an image that would take up the entire screen. These images would be a prevue of the map the player would be loading into. I also added a line of text that simply stated the zone and that it was loading.

It is also interesting to note. From the developer side of things, I think in terms of “maps.” While from the player side of things I think in terms of zones, dungeons, and other names.

What I did not do is add anything fancy to this widget for now. There is no progress bar or anything else to try and indicate to the player how far along loading is. I frankly won’t be building out the networking part of the game till 2022 or later. As such anything I put in now would more or less just be fake and a waste of time in trying to think how I wanted to have it work. Loading times for me are also a couple of seconds if that.

I did go around to each of my zones and take a screenshot from within Unreal Engine 4 itself to use. I toggled the game view to simply remove a lot of the hidden objects that are seen on the developer side of things. I then turned on impression mode with F11. From there I used the built-in screenshot button of F9.

Unreal Engine is kind enough to pop up a link to where screenshots are stored as soon as you take them. I relocated them to a different folder for my organization as I wanted all my loading screenshots to be in the same place along with other assets for this part of the game. They were 3MB in size which is good enough quality for what I wanted. I could, however, increase that massively if I wanted to. The Unreal Engine 4 screenshot system has some amazing capabilities.

Now with a widget in place that had some stuff in it. I needed to tell the engine to display that information to the character in my portal blueprint. This was done with a simple “cast to the character” into creating a class widget. With the class referencing the widget I just created.

From there I had a couple of choices in which function I want to use in Unreal Engine 4. I’ve been using the “add to viewport” function for everything else I’ve been doing. As such I wanted to remain consistent in my coding.

After that Unreal Engine 4 has a neat function already created called Open Level.

In the new zone after the player is moved there, Event BeingPlay will be triggered automatically by that zone itself. Which will then call up my HUD and replace the loading screen widget with my HUD widget for that character in question. As such I don’t need to start state from this blueprint or try and handle displaying the correct HUD for the current class being played. For those that don’t already have something like that built a simple destroy with the load screen widget being the target should be enough.

To be able to test if my portal is even working I moved to one of my empty test maps. It just has the basic level starter package and nothing else. I then moved the version of the portal actor blueprint class into that map for testing purposes.

My first attempt resulted in an error when I tried compiling that I could not work out how to resolve. This caused me to rewrite it a couple of times.

I do have a complication with there being more than one possible playable class already in-game for the player to select as well. I’m also still quite a noob at trying to create blueprints. So I overthought the situation and ended up creating the above trash. It did not work which is why it’s all off on its own now. I kept it around to examine my attempts at trying to work out a solution. As a cleanup process, I removed it later on.

This is what I’m currently using which was very close to my first attempt at trying to walk myself through what all was needed. It’s very simple and efficient. I don’t expect it to remain this short over the long run as there are some thoughts on issues it will have down the road years from now.

After getting something that was working and testing it. I dropped it into my first map where a lot of new systems get tested. I have a couple of tests objects in there as well such as money, items, and other stuff the player would pick up before getting to the portal a few feet away from zone start.

One thing I was expecting is an issue with my different character classes in the game. Right now I have a sorcerer and a paladin character which I tested both. For easy of us in testing all my maps without having to port in, I have by default an override that selects my paladin.

As I expected. When I ran into the collision for my portal and was teleported to another map. My sorcerer turned into a paladin! While I could try and resolve this issue right now in my blueprint. I don’t see a need for it if it simply gets resolved through other means later on. Though I’ll leave a short note of it for myself as this would be quite a strange bug to have when private beta testing rolls out.

One unexpected result of testing was discovering. This was related to my gold and items which did not transfer over when I was moved to another map. My experience gained was so I suspect since that is in my save file while a lot of other things are not. That should be the main cause. It will, however, need to be tested at a later date to make sure.

As far as why don’t we have a more in-depth save file working for this game? My entire inventory system I have working at this time needs a major overhaul. It’s also only set up for this game to be standalone. It cannot scale without becoming a massive nightmare. This also includes my bag system, and a bunch of other things it will affect my save system. Items and inventory is a thing I’m slowly working on due to the massive scale of those systems along. They, however, won’t be ready till late 2021 or 2022. As such, I can’t even test if this is the issue without doing a lot of work in this area first anyways.

After testing and making sure my first portal blueprint is now working. it’s time to expand things out for other maps. I duplicated both my load screen widget and portal actor blueprint for how many I needed. I then went in and change the background image and set the proper class and object reference and level name in my portal blueprint under component begin overlap for the collision box on my portal.

It was then time to move all my portal actor blueprints to the correct spots in my maps. Along the way, I tested each one to make sure it was working. I ended up discovering I mistyped the zone name for one of my maps.

I do not have any error catches with a message reporting back to the player when failure to load happens in my portal blueprint at this time. Since there will be a lot of reasons why that could happen and those systems are not even built yet (like a connection to the server). I did not see a need to add in a dummy function into my blueprint that I could not even test at this time. Thankfully Unreal Engine 4 while testing in their engine kicked back an error message.

Since this last process takes less than a minute to duplicate and make changes. I’m not at all concerned if I need to go back in the future one day and duplicate for all current 6 and a future of 25 zones a new widget and blueprint I build out when I rework this system. This last part was the fastest thing to do.

Final Thoughts

This is just one of a million things that I need to do. It’s also interesting when you just want to do one tiny little thing how many other systems and things end up being related or required to get something fully up and running to what you want it to be.

Today was just getting in basic functionality so I can start to reference these portals later on when the time comes. Years from now I might laugh at how simple and easy my first portal version was. I will at least hope it looks much better!

Information

Screenshots were taken and content was written by @Enjar. Screenshots are from Unreal Engine 4.

Game Development | Basic Portal To Another Map

Collision Overlap

UI Widget And Portal Blueprint

Final Thoughts

Other Posts:

Information