Is anyone seriously surprised? What Unity did was tantamount to business suicide, but these things move slowly. Expect to see more and more out of Godot in the coming months, as projects that were nascent when Unity tried their greedy power play will finally start to get teased.
Having tinkered with Godot and Unity, I can honestly say I like Godot better.
Their documentation is miles ahead of Unity's and actually makes an effort to explain how things work. It's not perfect, but a lot of the frustrations I had with Unity came from it being a total black box which just isn't an issue with Godot.
The editor also doesn't take forever and a day to install or start up.
I had so many issues with documentation in Unity just not being up to date at all, and me trying to find answers on the Unity sub reddits were met with "are you too fucking stupid to google" and then link me to the documentation I just said didn't work. Godot's documentation is just in the engine and I don't have to search for it, and it's almost always either up to date or close enough that a quick Google solves the issue.
I've found that Godot's community was much more forgiving and much more receptive. It did take a bit of a hit when the Unity users came over and started acting like snobs and entitled that Godot NEEDS to make changes because Unity does something a certain way.
Even on slow internet, you can download and make.a new project in godot in the time it takes to open a project in Unity.
Games take 3 to 5 years to develop and switching engines during development is a very poor decision. In two years you will see how many companies have moved on.
No surprises here really. The creators of dwarf fortress are incredibly passionate about their game. It just happened to become successful. The AAA game industry is the exact opposite.
They basically made it while living in poverty because they refused to charge for it for the first 10 years. I donated for a few years and got drawings for my money. Great game and great people.
I think the lesson is not that bucket-o-flash-drives is a better way; I think the lesson is that you can make a not-ideal process work completely fine if you just keep focused on the main point. People made successful software way before version control existed. It just makes it easier but that's all it does.
Linux was written up to about version 2.2 or 2.4 or thereabouts with no version control, just diff and patch and email. They invented git because at a certain point they wanted automated tools to make easier and more automated their way of working (which none of the suitable VCSs of the time were capable of), but it wasn't like they couldn't do the job until the tools existed.
Yes. The little word "suitable" was doing a lot of work in my explanation, it's true. BK was invented by a kernel developer for pretty much exactly the reasons I explained; I just glossed over the part of the route that went diff+patch -> BK -> git as a detour. I was actually a lurker on the linux-kernel mailing list while all this was going on and saw the fireworks in real time.
It's not exactly accurate to say BK withdrew support. Larry McVoy was such a pain in the ass about wanting to control how people used his product that the kernel developers felt the need to write their whole own solution as opposed to continue putting up with him. (Specifically, his pulling Andrew Tridgell's license for dubious reasons was the straw that broke the camel's back.) RMS actually wrote a sarcastic open letter thanking McVoy for providing a good lesson in why it's a bad idea to let your important stuff be dependent on proprietary software.
But the point remains; BK was invented by a member of the kernel community specifically because none of the existing solutions were usable for them, after more than 10 years of one of the biggest and most-distributed software projects in the world having no source control whatsoever.
Project zomboid had to start again after flat got burgled and laptop gone. Offsite backups are key for theft and fire. Version control is the easiest and cheapest way.
Someone always knows someone that drinks, smokes and eats crap and lives until mid 90s. Doesn't mean it's good health advice.
I've never played the original. I have so many free/cheap games through epic/humble/prime etc I can't ever decide what to start. So I don't start anything. But I'm considering it as well.
I don't even like card games, but Slay the Spire is great. Easy to learn, quick to play... and then all of sudden it's the only thing you've played all week.
Unfortunately we all know what happens when you tell hackers that something's going to be very hard to break into.
I understand that they were excited about the idea and wanted to share it with gamers, but if they actually wanted to give the system the best chance of success, they should've kept their mouth shut.
It was a really interesting food for though, especially since both cybersecurity and game development are my main areas of focus (I work part time in offensive security, and part time as game dev). I has actually motivated me to start considering that I might give data-mining this game a try, because I'm really interested in how he wants to solve the many issues present.
I'm betting it would probably be mostly leaning into "security by obscurity", but if that's the case, throwing a gauntlet like this wasn't a good idea. Because every technically sound solution I came up with was a nightmare from game design standpoint, and I couldn't came up with any puzzles or secrets that wouldn't be extremely complex, mostly because you just require a really large problem and input space for it to not be brute-forcable at any of the reverse-engineerable stages.
Also, I have a soft spot for clever marketing tactics, and this one is amazing.
I was always aiming towards just being a gamedev, but since there weren't many Bachelors degrees at the time focused on that, I went for Software Engineering, and then Masters in gamedev. However, experience working for alongside school in QA for a bigger gamedev company has kind of made me realize that corporate and AAA gamedev isn't really art, and you're basically the same code-monkey as you would be anywhere else, just for a lot less money. And since at the time I just played Watch Dogs 2 and was running a Shadowrun campaign, I was pretty into hacking at the time, solving CTFs and generally researching into it, which was prompted by one optional class on pentesting.
So I decided that since working in gamedev will probably leave me burnt out and with lot less money, I just applied for part-time cybersecurity job so I could finance my hobby gamedev career that's not limited by the fact that it's my livelyhood and I have to make money - and that makes every kind of art so much better. I still went for Masters in Gamedev, though. And after several years, the cybersec company started to turn more and more corporate, and I was offered a job at a small indie studio made of mostly friends, so I switched from full to part-time, and took another part-time for a lot less money but with an amazing work environment.
Besides that, Red Teaming is basically just LARPing Shadowrun, it sounded like the perfect job, just trying to talk and hack you way into banks and corporations, I couldn't say no to that :D
We moved from GitHub to Gitlab and the rate at which new contributors found the project effectively halved. We had a Matrix at some point and one person used it. The reality is you have to pick your battles.
That's fine and I understand; and I'm cool if projects have multiple ways to make contributions. What I hate is when open source projects only exist and allow communications on closed platforms.
We also have forum.2009scape.org, which is open source. Any questions people have are only answered here, for the explicit purpose of better searchability of answers.
(But people hate registering on new sites)
Trust me, I know what you're saying. We did our best, but ended up deciding to focus on the project, rather than a larger movement as a whole
Gamers 😤 For what it's worth, more users, especially on a gaming-related project probably the effort providing basic support faster than it increases contributions.
The network effect is a real problem tho. Hopefully ForgeFed & Gitlab implementing ActivityPub will help with this. Same with OAuth with GitHub as the SSO provider.
Bridging Matrix seems like the best of both, but takes a lot more work.
I'm a purist, so if I see a project uses Discord, I'll immediately start looking for viable alternatives.
We do, but people don't come over. It's a service issue; if the goal is maximize contributors, you need to minimize friction. A mirror minimizes friction, but it's still a significant step over "just being on Github":
That's a shame. If GitHub didn't have their own pull request system (or at least did it the way git does) I would have suggested maybe finding a way to allow PRs from GitHub.
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 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.
I don't mean to be passive-aggressive, animations are really hard (especially to produce on game-wide scale alone), but I love those in-sync doggos, choreographed tails like they are about to start a (good-)boy band.
They look like they're about to start snapping their fingers menacingly at 0:46.
While we're talking about it, at 0:16 on the first video it kinda looks like the PC just sticks their hand in between the wolf's jaws, before punching it with their other hand. Got a chuckle from me.
I have not heard "snapping their fingers menacingly" since I heard a description of West Side Story. Pleased to come across it again, this is going to make me actually check out the trailer now
I actually surprised that when I went looking for a clip to share along with that comment, I couldn't actually find any clip of them walking directly at the camera doing it like it happens in my head. (I've never actually watched it either on stage or film, but I guess I know it through cultural osmosis.)
As someone who inevitably gets thrown into the "devops" side and the like:
The vast majority of developers can't integrate code or even resolve a merge conflict (and god help you if someone convinced the team to do rebasing instead...). They just stop working and then whine three weeks later during a standup that progress is halted on their deliverables. And, because of the stupidity of "devops" as a job role, there is an increasing culture that development should not have to worry about this kind of stuff.
So good project management becomes splitting up files to minimize the chance for conflicts and spreading tasks out to minimize the times people will be in the same file, let alone function. And if they do? Then you do whatever the latest buzz word is for "peer programming".
I will never understand the idea that rebasing inherently causes problems. Rebasing gives a much cleaner history and reduces the number or commits with multiple parents, making it approximate a simple tree rather than a more complex graph.
The simple rule is branches that only you work on can be rebased, shared branches must be merged.
I've never understood the complaints about rebasing. Just make sure you merge if it is complicated
Jokes aside: It honestly isn't THAT much worse. But if you don't "understand" git, you can fuck up your history and it is a real mess to recover from a "failed but technically not" rebase. Whereas merges just result in a shitfest of a history but everything gets reconciled.
Although, a bit of a rant: I do still think rebasing is fundamentally "bad" for long term debugging. As a simple example, let's say that you changed a function signature on branch A and merged it in. Branch B uses that function and started before A. After a rebase, there is no indication that those previous commits would not have worked or were counting on a different signature.
Generally speaking, you can avoid this so long as you always add a merge commit to go with the pull requests (or futz around a bit to identify the known good commits). You assume that those are the only valid commits and move from there. But when you are debugging a bug that silently got added two years ago and think you are clever because you know how git bisect works? You suddenly have a lot of commits that used to work but don't anymore.
It doesn't come up often (especially since so many workflows these days are "throw out the old code and redo it, but right this time") but you only need to run into that mess once or twice to no longer care about how clean your history is.
This feels like a problem I just had a complex enough code base to worry about. I like rebasing because it feels more like I am committing when I intended, but if the deltas were too great it would be a huge issue.
The small more frequent changes not solve this too?
If your project/code base suits itself well to being nothing but small feature branches, sure.
But reality is that you are going to have the "long living feature" branches where it doesn't really make sense to merge any of the code in until "it all works"
The “long lived feature branch” approach is kind of the entire problem that leads to merge hell though. Having long lived branches is at odds with the rebase centric style and that’s intentional. Rebasing incentivises keeping branches small and getting stuff into main as often as possible. Basically it’s about using git in a “trunk” style.
The next question is “what if I don’t want this code to go live yet” to which the usual answer is “feature toggles”
People get very dogmatic about this stuff haha. I’ve worked in teams that were very hype about using rebasing and teams that could easily handle long lived feature branches. The difference is the latter kind of team weren’t all trying to edit the same files at the same time. Hmm. So yeah I guess what works best is situational!
EDIT: I just realised this is a gamedev community whereas the above comment is based on my experience in the “enterprise business factory” dev world. Might be a bit different over here, not sure!
Pure ideologies work until you have tight deliverables. And "feature toggles" become problematic if you need to do a "release" and don't want to have undocumented (possibly unfinished) functionality that is one malformed configuration file away.
At the end of the day, it is about balancing "clean" development with acknowledging thjat you are going to need to cut corners. Generally speaking, "open source" projects can get away with a strong focus on ideology because they don't have deliverables that can mean the difference between being rockstars and being this week's tech layoffs.
Our last major college project that spanned multiple semesters was worked on by 5 devs all editing the same source files over Dropbox. The school had servers for svn, but no one knew how to do source control. It was exactly the type of shitshow you would expect.
I'm an open source maintainer part-time. My God how I've wanted to call so many people "idiot" straight to their face.
I don't blame some people for turning bitter. You wouldn't have much faith in humanity left either, after closing your 100th duplicate issue with a solution that sums up to "read the fucking docs".
I was talking to a friend recently who was frustrated because they felt like tech support had been treating them like an idiot. They're a reasonably techy person and had gone through all the troubleshooting steps in the documentation, but the person on the phone had them do it all again. I tried to explain the perspective of the tech support guy — the fact that people often refuse to restart their PC because it feels like too simple of a step and they feel patronised by the suggestion, to the extent that people lie about whether they've done a particular troubleshooting step.
I told them that it was valid to feel frustrated with how long the call took when it could've been much quicker and simpler, but that they should attribute their frustration at people who repeatedly refuse to read the docs, rather than the tech support guy. My friend wasn't an idiot, but they were tarred with the same brush because of how many people seeking tech support are belligerent idiots.
I think that yes, the execs are greedy, but there are also two other problems:
Shareholders are also greedy, arguably even more greedy than company employees (executives are employees).
Developers have been overhiring, which is generally a symptom of someone not knowing what they are doing thinking that hiring more people makes things faster/better when actually the opposite is the case.
Out of touch, greedy executives that dont know what theyre doing, trying to meet unreasonable demands of shareholders? Yeah, perfect storm material.
Yes, thats part if what I was talking about. The shareholders have unreasonable and unrealistic demands. Companies cannot infinitely have increasing profits year over year, but that is what shareholders demand. So the execs try to achieve those unreasonable demands, which results in overhiring because of course if more people work in a game then obviously the games will be done faster and better resulting in more profit, according to their thinking.
Im just saying that while executives are being greedy, they are only one cog in the machine.
Don't forget that executive compensation is often significantly comprised of stock or stock options. By feeding the shareholders, they're feeding themselves.
It's important to understand that this is not just individual greed. The problem is that greed is ingrained into the system. Capitalism simply does not function without greed.
The only reason shareholders will move their capital is if the company is expected to grow. What is the point in risking your money if there is no profit? This search for infinite growth is what leads to the death of products. It creates different objectives and incentives than simply making a good product that users will pay for and providing a steady job for employees. A situation where the company does not grow but continues to make a good product and pay its workers a decent wage is an acceptable one for everyone except for shareholders.
Executives are just the middle layer between investors and workers. They make sure that investors get their return on investment, since investors don't really give a shit about the product or even how it operates, they just care about the numbers on the balance sheet. And as someone noted in another comment, they are paid mostly in company stock so that the interests of shareholders become partially their own.
I think COVID is partially to blame here too. Specifically with the over hiring. A lot of companies took on too many people with the influx of cash caused by everyone staying home and playing games and when the market went back to level and everyone went back to work companies were left holding the bag for a bunch of employees that they realistically couldn't support and probably shouldn't have hired.
execs often hold good amounts of shares though, not sure what the point you're trying to make is. It's often in their benefit to make short-term decisions that make the stock price go up in a span of 1-2 years, then they can cash out and do the same somewhere else.
Considering execs usually are fired for ignoring shareholder demands, I would say regardless of how many shares execs have in a company, attempting to meet shareholder demands is always in their favor. This is irrelevant to the point I was making.
Game Development
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.