Sandbox Logo
Page Header
calendar_today 3/31/2024 people matt chat_bubble 0 visibility 2k

Game Jam Winners

Winners Retrospective

By 
bakscratch
With the contest over we reached out to the winners of the game jam to talk about their process, what they liked and didn’t like about the game creation process inside s&box, We hope you find this blog an interesting read on the process of creating games!
x4

Squirtfire

By Carson Kompon

What is Squirtfire?

Squirtfire is a 2D arcade shooter with minimalist graphics, but this isn’t how the game looked when I started the jam. My initial idea was to create a top-down 3D dungeon-crawling roguelite that used the citizen model with various customizations for both the players and enemies. I was able to get pretty far in the first 2 weeks of the jam, but I quickly realized the game’s performance wasn’t going to hold up if I wanted to spawn any more than 25 enemies at once.


The Good

In order to save loads on performance, I decided to cut the citizen, 3D assets, and use of navmeshes from my game. The shift to 2D was very natural, and I was able to re-use the majority of the components I had already written without any modifications which was awesome. Actiongraph proved to be an insanely useful tool in my arsenal and I don’t think I can see myself going without it. The new Mesh Editor made it very easy to create each of the shapes for my game but definitely proved itself to be very limiting in its current state.

The Bad

The lack of a 2D scene view / 2D components became a nuisance very quickly as I just wanted to be able to do as many things as possible without worrying about depth while still being able to layer things appropriately. Since networking is still pretty early there is no lobby data other than maps loaded via a Map Component, so I ended up making empty hammer maps for each mode just so I could get the gamemode name from the metadata. All of these things can be worked around but the one that couldn’t be worked around was the fact that the game couldn’t hold up performance-wise when it was 3D.

Conclusion

All-in-all I really enjoyed the development of this game and it really goes to show how malleable s&box is as an engine, even with the existing quirks here-and-there that need to be worked around. The ability to very quickly pivot from a 3D game to a 2D game with little-to-no changes and quick iterations is phenomenal.
x3

Dark Descent

By Fortune

What is Dark Desent?

Dark Descent was an idea I've had knocking around in my head for a long time. The initial pitch being "an old school dungeon crawler game with a melee system similar to games like Mordhau and Chivalry".  My first prototypes for this go all the way back to when the entity system was still a part of s&box.

The Good

The scene system. Wow.
I've used s&box a lot since getting access way back in 2021. The scene system was easily the best decision they've made in regards to s&box's development. It's like Unity, but without all the awful stuff Unity is known for.

If you've ever worked in a larger project in Unity, you know that iteration time shits the bed. Just opening the project can take 15 minutes, let alone running a larger scene. Not so in s&box, opening the project, making changes, hitting play... it just works. It literally takes less than a second to start testing my game in the editor. This is the fastest I've ever been able to iterate and it feels really, really good.

All the work facepunch put into this system over the years has paid off tremendously.

The Challenges

My friend, anotherSeeker, modelled and rigged the skeletons we use, and we decided to just use that as the player model. After that, I made all the animations for the player and npc skeletons (except the wizard, that was anotherSeeker <3).

Animation is not my strong suit, I'm a programmer first and foremost so this was probably the most challenging part of the whole project for me.


Dark Descent doesn't use viewmodels, there's just your actual body that's being animated. Your camera is attached to your skull bone and your mouse movement tilts your pelvis instead of rotating your camera. It took a lot of iteration to get this all blending correctly. Making sure the hands don't move relative to the camera when you're looking up and down was particularly important (and difficult!). This means that you can have a sword in your hands and everything stays where it should when you're looking around while playing.


The Bad

Performance sucks big time but I think we all know that, so let's talk about something else that bothered me while working on this - prefabs.

Prefabs, as they are at the time of writing, really suck. All they let you do is reuse stuff that you've sequestered away in another file. However, that's where their usefulness ends. You can't modify them, add children to them, or functionally alter them in any way in the scenes you've placed them.
You can't make prefab variants, or inherit from prefabs at all. So if I had to make a change to how NPCs worked, I had to make changes to everyone individually. I couldn't even modify the health or damage of my NPCs without having to make a whole new prefab for that.

Conclusion

s&box has come a long way since I first got access and I'm very excited to see where it goes next. I really think facepunch has made something special here, that stands out from other existing game engines in meaningful ways. This was my first time competing in a game jam and I had a tonne of fun and I'm looking forward to the next one!

Rogue Arena

By Eagle One


What is Rogue Arena?

Rogue Arena is a four player action co-op game where you and up to three friends must fight waves of fantasy monsters to earn your freedom. 


The Editor

The scene system is amazing. Coming back to S&box after an extended break was really smooth and took almost no time at all. The iteration speed once all the nice drag’n’drop properties are setup is truly incredible. Using ExecuteInEditor to preview how projectiles will fly or making a custom AssetPreview for game resources to preview clothing sets makes things so much easier to work with and nicer to look at. And it’s so easy too.
Multiplayer development

Hot loading is often overlooked but combined with the easy networking might be one of the best things about s&box development. Being able to debug multiplayer in real time with anybody in the world with a very basic setup feels like genuine wizardry. Playtesting and making minute changes to damage, spawn rates, and other game properties makes the process of making a cohesive game so much faster.

Performance troubles

It’s a well known issue but performance across the board is not good. The profiler doesn’t give a lot of very good, actionable information for performance issues on our end and having to plug in an external profiler is more trouble than it’s worth. At the moment, most of the performance issues boil down to issues with s&box rather than with our project, which was sometimes frustrating. 

Growing Pains

While s&box is changing, things tend to sometimes slip through the cracks or get their priority reassigned. That’s fine and part of the development of something like this, but especially in an artist driven system we’ve hit a lot of bumps along the way that seem a little overlooked. 
The legacy particle editor has its downfalls but the new scene particles just seem to replicate the cluttered workflow as one big spreadsheet per particle system. Particles need tools that aren’t just component property sheets.

Conclusion

S&box is clearly going places, and the vision in mind for the future of this engine has never been more clear. This feels like a game engine made by game developers for game developers. There’s nothing that compares to the absolute passion this engine inspires in our developers and the people we work with. It has its hiccups but it’s clearly improving every day and you get the impression that the engine, even in its current form, is a sleeping giant waiting to take on the industry in a big way. Eagle One Development will always be grateful for the opportunities s&box and facepunch have provided us. We are excited for the future of this engine as a whole. It’s hard to believe we managed to make this game basically from scratch in one month.
x2

Grug

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.

x2

My Summer Cottage

By Small Fish

What is My Summer Cottage?

My Summer Cottage is a Finnish survival simulator. Want to relax in a sauna? Go fishing with your friends? Hunt local wildlife? Then this is the experience for you! It blends the normality of your average day in Finland with ridiculous random events to create a dynamic world for the player to explore.

If you're interested and want to read more, our blog goes into further detail regarding the development process: 

The Good

The transition to the scene system was a breath of fresh air compared to the previous s&box entity system. Being able to drag and drop events, shop items, NPCs, etc. directly into the scene and instantly test them sped up our ability to pump out content for the game. Features like the character creation would’ve been extremely difficult and time-consuming to make in the entity system.

The ability to create editor widgets and gizmos also proved to be extremely useful. We could make gizmos to position items on the player’s hands, tools to generate icons, or widgets to display prefabs with specific components; all without needing to run the game.

From day one, we knew the game would heavily rely on ActionGraph. This meant that if we misjudged how stable it was or what it was capable of, we would need to scrap it all and go back to the drawing board. ActionGraph ended up being extremely stable and reliable; it even received major updates during the competition, which massively sped up our workflow! Not to mention, even the artist could pitch in! Shout out to our Small Fish intern, Ziks.

The Bad

A big map resulted in everyone working in one main scene. This was a huge pain as other people’s changes sometimes didn’t load correctly, so we would always override each other's work. There has to be a better way to work on the same scene. It was more manageable with the entity system due to hammer prefabs, but the new scene prefabs don’t share the same advantages.

Particles are now an afterthought, you don’t feel like an artist anymore when creating them. The new component-based particles are also missing many features and the results are underwhelming. Component particles have their uses but we are hoping they’re not the be-all and end-all. A standalone tool for creating particles would make for the best experience, some kind of particle graph, perhaps.

Conclusion

Every single Small Fish member started working with s&box in 2021. We have been there to witness the engine evolve and undergo major growing pains. Out of all the iterations, working with the scene system has been the best experience by far (not just because we won £10,000). Not to mention, the scene system is only a few months old! We are excited to see where the next few months take us as Facepunch continues to refine the development experience.

Comments