It has been well over a year since the last article we posted about VoidGate. Some might take this to mean the project is dead, but that is far from the truth. Instead, for the past year we have rewritten the code for the game. Now we have mostly finished that and are able to focus once again on creating content.
So, what was the reason for rewriting the code? The game is being built in Unreal 4, and it had been completely written in Blueprints. Not a terrible thing in itself. A strange route to go, considering I am far more proficient in C++. So why Blueprints? Partly to familiarize myself with the system (although I had spent a great deal of time prior learning it), and partly out of enjoyment.
However, as time went on it became messy and difficult to manage. The greatest strength of Blueprints seems to also be its greatest weakness.
It's easy to build quickly in Blueprints. However this speed leads to a lack of maintenance. Code just grows without being trimmed and optimized. Obviously this is not the fault of Blueprints itself. The fault lies at the programmer. But even a good programmer falls easily into the temptation of laziness. And before too long, it has become an untamed beast.
An example of this is our code just to handle the dragging and dropping of inventory items in the GUI:
And the result of this was very buggy UI which is one of the more difficult aspects of a game to develop (although this perhaps depends on the developer). In this case, fixing one bug meant creating more. It lost the flexibility and power of modular, small purpose functions.
With the rebuild, it hasn't been completely moved from Blueprints, as some things are nice and easy to do in Blueprints, and for things where optimization for speed isn't as important, like menu based UI (inventory management).
Cleaning it up, it's now much more manageable:
Another easy trap to fall into with Blueprints is scope. Blueprints makes it far too easy to break a rule stressed by experienced programmers: keep variables and objects within scope. Although Blueprints has the ability to restrict access, like making a variable or function private, the ease of using makes it too easy to remember this feature even exists. Because of this the many complicated systems of the game becomes far too coupled. Even as an experienced programmer who understands the dangers of this, and the significance of decoupling fell into this. Again, Blueprints is not necessarily to blame for this. It's the programmer's job to avoid this, because it's easy to do in any language.
Please don't misunderstand any of this. I'm not speaking ill of Blueprints. It is a very interesting form of programming, and I enjoyed it a great deal. I say this despite C++ being my favored language. To avoid a tangent I won't go into more details. Blueprints is powerful, easy, and convenient.
As a wonderful bonus, through the process the majority of the C++ code has been exposed to Blueprints in order to rebuild it in layers. And this has been a very fun and interesting experience. The sheer power and flexibility of Unreal is both amazing and humbling.
Another advantage to rebuilding the game is moving a huge amount of data away from Blueprints and Data Tables into JSON. This gives easier access and flexibility with modifying game details, for one example adjusting balance. Rather than having data placed inside of Blueprints for items, the data for equipment and items is now held in JSON. This is then used as a basis for how to randomize the item. The same is true for monsters and player data.
We plan to make it possible for players to create their own JSON files to adjust the game to their liking. And upon starting a game, be able to select from a list of possible configurations. How far this moddability will extend is yet to be decided and seen. Hopefully though, this will increase the replayability of the game.
And now with the rebuilding largely done (there are still a few systems to touch up on, such as magic) we can turn back to building content.
As you can see from the pictures showed, we started our focus on rebuilding the forest areas. This is the third or fourth time building forest maps. We experimented with a few methods and even tried a voxel system. Voxels turned out to be a mess and weren't working the way we hoped, so we scrapped it. We weren't planning on allowing the land to be modified by the player, instead we wanted a way to develop varied terrain. This caused some gameplay elements to become much more complicated.
So now we are taking a simpler approach, but so far we are happy with it. It has some ways to go, but it is promising. We are excited to see what becomes of it.
And with that we come to the end. Thank you for your patience and support. Here is a short video demonstrating the new dynamic day/night cycle in VoidGate.
