UPDATE: So, apparently it’s mostly fake, taken from this article [translation] (where they even mention some kind of VCS).
However, even though it’s not as absurd, it’s a great read and a pretty wholesome story, so I recommend reading the article instead. And I’m even more convinced that this studio really does not deserve any of the hate they are getting.
Here is my summary of some of the interesting points from the article:
PocketPair started as a three man studio, passionate about game development, that couldn’t find an investor for their previous games even though they’ve had really fleshed out prototypes, to the point where they just said “Game business sucks, we’ll make it and release it on our own terms”, and started working on games without any investor.
They couldn’t hire professionals due to budget constraints. The guy responsible for the animations was a random 20-yo guy they found on Twitter, where he was posting his gun reload animations he self-learned to do and was doing for fun, while working as a store clerk few cities over.
They had no prior game development experience, and 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.”
They had no budget. They literally said "Figuring out budget is too much additional work, and we want to focus on our game. Our budget plan is “as long as our account isn’t zero, and if it reaches zero, we can always just borrow more money, so we don’t need a budget”.
For major part of the development, they had no idea you can rig models and share animations between them, and were doing everything manually for each of the model, until someone new came to the team and said “Hey, you know there’s an easier way??”
It’s a miracle this game even exists as it is, and the developer team sound like someone really passionate about what they are doing, even against all the odds.
This game is definitely not some kind of cheap cash-grab, trying to milk money by copying someone else’s IP, and they really don’t deserve all the hate they are receiving for it.
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”
