OK, so we are not quite ready to get to “Action!” yet, but now that we have a basic level lets talk a little about cameras, lighting, navigation and building stuff in Blueprint.

Building a Camera

So we have a level, lets build a camera so we can look at things properly. In keeping with the boardgames that inspired this project, where players sit around a table a look down onto the game world, the camera needs to present our world using a top down angled view. It should also let the player scroll around the map using either the keyboard or “bumping” a cursor against the view edges, in short a typical RTS camera. There are a lot of tutorials on youtube and other places showing how to go about building a camera like this but it is important to understand how Unreal expects player control to work and be organized.

From the manual “A PlayerController is the interface between the Pawn and the human player controlling it. The PlayerController essentially represents the human player’s will.” So, our player controller needs to interpret raw input and convert it to events that can be used to control our Pawn. In our case the Pawn is actually our camera. Spawning the right player controller and linking it to our camera (and eventually our UI) is handled by the GameMode. Unreal has a default game mode that can be set in the editor and each level can have an override to set its own game mode and replace the default. So, lets use the default game mode to handle our menu interactions and initially greet the player when they first launch the game and then override this when the procedural level is loaded. Something like this:

Game Modes

Well, that was more than I bargained for to “just setup a camera” but it gives a solid foundation to build out menus and an in-game UI so thats going to be pretty handy in the long run. Building all these different bits is also quite simple with Blueprint once you know how to hook them all up.

Lights and Navmesh

Working with an entirely procedural map is probably not something the designers of Unreal had in mind. I was a little concerned things like lightmaps and navigation meshes that would normally have an element of editor pre-computed data might have issues. A procedural map obviously presents very little opportunity to pre-compute anything. Thankfully Unreal handled things just fine, on the fly navmesh generation worked great and simply required stretching a navmesh volume to fit the generated map of rooms and then trigger an update (easily done via Blueprint).

Navmesh

As for lighting, right now I’m using Unreal’s distance field based shadows and this seems to be working well (I’m not worrying about mobile platforms for the time being). However, going forward lightning will need to be handled carefully, especially once point lights, dynamic and rigged meshes are added.

Shadows

Thoughts on Blueprint

At first I was a little suspicious of Blueprint, being an experienced programmer perfectly at home in C++ I expected Blueprint’s graphical scripting system to get in the way, forcing me to laboriously connect wires and nodes to do what could be accomplished with but a few lines of text. While it sometimes feels this way, Blueprint actually offers something that is extremely powerful but not immediately obvious, communication.

Regardless of how quickly or how easily an engineer can knock up a system in Blueprint its real strength lies in how easily they can communicate that system to others. The ability to quickly show another person how something is put together is immeasurably important when working in a team but has also lead to an explosion of community and official tutorials. It would be hard to imagine watching (or making) a video where someone writes out lines of code, but that same developer walking through a visual blueprint is vastly more consumable. The resultant wealth of quality tutorial material is a massive boon to anyone using Unreal, weather or not the final work ends up being in Blueprint or C++.

My current work flow involves building things out in Blueprint first and if they become too complex I move them into C++. It remains to be seen if performance requirements will change this choice, the project is far too small at this early stage for it to be a problem.