Venturi DevLog #4 WIP Loadout Manager, Lua Scripting System Update
Last week we made a re-commitment to a weekly blog post detailing all things related to the development of Venturi and this week we have plenty more to talk about. We're going to play a bit of catch up, devoting this blog to some features that have been developed over the past couple months and then the rest detailing more recent work that has been done since the last update. Let's get started!
Loadout Manager
The UI is an integral part of any game, and we've made some pretty substantial changes to our UI over the last couple months that have left us pretty excited. If you tuned in to the blog last week you saw the level editor but that is only one of the many UI changes we have made. This week we would like to introduce our new loadout manager that is responsible for allowing players to view their inventory, equipped items, stats, and view of their ship.
The loadout manager has been in development for a couple months now and is still being designed and tweaked, but we're definitely proud to show it off in its current state. Players will use this menu to examine and modify their ships. They can mount items to their ship (things likes weapons, thrusters, and utility devices like shields), access their ship inventory, and see any applicable ship stats. The next important element at work to note is how the player will configure the loadout of their ship. Its simply just a matter of dragging and dropping from the mount points. The inventory of the player is just below the view of the ship which allows for simple swapping, dropping, deleting, equipping, and unequipping of items.
In the future we plan to expand out the ships statistics, item description, item search and filter, and inventory pane. As of right now those components are still pretty bare bones so there is not much to show. The loadout menu will be a single part of our larger in-game menu, which will eventually include the mission journal, achievements, map, and other important game information.
Lua Changes
We also made a few improvements to the Lua scripting system. Initially, each level could only have one Lua script associated with it. This script would define functions to respond to gameplay events like an Entity dying or an Entity entering a region. We realized that, for bigger levels, having a single Lua script could get unwieldy pretty quickly. There would be a lot of unrelated pieces of logic all intertwined together inside one file, trying not to interfere with each other. This would be rather difficult to achieve, not to mention unpleasant to read.
So, we decided that it would be much better to modularize the whole system and allow any number of Lua scripts per level. Each script executes entirely independently of one another, and they can be as large or as small as you'd like. The idea, though, is that each script will handle one small, indivisible chain of logic in your level. An example, from our previous blog post, would be turning a light on and off as the player enters a certain region in the level:
Ideally, this would be the only code in the entire file. It represents one indivisible chain of logic and it handles it nicely.
Having small, independent modules of Lua code brings us to our next improvement: the ability to enable and disable any Lua script at any time. We realized that, sometimes, we need some action to occur only once or only under certain conditions, as dictated by other Lua modules. So, we added Lua funtions that can enable and disable any other script, and another function for a script to disable itself. When a script is enabled, it responds to gameplay events as expected; when a script is disabled, it doesn't. Since each Lua file only handles a small piece of logic, we can do this very cleanly with no side-effects.
That's everything for this week—thanks for reading! If you have any feedback, feel free to hunt us down on on Twitter or Facebook. We'd love to hear what you think!
