sbox-issues
sbox-issues copied to clipboard
Facepunch
Ship Engine Version with Published Game Builds
For?
S&Box
What can't you do?
Go a week without my catalog of games breaking due to api changes, mesh editor changes, networking changes, ect.
As-is, asset.party rarely has any games in a fully functioning condition since S&box is constantly being updated, (which is good) but leaves games made in previous versions unplayable (which is bad, and is leaving a bad impression on many people whenever keys are given out).
So I would like to propose that engine versions are shipped separately from S&box (the platform/launcher) and are instead tied to the games being played.
How would you like it to work?
Whenever you publish your game to asset.party, it should include the current engine version in the metadata of your game.
As a user, when you now go to play any game in S&box (the platform) it will first check the engine version the game is using, and download it before downloading the game (assuming you haven't already played another game on the same engine version before).
Now S&box (the platform/launcher) can reference the engine version without being packaged in to either the launcher or with the download of each game (like how base.dll is). This means games stay the same size, the development process stays unchanged, and developers can feel safe when they publish a game knowing that it will remain there without breaking.
This would work best alongside #5472 (allowing users to specify engine versions themselves, allowing them to keep their games stable while s&box continues to evolve)
What have you tried?
There are currently no other options other than waiting for binary export support and publishing on other platforms (which I feel defeats the purpose of s&box as a platform. especially when it comes to multiplayer games/games with addon support)
Additional context
I realize the infrastructure changes required to do something like this would probably be monumental in size. But I genuinely think something like this is necessary if S&box (the platform) is to survive. All the negativity around S&box (from a player's POV) mostly comes from 90% of the games being broken due to the constant changes (which are always for the better). So if players continue to have this perception then it could affect the perception of not only the platform but all games released on it moving forward. (Not to mention the crazy expectation that's been built for all developers to update their games whenever there's a new s&box update)
I've also given out keys to a handful of fellow gamedevs who tried some broken games and were very disappointed when I told them that games update automatically when the platform does. This change benefits both developers and players in such a way that I really cannot understate. I genuinely believe this is a really important feature to have for S&box.
As an Unreal Engine dev, I believe this change is 100% necessary for the longevity of the engine. I myself move between various versions of UE constantly based on how stable the project I'm working on needs to be. It's also telling how many people are still using UE 4.27 for brand new games because it's just tried and tested and they won't have to deal with bloat or anything else.
As a new SBox dev it has been very disheartening working on something knowing it probably won't work in a month and I should be able to focus on making the game and not trying to make something I can maintain as a live service just so it functions, it's honestly the biggest disadvantage and the one thing stopping me from making more projects in it.
While your solution to the problem is guaranteed to work under any circumstances, I think it's quite overkill.
At the moment, the game list runs on the engine, which means they would have to either make a launcher like the sbox-dev.exe one (or use a web page like Roblox 😉), or launch a second, older instance of the game. Maybe it's possible to somehow decouple the engine into a library so that you can run two versions of s&box in a single window, but in my uneducated opinion, it sounds like a lot of work that is not worth it.
Let's also take the download speed into consideration, especially with the current development cycle of roughly two "releases" per day.
What I suggest is to ship compatibility DLLs for the older games that will fill in the old API calls and whatnot. It will be both easier on the download sizes and easier to maintain.
Before I mention any negatives, I do understand that this engine is a work in progress. I'm perfectly okay to take breaks from s&box and wait for it to be in a more refined state. I thought it'd still be worthwhile to let developers know my pain points even though I imagine they will be addressed in the future.
Our game "My Summer Cottage" has been hidden and probably will be hidden for a while (if not permanently) due to this. We have experienced multiple engine-breaking changes since the end of the game jam and it has been only ~2 months.
I think the most annoying part is you don't even know when the breaking changes occur. I remember finding out that our character controller was completely busted due to animgraph changes by watching a YouTube livestream. Even more recently a popular Youtube channel attempted to cover our game but ran into an exception that completely made it unplayable (this was due to a footstep sound bug that was pushed to the engine).
I personally don't have any interest in launching my live game build every single week to see whether or not something has been broken. I can't speak for my entire team, but, I feel like this is partly the reason why nobody is interested in further developing "My Summer Cottage" after the game jam.
To be honest there were positives to be gained by hiding "My Summer Cottage" completely. I was unable to do multiplayer testing without the ability to push a new version to asset party. So at least I can push broken builds to asset party without messing up the live build for our players.
I'm still excited to publish a proper full-scale game using s&box... but I think it'll be in a year when issues like this are solved and game exporting is available.
To reiterate, I understand this engine is a work in progress... but I thought I'd just mention the conditions which lead to projects like "My Summer Cottage" dying.
To be honest there were positives to be gained by hiding "My Summer Cottage" completely. I was unable to do multiplayer testing without the ability to push a new version to asset party. So at least I can push broken builds to asset party without messing up the live build for our players.
Huge agree on this point! I'm sure it's planned but just wanna show my support for this to come sooner than later.
If your games are breaking due to updates from us, then that's a bug. We should NOT be breaking games now. Report these changes as bugs please.
If your games are breaking due to updates from us, then that's a bug. We should NOT be breaking games now. Report these changes as bugs please.
I understand, and have started going through all my games and trying to find the root cause of each issue. My main problem though is that most of the times things don't break because the engine is broken, but because it's changed (typically for the better). I don't really see this stopping at any point (because the engine should always be improving) which is why I proposed engine versioning.
I've started making issues for the engine-related bugs I've encountered (So far just https://github.com/Facepunch/sbox-issues/issues/5474)
But I would also like to compile a list of things that are broken in my games as a result of recent changes that weren't direct errors/bugs in the engine:
- Now that GameManager is ripped out (since Game class has replaced it) all old games that haven't been re-built no longer work since there is no compatibility layer for GameManager -> Game.
(Whitelist error: Failed to load type 'Sandbox.GameManager' from assembly 'Sandbox.Game').All games last-updated before mid-march are affected (but were not auto-marked as hidden). - VOIP Roulette is broken because you can no longer draw a Camera over UI (The UI layer always forcefully draws on top of everything).
- All models in Squirtfire (and my other WIP games) that were made with the Mesh Editor are completely gone since there was no JsonUpgrader path (or automatically exporting vmdls of the previous version to preserve them). This means people playing Squirtfire can't see some of the enemies.
- Any audio-visualizers that were based on the previously documented array size of 512 are now checking outside the bounds of the array and erroring now that the size has been changed (https://github.com/Facepunch/sbox-issues/issues/5394)
I will try my best to continue to report any bugs/anomalies in the future but sometimes it takes quite a while to construct a proper issue and I don't always have that kind of time. Even compiling this list took me nearly 2 hours 😅 It's especially difficult when I really only hear about these issues because players message me directly about them and I'm not encountering them myself. So I then need to set aside even more time to try reproducing it on my end to determine whether it's a facepunch-issue or a me-issue. This is all free volunteer work at the end of the day so please understand that it's hard to catch all of them on our own when we'd rather spend that time working on our games/engine tools <3
So, mixed bag, but:
- GameManager - should have never been removed if it broke games
- Camera over UI - not totally sure what we changed here, but I am sure we could find a way to revert
- Mesh Editor - a question for @aylaylay maybe on why compatibility broke and what we can do to ensure we keep it
- AudioViz - sucks but this is a bug fix, so nothing really for us to do other than say sorry.
I would hope that these things get much much rarer as we go on. We shouldn't be breaking games at all now, really. We should be designing our APIs in a way that guards them from breaking in the future. But there are two types of break.
- Compile Breaks - these are EASY for us to detect. I'll add some stuff in place to detect these breaking changes now so that our builds won't go live if it broke any games.
- Behaviour Changes - our fault and we should be being extra careful now to not continually break games.
One of the problems with accidental behaviour changes is that if we don't know about them for a long time, people will rely on the new behaviour, which means we end up breaking those new games if we fix it.
Breaking change to mesh editor happened a while ago and was explained why. Care is being put on maintaining compatibility, this isn't an on going thing.
I understand Facepunch's position here, you are actively making things better and improving things, but the main issue is that you can never conclusively say there'll never be any API changes/backend functionality changes/breaking changes of any kind for the entire future of the engine.
Many of these things can be bugs that need fixing, but occasionally something will simply be broken because "It needs to be broken".
And then it puts 3 year old projects that haven't been touched by their developers in years in non-working states with the developers themselves both being none-the-wiser and likely probably not wanting to go through the effort of fixing an old project.
I don't think we need versioning the same way Unity versions.
Sbox doesn't need 2021.1.0-28 then 2021.2.0-19 then 2021.3.0-38, a total of 85 versions in a year, the same way Unity does.
But the idea of say a "stable" release for a year, or even a 4 month period, people could target and develop for then could launch instances of in the sbox-launcher, that might be a practical solution.
This would illeviate issues with older games breaking down due to changes, but doesn't require the same constant versioning Unity does. Staging can have constant unversioned updates the way it does right now, and people just have to optimise their releases to the closest "stable" version.
You'd still have to launch a new sbox instance when using the sbox-launcher to launch a game developed on an older version of the engine, so that issue would still exist, but I can't really see an easy way to make this problem go away.
I guess you could turn every feature of the engine into a library?
Then you'd have versioning for modeldoc, shadergraph, actiongraph, hammer, whatever else.
Someone can say "This project is made with 13.4.2 version of the mesh editor", and simply hotload that library, but the overhead of a solution like that seems ridiculous if at all feasible.
Hard agree with @MD485 here. I can't speak for how viable version control would be for games on the platform, but for standalone there 10000% needs to be stable versions devs can use with the guarantee things won't change/break. It's going to be a dealbreaker for anyone shopping around for an engine if there's only one version that is subject to change, even if it is bugs (which is best case).
So, mixed bag, but:
- GameManager - should have never been removed if it broke games
- Camera over UI - not totally sure what we changed here, but I am sure we could find a way to revert
- Mesh Editor - a question for @aylaylay maybe on why compatibility broke and what we can do to ensure we keep it
- AudioViz - sucks but this is a bug fix, so nothing really for us to do other than say sorry.
I would hope that these things get much much rarer as we go on. We shouldn't be breaking games at all now, really. We should be designing our APIs in a way that guards them from breaking in the future. But there are two types of break.
- Compile Breaks - these are EASY for us to detect. I'll add some stuff in place to detect these breaking changes now so that our builds won't go live if it broke any games.
- Behaviour Changes - our fault and we should be being extra careful now to not continually break games.
One of the problems with accidental behaviour changes is that if we don't know about them for a long time, people will rely on the new behaviour, which means we end up breaking those new games if we fix it.
I believe the reason why Carson is pushing for versioning is because there will be positive changes to the engine that will have to break games. For instance... I don't see any reason why GameManager should exist at all. Is the plan to keep around GameManager forever just because there are a few games that initially relied on it? or am I misunderstanding?
GameManager removal being reverted seems like a bit of an overreaction to this thread, the Game class has completely replaced it so keeping it around only hurts, we had the band-aid ripped off once, why put it back on just to do it again? Carson's proposal is looking to be the end goal solution to this problem, we can't just keep obsolete classes around forever and then yell at the Dev with a warning for using it
I understand Facepunch's position here, you are actively making things better and improving things, but the main issue is that you can never conclusively say there'll never be any API changes/backend functionality changes/breaking changes of any kind for the entire future of the engine.
Yeah it's very hard to tell where to draw the line and say "we're done". Because after that point if someone finds that something should be improved/changed or some new technology requires it then your options are left very limited when it comes to supporting games made before those changes.
I guess you could turn every feature of the engine into a library? Then you'd have versioning for modeldoc, shadergraph, actiongraph, hammer, whatever else.
This is basically the idea I was getting at with my proposal. Since base library has already been like this for a while (and that ships directly with your game) the base engine version could be structured quite similarly.
I don't see any reason why
GameManagershould exist at all. Is the plan to keep aroundGameManagerforever just because there are a few games that initially relied on it? or am I misunderstanding?
I agree that GameManager shouldn't have been hastily re-added. My point wasn't that GameManager should continue to exist. Because having both exist means that people with their own GameManager classes (that arent in a namespace) are now broken and there's a class lingering around that shouldn't have to. My point in mentioning the GameManager issue is that this could have been prevented if we had some form of engine versioning.
My take on this is that the engine is still in progress and things like this are expected to happen. Api changes will happen. If you are choosing to develop in a developer preview, you should at least have the thought that something could happen like losing your progress.
My take on this is that the engine is still in progress and things like this are expected to happen. Api changes will happen. If you are choosing to develop in a developer preview, you should at least have the thought that something could happen like losing your progress.
Then you are missing the point entirely. What people like @MD485 and I are trying to say is that even then it's no longer a developer preview and want to improve the engine, they will be encountering the same issues without some sort of engine versioning solution.
It is near-impossible to consider an engine "100% done/complete" if it has a 10+ year proposed development time.
(Yes obviously I know that things are expected to break in developer preview but this whole thread/issue was made to prevent it from happening when we are no longer in developer preview)
My take on this is that the engine is still in progress and things like this are expected to happen. Api changes will happen. If you are choosing to develop in a developer preview, you should at least have the thought that something could happen like losing your progress.
Then you are missing the point entirely. What people like @MD485 and I are trying to say is that even then it's no longer a developer preview and want to improve the engine, they will be encountering the same issues without some sort of engine versioning solution.
It is near-impossible to consider an engine "100% done/complete" if it has a 10+ year proposed development time.
(Yes obviously I know that things are expected to break in developer preview but this whole thread/issue was made to prevent it from happening when we are no longer in developer preview)
Sorry, I did. I agree with the proposed changes. I think its a very difficult problem to solve and needs some thinking to be solved correctly.
So long term, for standalone, there will be engine versioning. We appreciate the importance of that from Rust and Unity. How we distribute that needs looking at, but we'll do that at the time.
Versioning the engine for the "platform" games won't work as such.
Keeping GameManager in is fine. It's the way things are meant to work. It gets marked obsolete, when you update your game you get a bunch of warnings, you fix it, everything keeps working. We can use the backend to look through all games and see which are using which classes, and can remove it when nothing is. That's the lifecycle there, that's how it's meant to work.
At some point in the future we'll upload the code of your game to our backend and compile it there. What is likely to happen there is we'll keep a copy of the code bundle, and when we change something breaking we'll re-compile all of the games with those changes. This will be done with a bunch of auto-upgraders, so we can evolve the game API without breaking the code.
So long term, for standalone, there will be engine versioning. We appreciate the importance of that from Rust and Unity. How we distribute that needs looking at, but we'll do that at the time.
Versioning the engine for the "platform" games won't work as such.
Keeping GameManager in is fine. It's the way things are meant to work. It gets marked obsolete, when you update your game you get a bunch of warnings, you fix it, everything keeps working. We can use the backend to look through all games and see which are using which classes, and can remove it when nothing is. That's the lifecycle there, that's how it's meant to work.
At some point in the future we'll upload the code of your game to our backend and compile it there. What is likely to happen there is we'll keep a copy of the code bundle, and when we change something breaking we'll re-compile all of the games with those changes. This will be done with a bunch of auto-upgraders, so we can evolve the game API without breaking the code.
So if there's 500 games on asset.party and like 5 shitpost games or whatever use an obsolete class or method you won't remove it despite it just making the API unnecessarily conchfusing
So long term, for standalone, there will be engine versioning. We appreciate the importance of that from Rust and Unity. How we distribute that needs looking at, but we'll do that at the time.
Versioning the engine for the "platform" games won't work as such.
Keeping GameManager in is fine. It's the way things are meant to work. It gets marked obsolete, when you update your game you get a bunch of warnings, you fix it, everything keeps working. We can use the backend to look through all games and see which are using which classes, and can remove it when nothing is. That's the lifecycle there, that's how it's meant to work.
At some point in the future we'll upload the code of your game to our backend and compile it there. What is likely to happen there is we'll keep a copy of the code bundle, and when we change something breaking we'll re-compile all of the games with those changes. This will be done with a bunch of auto-upgraders, so we can evolve the game API without breaking the code.
Awesome, that sounds good.
