With that in place, weapons were next. So on to some hard surface modelling:

With a bit of magic and Blueprints you could collect and shoot the guns. At this point I prototyped a first level and playtesting was done in a group of friends.

Building the buildings

This was one of the first maps we tested. As you can see it is very open spaced. We did not like that, so a more closed map had to take its place. This is where the building system for buildings comes into place. You see I wanted a lot of buildings, with lots of variety, but did not have the time to modell each one. Inspired by Rollercoaster Tycoon's building system I created my own variant of this using construction scripts.

As you can see in the gif above, walls are 3x3m in size to be realistic, but also adhere to UE4 grid system. This system is very flexible, you can build windows, doors, roofs, pillars, etc. You can also build smaller walls and in an 45 degree angle. Special measures were taken to ensure that there was absolutely no z-fighting. Once a building was done it was saved as a static mesh and furniure and spawn points for items were placed and saved in a blueprint. Now you could choose a building and just drag and drop it into the scene. Amazing! Here is what you can acheive with said system:

The inventory

Apart from  the networking, the inventory was probably one of the hardest things to get working correctly. It was supposed to be drag and drop and work not only in the inventory screen, but also in the shop and in a dead players crate. Which posed all kinds of problems. Here is the solution I came up with: Each item is contained within one widget, I called them ItemWidgets. These contain information about their caliber, cost or wheter they came from a crate. This information is mostly stored in enumerations. These ItemWidgets can be dragged and dropped in the inventory screens. The inventory screens are all the same class, just populated differently depending on the current screen.

When an ItemWidget is dropped logic gets executed in the ScrollBox where it was dropped into, depending on whether the inventory, shop or crate screen is open. This logic is hard coded, because it is so different for each screen. This is not the best solution, but it is flexible enough for me to add Items in the future, without too much work.

A lot of edge cases also had to be tested and debugged. For example what if the player dies while in the shop? What happens if the game ends when the player has a crate open and so on. These were handled in the Inventory itself, becuase this logic has to be always executed, no matter the current screen.

Conclusion

This was just a look into some of the things I did for Mercy Break. Unfortunately I don't remember a lot about this project and did't document it, because I never intended on publishing it.

While a lot went right in this project it can be tidious to play and the player experience is not exactly what I intended. It is a lot of fun to play with friends tho. Some of the issues were adressed in a later version of the game, which sadly is still unfinished.

See here for mentioned Update:   Major Update in developement