I'm a DevOps person by trade, and I have been playing a lot of Palworld. This is my worst nightmare and I have no idea how any team bigger than one person could have done anything without basic source control. Guess it just goes to show that nobody cares about the details as long as you ship.
My realisation long ago is that the games industry just doesn't work like the rest of the software engineering industry. The most cowboy engineer you've ever worked with is a voice of reason in the game dev industry.
Yeah, I have a colleague or two who have worked in that space. You could not pay me enough to work with their tools, conditions, and practices. Guess I'm in the wrong sub for that opinion, but I'm just a wanderer stopping by.
It turned out it's not true, they did use VCS. However, they mention a pretty horrifying story about VCS nonetheless.
They were a team without prior or professional gamedev experience, and they were using git. The first senior engineer, and first member of the team who actually was a professional game developer, was someone who ranomly contacted them due to liking Craftopia. But he didn't have experience with Unity, only Unreal, so they just said mid-development "Ok, we'll just throw away all we have so far, and we'll switch to Unreal - if you're willing to be a lead engineer, and will teach us Unreal from scratch as we go."
And then, they also mention this:
Surprisingly, [the new engineer] had no experience using the version control system git.
According to him, Perforce seems to be a better match for Unreal Engine.
But Perforce is too expensive. This is not the amount that a company like us would pay.
If you can't use Perforce, you should at least use svn instead of git.
Fully trusting his words, I also migrated my version control system from git to svn.
On the other hand, now that I think about it, SVN may actually be better for Unity projects than git is, at least in some areas.
One major issue with Unity and VCS are the scene and asset files. Trying to mere scene changes when multiple people have worked on the same scene is hell, to the point where it's usually better to just choose one changset and manually re-do the other. I know there is a unity merge tool for that, but since you have no idea what exactly it did, it's been pretty hit or miss.
SVN could solve that issue, since you can just lock files.
However, that still doesn't outweights the benefits of virtually every other feature of VCSes.
It's such a shame that Unity are greedy bastards that tend to buy out and heavily paywall amazing projects. I've worked with Plastic on one project, and it's amazing. I've really enjoyed the workflow, and the way the merging works is awesome. But then, Unity came and now it's unaffordable for anyone but larger teams.
Same with Parsec. Parsec has been an amazing alternative for Steam Remote, that had open source SDK and libraries to integrate directly into games. It was a perfect alternative for smaller teams that can't make proper multiplayer. And once Unity bought them, they've removed access to SDK only for companies that directly ask for it - which we (being a small student project done on our free time, that really could use MP since it's two player only local coop game) have done, mentioning that we're really just students and hobbyist.
They response? They basically said "Sure, we can give you access to the SDK, no problem. The first step is to pay us 1 000 000$ for it.". How can anyone be so out of touch?
I got stuck organizing the migration at multiple companies. Believe me, I know how many people still use SVN (and CVS...)
And, in some cases, that is your "good reason not to" because of the disruption to development and needing to retrain devs. But it is also a migration that is well worth doing, if only because of how good Gitlab is.
I prefer Plastic way more than Perforce, from a brief experience I had with it on one project. Too bad it's been a victim of the Unity's "buy it, paywall it" strategy, where getting a license is mostly unaffordable for smaller team.
Yeah, I forgot to mention in my original post that ECS was extensively described and already in use by many private commercial engines (like Overwatch) at the time when the patent came out. Absolutely ridiculous patent that shows why the whole system is broken.
They did that to Parsec. Their SDK was once an openly accessible and amazing alternative for Steam Remote, which (In my experience) worked better and was easy to integrate into Unity.
Then Unity bought them, closed-sourced, and if you want access to the SDK, you have to ask for it and they have to approve it.
We tried that three years ago, mentioning that we're just a team of students working in school on a two-player only coop project that could really use a multiplayer we can't implement.
This is their response, and I'm still salty about it to this day:
Thanks for reaching out about Parsec! You mentioned in your comments that you were interested in SDK. SDK starts out at $1million. I think upgrading to our Teams plan might assist with the lag issues you're experiencing with your team.
Our Teams subscription starts art $35 per user.
Please let me know if you have any further questions you have.
This is the point of patents. Privatize technology that would benefit all and then ask rent from people using it. Then make money without doing shit, except for the odd enforcement (through lawsuits). Just feudalism updated to the modern age.
Wouldn't this, along with the other numerous talks on ECS that were made before Unity copyrighted it, be enough to challenge the copyright and have it revoked? Or is that not how copyright works?
The patent wouldn't be for any ECS; it would have to be for a specific implementation. The post may match the implementation, and invalidate the patent, but just being an ECS wouldn't be enough.
I was a Unity user for a long time, I watched them fumble after fumble, then merge with Iron Source, deprecated features with promises of the future, canceled plans, mire promises, pulling the rug out from under people, etc
I will never use a non FOSS game development ecosystem anymore. We should all force the industry to adopt this.
The point in the article isn't bad, but what he is forgetting is whatever version of Unity his engine depends on, will always be available. It's not actively being worked on really, unless you intended to update to a later release but most don't need to. Doesn't matter if Unity goes down, they will always have a product, they'll just get smaller and privatize which isn't a bad thing.
Unity made a gazillion dollars and wasted it all on acquisitions it had no business managing. They poofed a billion easy on those and people got extremely profitable payoffs and retirement plans. All this while they play is for fools.
As a Unity employee who was recently let go I know it's still a total shitshow, and we're all better off cutting our losses and not planning improvements on the Unity version of our games. At least Unreal isn't bleeding money and backtracking on a bad business model.
True, except that you need to be able to compile for the latest SDK, etc. Google and Apple now require that your app is compiled against the current or immediately previous SDK, and will actually hide your app on the store if it isn't now. Perfectly good games just disappear from the listings for some BS reason.
And the old version of your game engine often won't compile against newer SDKs, especially if it's more than a couple years old.
I experienced something similar with my game that I made using Unity and the Chromecast plugin for it. Google stopped updating the plugin, and the new Unity didn't work with the old plugin, and for some reason I needed to use a newer Unity version. (It's been a while and my memory is hazy on it now.) I could not compile my game for modern devices anymore. Luckily, it wasn't even a game I had published, so I didn't screw over any users with that, except my own family.
I'm a senior non-game developer, playing at game development in my spare time. I used to use Unity, but I've quit them a few times, and I think this time is for good. UE4/5 didn't really fit my work flow or design style.
So I'm playing with Godot now, and I'm pretty impressed. Some things like 3d imports and animations could use some love, I think... But otherwise, I'm pretty happy with it.
Professionally in Unreal 5. Hate it with a passion. Not only is the engine a shared state leaking piece of s*it but the language(s) that come with it make the whole mess even worse.
In my free time I worked with Bevy which is really promising in my opinion. I hope their editor will be as amazing as the rest of the framework.
Recently I also tried Fyrox. It is nice, probably usable for some smaller things, but damn it feels a lot like Unreal again with going a OO-like paradigm. Of course little to no memory-safety issues it being developed in Rust as well (+ a runtime borrow checker they implemented on top to check on shared writes to Resources, Nodes, etc.), but compared to ECS it feels terribly clunky.
ECS just feel sooo right!
Also, if someone needs a more mature engine than Bevy, don't go for Unity or Unreal - Take a look at Godot. It's FOSS and even supports Rust bindings (and I do think Rust the shit and will be a big deal in the future).
The game was crashing. Not a lot, but about once a day the game would randomly just explode. No particular rhyme or reason to the stack trace or what was going on at the time. Just, boom!
We obviously can't ship that way. It was getting kinda late in the development cycle, enough that this made everyone nervous, and I was tasked with tracking the thing down. They said we hope you find it fast, but fast or slow, you have to find it because we don't really have a choice.
I spent about a week trying to see if it was related to any particular thing. I started disabling subsystems to track it down. No audio, wireframe graphics, simple test level, remove all equipment or controllers we don't need. Nope. At this stage you start having those tense conversations like "Maybe we don't NEED level 6.3" when fiddly bugs start to show up, but it was irrelevant, because nothing we could remove would solve it. I made some level of attempt to run back in the source control to see if I could binary-search to where it first showed up, but the game crashing isn't exactly unheard of and it was fiddly to even reproduce the thing in the first place. That was what made it so insanely slow to track down. No luck from any of this.
After several days, I understood that I wasn't in for a typical debugging session. What I decided on was to embark on making a build of the game that was byte-for-byte identical from run to run. No audio, no control input, constant RNG seed, track down anything that might make it deviate or anything time- or IO-dependent. That took about another week, but at the end, I had my build. Every byte of memory was the exact same from run to run; every address, every value. (This was a console game so this task was easier than it otherwise would have been.)
So we're two weeks in now. By dumb luck, I managed to replicate the bug almost immediately once I had the repeatable build. The morbidly simple level and setup that reproduced it quickly was: Start the repeatable build with a script running that would spawn the player in a bare room with a floating gun. The gun fires, killing the player. The player drops to the ground, and then the game crashes. Every time.
I got you now, you son of a bitch. Happy that the thing was trapped now, unable to flee into its stochastic wilderness, I began to live in an endless world of execution-style slayings.
What followed was actually the longest part. As I said, the crash had no real pattern, but I now had the ability to go backwards in time. I could control everything. I took any wrong-looking values from the memory at the time of the crash, and started setting watchpoints on their memory addresses. How had it gotten this way? What touched this piece of memory? The process of single-stepping through, as a single piece of memory was allocated, used, freed, and then reallocated, trying to understand it all and find the wrong bit, was intense.
My memory of the following couple of weeks is honestly a little fuzzy. I know I was able to track down, by single-stepping through every single place the offending memory value was touched, to definitively work out what value it was that had had an impossible value, how it had caused the crash, and every single place that value had been touched, until I arrived at the offending code. The problem was... the bug wasn't in the code I was looking at. It had had some weird impossible value in some of its data that had caused it to set up something else wrong.
Oh. Oh no. Do I have to do it again? By now I was three or four weeks in.
I did do it again. Like I say I don't remember clearly, but I remember that it took me about 6 weeks in total and I filled up the majority of one little notebook that I kept next to the computer to write notes in. Little hex addresses, stack traces, clues that I might need to flip back to later. No matter. After tracing back all the breakage, I finally arrived at the code that was actually causing it. Once I actually saw what was happening, it was easy to work out.
At some point, someone had added a cache for some expensive-to-compute data for actors in the world. The cache had a mapping of actors to cached-value matrices, and each actor had a single value that was a pointer to its cached value, or NULL if it had none. I think they were too big to store indefinitely? There was a little LRU cache. But, if an actor was destroyed, it wasn't removed from the cache. So its cached data would sit there in the LRU cache, like a little time bomb, until the thing expired, and then the last part of its removal from the cache would be... unsetting the pointer to cached data in the now-dead actor back to NULL. The actor's memory had already been freed, and so one int, somewhere at some random location in memory, would get set to 0. And once in a while, it would happen to be at a location where that would cause serious problems (usually leading quickly to a crash).
Hm... not sure it would have. Something simple like overwriting freed memory with an identifiable pattern wouldn't have helped, because by the time the crash happened, the actor's memory had been reallocated and was being used for something else.
This was on the Wii, which had some pretty bare-bones development tools, so it wouldn't have been real easy to try to use something like valgrind to do more sophisticated memory debugging or anything. It was basically single-threaded, too, BTW (I think audio and input were based on interrupt handlers), and I made it more so with the repeatable build.
Yeah. I was proud of myself. 😃 IDK how easy it is now with all these friendly toolkits, but back at that time and definitely for console development, there wasn't a lot of way around really knowing your shit. Even having a degree, it definitely helped, but even that wasn't really a full preparation for some of the difficult stuff I ran into. I wish CS prepared people better for real-world engineering; in particular I wish reading big codebases was more of the curriculum. I actually came out of school still with fairly bad working-with-production-code abilities.
Separate related story, I was disagreeing with my boss about whether to hire some guy. My boss said, but his code is really bad. I said, yeah but he's right out of school so it's to be expected. When I first graduated my code was really bad. My boss got sort of distant for a second while he was remembering, and then his face came alert again and he said, all animated, "Yeah! It was. It was terrible!" I said yeah, I know, then I learned what I was doing and it was better. It's just sort of how it works.
Game Development
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.