Making the Game: Final Touches

With the gun complete and the game as well, there are only a few more things left to do in the game project before I put them together.

Cleaning Up the Project

Having a messy project usually wouldn't matter too much, as long as the person (or people) working on it know where everything is. However, a messy project can be difficult to navigate, especially after long periods of time or if new people are being brought on board a project. That's why I'm going to clean my project up to a more acceptable standard!


The World Outliner allows for easy access to all the objects in the scene. However, if they're not categorised properly, accessing them can be a right pain. Thankfully the Outliner does allows for proper categorisation through the use of Folders. I chose to sort my objects by their room and type. So all the floors in Test Chamber 01 will be in Test Chamber 01/Floors.


As for my project folders, they are already properly categorised and clean... well, except for one thing. Redirectors. Every time a Blueprint that is referenced somewhere in the code is moved, a redirector is created, serving as a reference to the object. However, redirectors can be removed. First, to make them appear in the Content Browser, one needs to go into Filters -> Miscellaneous -> Redirectors. Then they need to be right-clicked with the mouse and the Fix Up option needs to be chosen. This resolves the redirection and changes the reference in the code to the actual new location of the Blueprint in question.

Building the Lighting

In Robotrooper: Survival, the lighting setup was very dark. This played into the game's atmosphere and its gameplay. However, Simulation's different. The game's atmosphere is a lot less dire and a lot more relaxed. In that sense, Survival and Simulation are a bit like ying and yang.

I built the lighting once to see how it would turn out. I was expecting it to be quite dark, considering most of the game takes place in closed off areas with no windows... And I was right.

Fixing the lighting was not difficult, however. I needed only to play with the level's Skylight. I changed its mobility to static (and thus making its light dynamic rather than static) and played around with the Intensity value until it was just right. And voila! The game looks great!


One issue I did notice though were Text Renderers. The lighting made them very dark and hard to read. Luckily the solution was simple. I opened up the text material and repluged its vertex color from Base Color to Emissive Color. Now the text will be visible no matter the lighting!

Testing

I've run several test runs of the game throghout development and caught and fixed many bugs/imbalances then. I've had some close friends test the game now too. The game does have a pretty steep learning curve, but all features seem to work as intended.

So I guess that's it. Game done. Now to put in that gun...

Comments

Post a Comment

Popular posts from this blog

Making the Game: A Simple Puzzle

Image
Having created the shockwave gun , I was ready to move on to what would act as the game's primary gameplay puzzle: Getting so-called "Cube keys" to "Cube-activated buttons" in order to open a door. Just as in the previous Robotrooper  instalment, these puzzles will slowly grow in terms of complexity throughout the game. First, I created models for the cube key, button and door by placing a few box brushes in the scene. Brushes are simple geometric shapes which can be used to create models of a limited complexity. After playing with the brushes and their " brush types " (additive or subtractive, i.e. whether they add or remove bits from the overall shape), I applied materials to their surfaces and converted them into static meshes, a process I still remember from my Foundation Year. I also added Simple and Complex collisions on them, which will make them "solid" in the game. Then it was time to create their blueprint equivalents. ...
Read more

How to Keep Blueprints (Mostly) Readable

Image
The Blueprints Visual Scripting system is a great tool for programmers and non-programmers alike. It can be used to prototype or to fully implement features into a game, and its visual style makes it easy to read... Well, most of the time. Blueprints can get pretty complex - connections between events, variables and nodes can often begin to overlap, it can be hard to tell where one event ends and another begins, etc. So it is no wonder that there's a whole blog dedicated to " Blueprints From Hell ". Here are two ways I try to keep my blueprints readable, at least to an extent: 1. Comments  - There are two types of comments in Blueprints - Node Comments and Comment Boxes . Node Comments can be added on top of a node to specify what it's meant to do, while Comment Boxes can denote what a set of nodes do as a group. This can help organise content by its functionality. Above is an example of a comment box from a previous blogpost. 2.   Reroute Nodes - The...
Read more