By Ape Tavern
What is Grug?
Grug first started as a solo concept by Carson, with a few artists from Ape Tavern helping here-and-there. When the jam was announced, we were immediately interested in pursuing it further as our entry. We wanted to make a survival game with a unique identity, so we decided to focus on the caveman feel/vibe and made sure there were enough biomes to explore and enemies with unique behaviours. There were many ideas we wanted to explore but had very little time given the ambition of the game and the scope of its systems.
The Good
Scene is awesome. It is rough around the edges in a couple of areas, but these are obvious areas for improvement that Facepunch have already acknowledged. Iterating is very swift, and changes are represented instantly. The editor feels good to use, and you can even write your own editor tools with ease, which is a huge plus to the workflow.
ActionGraph was an unexpected pleasure to work with. It was perfect for embedding various behaviours into different systems in the game without crowding up the codebase. One way we took advantage of this was by embedding mission unlock and complete conditions into our mission GameResources as ActionGraph expression graphs, which were invoked and checked by our mission loop code. We were also able to embed behaviours into holdables (tools & weapons) and interactables (chests, doors, etc.) by writing custom C# nodes. By defining a few core behaviours and reusing them in graphs, we were able to continue embedding flexible behaviours while avoiding spaghetti graphs with the same copy-pasted behaviour.
The Bad
Performance is rough, but editor performance is particularly bad. We were struggling to get any development done in our main scene near the end of the contest, but Facepunch has acknowledged performance as something they are working to improve.
The resource system can be rough - it is common to need to force all assets to recompile after pulling changes from a teammate due to certain assets not recompiling. Some assets recompile for no reason upon startup. Renaming assets or components, or even adjusting the namespace of a component, will break all references to it in the editor. After renaming assets, leftover compiled files will haunt your game while you wonder what is going on. We ended up writing some editor tools to clean up leftover compiled files to address some of this behaviour.
Another challenge of the resource system is how it behaves when testing multiplayer locally. You can easily spin up a second client, but if you make changes to assets, or even prefabs and resources, you need to upload your changes to asset.party to see the changes reflected on the second client.
Conclusion
While the engine is not perfect yet, it met our needs without too much heavy lifting on our end. Most of our issues are a result of how new the scene system is. Our team lived through the entity days of s&box, and are big believers in what the new scene system is capable of. We could not have iterated on Grug as fast as we did without it, and we look forward to the future.
