Journeyman's Minimap - Code Plugin for Minimaps and Fog of

Hey there,

If you’re using the generated background feature, the scene is rendered to a render target only once at the start of the game, so don’t worry it doesn’t do something crazy like rendering the world every frame. :slight_smile:

I also spent a lot of effort on optimization. Some examples of that:

  • When updating many icons’ positions, any intermediate calculations that are the same for all icons precomputed and reused.
  • Icons that are not in the minimap’s view are not rendered. This is done with the help of a broad phase collision check (a cheap check to eliminate icons that are definitely not in view).
  • A background texture assigned to an area that does not overlap the minimap’s view is not rendered.

I hope that answers your questions. Let me know if you’d like to know anything else.

Also what kind of support are you looking to provide for this plug-in? Feature requests?

You can always post questions about issues you come across in this thread or by emailing me directly (see marketplace page). I usually get back to you within a work day. As for feature requests, I will be releasing updates to this plugin but infrequently and depending on how many people show interest in a feature. Crash fixes and updating to new engine versions will have my immediate attention.

Sure. First could we get a little more information regarding how networking works with this?

Second, we want to press M to show the entire map over the whole screen and then if we press M again it shows just the mini-map. How difficult is it to do that with your system? Or does that work out of the box?

I bought this to support development and it’s great! Now I’m waiting patiently for an update with which you can generate texture based of navmesh, are you working on that? That would truly make it a complete system for me :slight_smile:

But I just wanted to already say thank you for your great work!

Looks amazing!

I would also love to see navmesh feature before I buy this though.

Hello? Anyone still here?

Hey guys! Sorry to take an extra day to get back. It was King’s Day in the Netherlands. :slight_smile:

I will be investigating rendering the nav mesh to the background texture. Thanks for the suggestion and for the people who seconded that. Expect progress updates on this starting next week.

The plugin tracks all actors with “MapIconComponents” added to them. This tracking is done independently by each game client. All minimaps will display the same world though, so long as the actors’ position is replicated.

As for how the icon appears (texture, size, draw color, visibility, etc), the plugin does not make any effort to synchronize these values. This is the responsibility of the actor that owns the icon. This is by design, as you should know best which attributes to synchronize and which to differentiate per game client. You probably want enemy pawns to appear differently from friendly pawns, which you can do by a texture swap or setting a draw color. Perhaps in your team vs. team game players should only see enemy players if they are in line of sight. Here are snippets that illustrate this, from a project I’m working on:



// Updates minimap draw color
void AMyCharacter::RefreshMinimapTeamColor()
{
	const FLinearColor TeamColor = IsLocalPlayerTeam() ? FLinearColor::Blue : FLinearColor::Red;
	TeamMapIcon->SetIconDrawColor(TeamColor);
}




// Updates icon visibility based on whether local player can see character and whether character is alive
void AMyCharacter::RefreshMinimapVisibility()
{
	const bool bCharacterVisibleLocally = LocalVisibility != EVisionTargetVisibility::Hidden;
	const bool bCharacterIsAlive = IsAlive();
	const bool bIconVisible = bCharacterVisibleLocally && bCharacterIsAlive;
	TeamMapIcon->SetIconVisible(bIconVisible);
}


In my project the above functions are called by OnRep_ functions of any replicated variable that affects the icon’s appearance, like Health.

This works out of the box. You can create a UMG widget that has two Minimap widgets and a Widget Switcher that toggles between the two based on a key press. The two minimap widgets can have different sizes and one can be configured to follow the player, while the other shows the entire map.

This is actually demonstrated in the Example Project, but you do need the plugin to run the project so I’ll paste some screenshots of the relevant bits instead. In the example project you can hold Tab to switch between the two widgets.
widget_hierarchy.png

Pressing a key to toggle instead of holding it works slightly different, because unfortunately widgets can’t capture key presses directly. But the bottom line is, the plugin supports differently configured minimaps that you can switch between.

I managed to include the navigation mesh in the generated background texture:

I will submit this update next week, after making sure this feature is integrated neatly. Including the nav mesh in the generated background will be optional. Note that while in the image the nav mesh also appears in the world, this of course won’t happen in your game.

Thanks again for this pointer, it helped a lot.

This is such a beautiful plugin that I’m seriously considering implementing it in my game. Do you know when the ability to have multi level maps will be supported? (i.e. using a zOrder for each level)

I’ve just now finished on the nav mesh and I’m starting on multi-level map support. :slight_smile: Expect multi-level map support to be submitted in two weeks.

Edit: Nav mesh rendering will still be submitted upcoming week, May 9th to be exact.

Update 1 is live

You should be able to pull down the first updated version of the plugin via the Epic launcher. Two features have been added:

Navigation mesh can be included on generated background
The MapBackground actor has a boolean option bRenderNavigationMesh that controls whether the navigation mesh should be rendered to the generated background. Since the nav mesh represents the walkable area, this should make it easier to paint over the generated background in Photoshop or another image editor.

Easier to control zoom level
Previously you could control the minimap’s zoom level by setting the view extent. For example showing a 256x256 world area is twice as zoomed in as when showing a 512x512 area. However, I recognize that defining the zoom level as a scale might be easier to work with. You can now control the minimap’s zoom level as a scale via the functions illustrated below. As of now, the minimap’s range is defined by ViewExtent.XY * ZoomLevel. Note that a view extent of (256, 256) and zoom level of 2 gives the same result as a view extent of (512, 512) and a zoom level of 1. Just use whichever approach is more intuitive to you. An advantage of the zoom level is that you don’t have to remember the initial view extent.

Let me know what you think of this update and if any issues arise.

I’m currently working on supporting multiple height levels.

That’s great news that the nav mesh feature is live! Thanks for your great work. I will try it out soon :slight_smile:

No problem. Thanks for the feature suggestion. :slight_smile:

Here is an update on the multiple level support. I have background texture selection based on Z-coordinate working:
Image moved to update announcement

You can specify each level’s height on the MapBackground actor. The actor’s wireframe will preview the levels. For each level you can set a different render target. If you leave the BackgroundTexture field for a level empty, a background will be generated for that level, rendered downward from the level’s ceiling.
Image moved to update announcement

I will continue on this feature, because with the introduction of multiple levels I also need to implement ways to control which icons are visible on a level. Fog should be updated to support multiple levels too.

Update 2 is live

In this update, backgrounds textures have gained new options.

Multi-level backgrounds
Robust and simple to use support for multi-level environments has been added. You can now configure multiple levels on a MapBackground actor, each with its own minimap texture or generated background. You define the height of each floor and will see the floor placement previewed in the front and side editor viewports. During gameplay, which floor is rendered is selected based on the Z-position of the MapViewComponent that defines the minimap’s view. You can also set a different SceneComponent whose Z-position will be used by setting MapViewComponent->HeightProxy to any SceneComponent. The functions SetBackgroundTexture(), GetBackgroundTexture() have been updated to receive a LevelIndex parameter, so you can change any level’s texture during gameplay. Here is a GIF of multi-level backgrounds in action:

https://s22.postimg.org/n2zkmd5jl/Multi_Level_BG_2.gif

Priority backgrounds
Do you have an outdoor environment with buildings, and when the player enters a building it should switch to the indoor background texture? This is now easy to do by placing multiple MapBackground actors and assigning different Priority values. When a MapViewComponent is inside multiple MapBackgrounds with different Priority, only the MapBackgrounds with highest priority are rendered. You can thus place one large MapBackground that define the outdoor background texture and place smaller MapBackgrounds with higher priority that define indoor background textures to make the indoor textures show up as soon as entered. Here are priority backgrounds in action:

https://s3.postimg.org/ic6p6jilf/Priority_BG_1.gif

Multi-level backgrounds and priority backgrounds are combinable. When using both features, the MapBackground with highest priority is chosen and the correct floor of that MapBackground is rendered.

Background Z-order
The rendering order of background texture is now controllable via the MapBackground’s ZOrder setting. A background with higher ZOrder is rendered on top. This is useful when you place multiple MapBackgrounds that should be visible at the same time, so you let them have the same Priority. Use this for example if you want to show an indoor background at the same time as the outdoor, but haven’t combined them into a single texture beforehand. By giving the indoor background a higher ZOrder, it will be rendered on top of the outdoor.

Icon interaction with multi-level and priority
MapIconComponent has a new setting to control how they interact with background levels and priority. You can configure the icon to always render or only render when the MapViewComponent (usually on the player) and the MapIconComponent are on the same floor. If the MapIconComponent is inside a MapBackground with high Priority (in-doors) it can be configured to only show on the minimap when the player is also inside that MapBackground (or one of equal Priority).

Show or hide backgrounds
MapBackground actors now have functions SetBackgroundVisible(bool) to control a background texture’s visibility on the minimap during gameplay. This is for you to implement any cases not handled by multi-level or priority backgrounds, for example hiding a room’s background texture until it is explored and then showing it permanently.

Tweaks and bug fixes

  • Fixed a broken in-editor documentation link (thanks Peter Ryan)
  • Fixed a crash that occurs when using a MapBackground that renders the nav mesh in a packaged game.
  • Removed the boolean option “Fill Background” from the Minimap. This setting is now interpreted from “Fill Color” alpha channel.
  • Fixed “missing includes” compile errors that occur since UE 4.15.2.

Left: Overview of MapBackground settings as of this update. Right: Configuring a multi-level MapBackground.

This is starting to look pretty powerful. You should probably add a link to this thread on your marketplace page.

Have you updated your documentation with this?

I didn’t realize I hadn’t put a link to this thread! I’ll update it now, thanks.

Not yet, I’ll do that this weekend.

Will you update to 4.16?

I am unable to migrate my project to 4.15, ETA on 4.16?