»Notice

This blog was actually written around/before July 31, 2026. Time of writing currently is October 13, 2026. Garry just put out a post which addresses some of the issues I have with s&box. The way I feel at the moment is basically: If they fix everything and figure out a way to save this, then I'm glad, we'll have another engine to use. But I'm just past the point of caring that much about it after having put up with all the negatives for 5 years. If they succeed, great. I'll use it again in the future when/if the experience has improved. The fact they are deciding to go free2play earlier than planned (later this year) is good and addresses one of my complaints directly. I could playtest my games with people I know properly without having to ask them to buy the game for $20, I mean $10.

»Website Update

I've been working on other stuff lately but felt like doing some more general programming, rather than the usual game stuff. The blog/static site generator needs some working on so I decided on that. Where I left off last time I had mentioned some of the features I needed to add/things I needed to fix.

You'll notice that I've got jump to heading working! Just click the » next to headers and it'll link to the header id correctly.

I haven't been as consistent with headings as I should've been, but I probably don't use them correctly anyway. I like to use h1 as overall general section titles, h2 as more specific, and h3 as a specific subsection of a section of a general section. H2 is smaller and blue-ish and h3 is even smaller and grey-ish, the darker the color the more specific the heading is.

»target="_blank"

I also made links open in a new tab. It's not something that is hard, at all, I had just put it off. It's a little more tricky when doing this with a static generator. I can't remember what made it easier using web frameworks before, but I'm pretty sure it was easier somehow. Basically the issue is that if I were to check link type nodes when doing my pre-cmark-render pass, I don't have any useful information about the link. It could be a link from the homepage linking to a blog post, or it could be a link that I would want to target="_blank" on.

There's not really a good way to know context of a link only given its url. I could make a custom link type but it's probably just easier to to do it on the JavaScript side again, because over there I can get the id and classList/className which is the best indicator of whether an <a> is just a normal embedded Markdown link or not (because I specifically style or assign id to links such as jump-to-header mentioned before). If it's an embedded .md link then it's most likely going to be used like this, so it's probably safe to set its target to blank so it opens in a new tab.

»Funny Date Thing

So, the site used to be written in web frameworks. A different one for each point in time. I won't go over it again. Before, it was written in Sveltekit. For flagging a blog as new, I embedded some JS to add the "new" CSS class to the blog list element. When I rewrote the site as a static generator in Odin, I mindlessly forgot about the "static" part. I wrote the code for flagging a blog as new in the actual Odin code. At compile time I was marking a blog as new, so whichever ones were new at the time were forever new on the actual web page. I dipped into the JavaScript land and did it correctly on the client through a script.

I would have liked to have had zero JavaScript but whatever. It's funny having to do date stuff on both the static Odin end alongside the JavaScript end. Subtracting the date was more involved on the JavaScript side than the Odin side, which is hilarious. Obviously, I mean without importing 300 random NPM libraries or something. The only dependency I have at the moment is HLJS for syntax highlighting since it's way easier than doing it myself, and it works really well.

»s&box Game

I've been working on a game in s&box a lot. I'm happy with the idea of the game. It's not even a bad idea for it to be on the s&box platform either, it's just that I imagine it more as a game you play with friends.

Unfortunately, I'm expecting a pretty large sized friend group to play it. The ideal is at least 8v8 players, 6v6 might be fine. It seems like you're lucky if you can even 2 or 3 people together at the same time to play something, so 16 seems unreal. There's a friend group I'm in that does manage to get 16-24 people together, one night a week though. It's been fun working on this game but my frustrations with s&box are impossible to understate.

»Issues

There's a myriad of issues with s&box. I've genuinely forgotten some of them because of how long the mental list in my head has gotten for them.

»Performance

Performance is terrible. Particle effects, especially ones that have alpha transparency, are incredibly lag inducing. If you open up the Sandbox game (sandbox as in Garry's Mod sandbox) and you walk up to a wall and shoot it with an automatic gun or quickly, which spawns the impact particle effect prefab, your framerate will drop by at least 75%. My game is a fork of Sandbox because it gave us a bunch of free work already done for us, such as weapons and inventory (which ended up getting ripped out and cleaned up as a base engine feature, which is nice). I did a small playtest in our game with one of my friends and just with the 2 of us shooting at each other, the game slowed to a crawl. That's only 2 people on a map causing frame drops, imagine 16!

I was talking to a friend about this and they said something in response that would usually be completely fair to say. "It's too early for them to optimize since they're still adding features." That'd make sense if s&box were simply a game. It's not simply a game in early development, it's an engine and it's not in early development anymore. You have to buy it for $20 to use it. It's not labeled on steam as Early Access either. Also, engines are always adding features! Unity, Godot, Unreal, etc. are always evolving and moving forward but they still (up to reader's interpretation of the word at this point) maintain an optimized renderer. The engine is never "done". I believe Garry himself said this is a 20 year project for them.

It would be completely different if we were in the developer testing phase still, or if it was even marked as early access on Steam which it isn't. I was in the dev preview since 2021 and during that time I did give them complete grace and patience when it came to optimization because obviously I wouldn't expect it at the time. Any reasonable person shouldn't have expected it to be optimized yet. It was very early in development. They still didn't even know what exactly they wanted s&box to be considering it went from "small game mode creation platform" to "entire game engine with plans to be better than Unity and game platform" during that time.

The engine is released now, it's public and been out for 3 months at the time of writing. Lack of optimization cannot be excused by "oh, it's in heavy development still!" I do see their commits and weekly posts. I genuinely look forward to every Wednesday to read about the new update. This week we didn't even get one though. Not reassuring. But I do see them trying in some areas. The issue is that, for example, s&box doesn't even have any culling unless you are using a hammer map. You know what does have culling? Terrain and terrain clutter. I would have expected the integral scene maps to get culling first.

Don't get me wrong, it does a lot of things better than Unity, and Godot too. Most other engines will never have the amazing hot reload features of s&box because they weren't built for it like s&box was from the start. I don't think you'll see it in Godot in the next few years, if not ever. In Godot, C# is a second class citizen... and your raycast results are a heap allocated dictionary 😖. Plenty of people very much still use Unity often enough, despite their terrible PR. I'll confidently say that were it not for Unity CORPORATION's terrible blunders, moving to Godot is a downgrade in most other respects.

I make sure to include the good alongside the bad when talking about s&box. I still do think it's the best engine you can work with, in some ways more than others. There are always trade offs, that's to be expected. Lately though after using it so consistently and often again, I'm just frustrated and want to focus on the bad more for once.

»Slop

It doesn't have many players and the reviews aren't so good. At the time of writing the player count is 480 and the reviews are mixed at 55%, this could very well have changed drastically since! The player count and reviews are things I can somewhat reasonably ignore as they can be fixed with time. Garry's Mod wasn't an instant hit when it was first put out into the world either. However, in this case, this platform needs players badly. The entire concept of the Playfund demands a considerable amount of players. Why make a game and put it on s&box if no one is going to play it AND you're barely gonna get pocket change for it? Meanwhile 100% "vibecoded" (vibecode is a terrible and almost seemingly purposeful misnomer for "AI coded" in my opinion) clicker idler Roblox tier slop or RP slop dominate the Playfund.

Why bother? The nature of the Playfund encourages player retention farms, instead of passionate game development. Yes, we've had slop in different forms for many years. Unity shovelware, asset flips, lazy ripoffs, etc. Yes, you had to compete against all of that when you put your game onto Steam too. The difference is the accessibility and sheer volume now. Not only has game development itself gotten much easier over the past 20 years but, now you just tell >insert latest craze AI user-facing friendly model name here< to "make me a game about x, y and with elements of z" and it'll do the work for you in no time.

I'm not going to get too deep into the (pointless) AI argument itself here. The truth is that this is how it is now and I'd struggle to believe it has had no effect on the volume of slop. All else equal, and we had no AI today, there would be far less slop games to compete with.

I'm not trying to go after them or Garry and scream they aren't doing enough or tell them what they should do about it. When it comes to actually solving the issue, it's not easy. How much AI involvement should mark something as being made with AI? If you used 1 AI placeholder or had AI generate an array of mesh vertices (definitely something I can understand wanting to automate at least because I hate writing them out by hand), does that mean it's an "AI slop game"? I think they're more pro-AI than I am so that could bias whatever they do a bit in favor of keeping AI stuff around.

»Editor Bugs

Sometimes, things in the editor just don't work. I was using the scene mapping tools the other day, duplicated a block, and then that block could not be interacted with in any way with the mapping tools. Couldn't select, move, rotate, resize, etc. it at all. One of my favorites is when components on a prefab or in a scene randomly get removed. I think this happens during a hot reload usually and it's NOT from me changing the name or namespace of a component either. I remember the problem used to be worse than it is now, making debugging a difficult process.

You can't really use a proper debugger with s&box either, as I prefer, instead you just print stuff to the console :). A lot of times, things weren't printing suddenly. After a few minutes I'd realize that s&box decided to just remove that component or more off of the GameObject for no reason. Counterproductive, yeah?

»No Export

s&box "let's you" export your game to a standalone executable. Except it doesn't yet, legally. Even when they do plan on letting you do so (in at least a year so says Garry), and I do mean letting. You'll have to email them, and ask them for permission. In turn they have to ask Valve for permission, or something like that. I don't know how reliable this following tidbit is but apparently: "Valve doesn't want slop games made with their Source 2 engine put onto Steam". That could be true, I'm just uncertain if it is confirmed as their reasoning for this chain of permission asking.

The big issues with this is that I have a group of people I know that are PERFECT for playtesting this game with. However, I would never ask ANYONE to drop the $20 to buy s&box just to playtest the game for me. That's criminal, especially given the lackluster state of s&box itself right now.

The thing is, you can literally export the .exe right now, it's just unsupported and the feature hasn't been worked on in a bit. I did export a build and test it to see if networking worked at all. It didn't. I left the Steam appid set to Spacewar (480), since that's the default and I know you can test Steam networking with it It didn't work, we couldn't connect to each other. I'm not sure if it was me doing something wrong, or if a simple fix would have worked, but I moved on.

»Tough Spot

All this frustration pushed me to consider moving away from s&box. Switching to Godot wouldn't solve every problem, and it would bring more of its own. Godot is not a bad alternative, it just has trade-offs, as with everything. One great thing about switching to Godot is that you can export your game and do whatever you want with it.

Even just not having the hot reload ability of s&box is a huge downer though, not to mention the plenty of other must-haves s&box includes that I've already gone over. This is a tough spot to be in.

»The "Custom Engine" Debate

Sometimes we tell each other to just make our own engines. This suggestion by nature must originate from people who have the tendencies and attitude that enable them to tackle this problem much more easily than others. This issue is complex. The number of variables which should help one decide with path to take are staggering. We are discussing game development after all, and games come in so many forms. Remember that this a medium that somehow Pong, LSD: Dream Emulator, and Call of Duty all share together. It depends on what the game is and it might not always be the best idea to do it all yourself, even if you know how.

I'll completely dispel the obvious to be clear. I'm not talking about general purpose engines. Making a general purpose engine (by oneself) is a misdirection of effort unless for some specific goal such as learning, or if you are ambitious and want to challenge the big dogs. Effort is much better pointed towards just making games how they used to be made: the "engine" is just the wrapping around the actual game, only serving the needs of that game in and of itself.

For small games, yeah sure. I still think it can be spooky and potentially make more work for oneself, but making my own "engine" for small games isn't something I've written off. When it comes to writing games "from scratch", like I try to do in Odin or C# sometimes, it's not so bad. I consider using graphics libraries or frameworks to still be "from scratch" enough. It's still hard enough as is. Raylib, SDL2/SDL3, OpenTK, Monogame, FNA are some good examples.

There are games that are better off just being made in a custom "engine" (again, it's just a thin wrapper around your game logic) and some that really should just be made with an engine. Honestly, I believe it just comes down to tendency of the user more often than not. People who like taking the hard path and having control are the types of people that will make their custom engine regardless of if it would have been provably more efficient and straightforward to do so in an engine.