Our second gamejam finished earlier this week, and we got a lot of fun entries. Congratulations to all the winners, and everyone that took part. It's a shame that so many people enter but so few win, there were a LOT of good games in this batch.
There's a couple of ways we can improve the GameJams I think. First of all, we need to prohibit entering games that have been released before the jam. It's against the spirit of a jam, in which things are created. Secondly, we probably need to do theme or something, to help avoid people secretly starting work on their entry months before the Jam.
Something I found in this one is that I enjoy way more the games that are short and simple. I don't want to play a jam where you spend the first 3 minutes in a menu, picking your character etc. I want to get straight into it. I'm a baby with no attention span.
So that makes me wonder, shall we have different types of Jams. I think it would be interesting to have more of a tech-toy jam, where instead of making a "game" you make something more like a toy, using some kind of interesting tech you came up with. I'm thinking of things like the way you can draw on windows in Alyx, or the rope physics in TLOU2, or the snow in Red Dead. Cool stuff to play with.
Talking in the discord, a bunch of the developers think exceptions are normal. They think we should silently hide them and just accept that errors happen.
I disagree with this. If an unhandled exception happens then you fucked up. If we ignore it, it could propagate and cause more errors. It could stop your game from working. It's a shitty experience for end users.
In an attempt to solve this I wrote a whole exception reporting system, so you can go into your organisation or game, and see all the errors reported. Then you can fix them. And then you have no more errors.
We felt it was unfair to do it without warning, but at some point in the future we'll make it so when a player gets an error in a game they're immediately disconnected from that game.
Work is progressing steadily on our upcoming human characters.
Under the hood, they use the same rig as the Citizen characters; this is going to let us share a lot of work between both sets of characters. And right now, it means everything already "works".
Which is to say that it does look quite janky, as all the animations and poses were made with a very cylindrical, big-headed "sausage man" in mind... but everything already works: walking, running, swimming, jumping, rolling, sitting, height scaling, ledge-grabbing, etc.
This also lets us share animations between differently-proportioned body types easily.
This is just the first step in getting them up and running; their animations will be remade with them in mind, and their animgraph will also most likely split off into a far more simple version.
A few months ago Lewis designed a brand new Main Menu, and I spent most of this month implementing and fine-tuning it. The goal is to make the Main Menu feel less like a console game and more like a proper games library.
Nearly everything is broken up into different modals now, including a modal that tells you a bit about a game before you jump into it. We're hoping this new flow encourages engagement like rating and reviews so it's super easy for players to instantly give feedback on games.
There's still more to be done, and things will likely change again, but this step was essential for us to realize the flaws with our current Main Menu and cleanup proper.
Sometimes you want your world to be very, very big. Here's a library I've been working on to make that easy, by streaming in cells at different levels of detail.
Cells can be loaded however you like: hand-crafted or procgen. As a demo project, I've used it with my old SDF library to generate infinite editable terrain.
It's a work in progress, but you can play around with it here: ziks.sdfworld
You can now record any user stats without having to define them in the backend first. This is very useful if you want to do things like record how many times someone shot a type of weapon.. because now you don't have to go in and manually add a stat for each entry. You just do shit like..
Similar to stats, leaderboards no longer need to be defined in the backend. They can now be built on demand, from any player stat.
var board = Sandbox.Services.Leaderboards.GetFromStat( "facepunch.ss1", "victory_elapsed_time" );
board.SetAggregationMin(); // select the lowest value from each player
board.SetSortAscending(); // order by the lowest value first
board.FilterByMonth(); // only show results from this month
board.CenterOnMe(); // offset so I'm in the middle of the results
board.MaxEntries = 100;
await board.Refresh();
foreach ( var entry in board.Entries )
{
Log.Info( $"{entry.Rank} - {entry.DisplayName} - {entry.Value} [{entry.Timestamp}]" );
}
When Garry goes on holiday he gives us a challenge to do while he's away. The whole s&box team get together to work on the challenge.
HC2 (or Cogwheel, pending a better name), is a procedurally generated survival game. We spent a week from start to finish, and are really proud of how it turned out!
Here's a playthrough video recorded by one of our devs:
During our hackweek our entire development staff are encouraged to take a week off doing what they normally do, and work on something else. Some people use this time to try to learn another discipline, others take it as an opportunity to try to make something different.
I don't know how to use SFM. I've tried multiple times. I don't understand it. Can I make something that I do understand, that does make sense? This was my hackweek project. It's basically Unity's Timeline.
I had a bunch of stuff planned but I ran out of time, so all you can really do is keyframe and lerp gameobject's and component properties.
You can now export your game to be standalone. It's not perfect and you can't distribute your exported games, this is a tech demo, so we can show Valve how it's going to work in an attempt to get their permission.
Here's a clip of me exporting our testbed game, and then running it - no cuts, no speedups. You'll notice that launching the game for the first time is a bit slow, we're aware of that, it's something we'll fix.
State machines are often a great fit for stuff like NPC behaviour, interactive objects, and even the main logic of round-based games.
This hackweek I built an editor to let you quickly throw state machines together, using Action Graph for transition conditions and to make stuff happen when entering or leaving states. You can even inspect a live instance to see which state it's in, and which transitions are taken.
It's holiday season, so a disrupted month, but it still feels like we achieved a lot.
I'm trying to focus now on the player experience more than the developer experience. So I'm looking at improving the menu system, the flow into and out of games, trying to retain players, making things actually work.
So over the next few months we're going to improve the main menu further, add achievements and gamerscore, and create the official sandbox game mode.
We're looking at getting the Steam store page up imminently too, but they're making us jump through a few hoops to get there. I think because we're giving access via the developer preview, but not actually selling it yet. Like Deadlock.
So I gotta say I agree mostly with your views on exceptions Garry. It's important to understand what is happening and why it is happening. For warnings this can mean you analyze it, understand what the warning is saying, realize it does not apply to what you are trying to do, and so you suppress it in that specific case, though for me this is rare. For an exception something is clearly wrong that needs to be fixed.
However I think in a release build it may be desirable to try and keep the game running. Lots of frameworks take this approach. Unity... JavaScript... PowerShell (by default).... uh... Visual Basic....
I think it should be ultimately up to the developer. PowerShell and VB let you turn on or off this behavior. It may make sense to add a project setting in s&box for this as well. Maybe for in-development works you want it on (or just break to debugger when an exception is hit, like with .NET programming with VS) and with a published gamemode it's off, since presumably any errors by that point were unanticipated and you should at least try to keep going if at all possible.
Personally I would want to see and fix all errors in my code but I can understand there is situations, especially in production, where you might just want to cross your fingers and try to power through.
I suggest that you give developers the freedom to choose whether their games insta-exit on exception or not.
Some games can be played adequately without the need to handle every single possible exception in existence
(Examples: solo games that don't need to account for perfect data parity with servers,
Non-critical multiplayer games (ones that don't value online/global competition) in which the gameplay can sometimes be enhanced when things go wrong).
Unhandled exceptions can also set off a cascading effect that not only reveals the exception itself, but what would happen if the exception was allowed to continue (whether good or bad).
Revealing the possibility of further improvement in safeguarding mechanisms in cases where exceptions do occur. Or revealing interesting/creative mechanics that can be exploited to enhance the gameplay rather than stall it.
Hello for exceptions i suggest a leaderboard, when game run into exceptions too frequently, the game become hidden from people, this prevent deception from s&box
Always happy to see the continued progress on this. I've been checking in every few months when I remember to for the last couple of years. It's been a delight seeing the direction Garry is taking things in, and the continued development efforts of the team over this long stretch of time. Soon will come the time where you receive the validation that all your efforts have been worth it. Best of luck everyone, keep going!
Comments