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.

    • NuXCOM_90Percent@lemmy.zip
      link
      fedilink
      arrow-up
      0
      ·
      6 months ago

      Version Control System

      At this point: That should be a synonym for “git” unless you REALLY have a good reason not to.

        • NuXCOM_90Percent@lemmy.zip
          link
          fedilink
          arrow-up
          0
          ·
          6 months ago

          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.

        • SurvivalMariner@lemm.ee
          link
          fedilink
          arrow-up
          0
          ·
          6 months ago

          Even legacy codebases get migrated easy. SVN etc. belongs in a museum. Best red flag for dead end dev job.

  • AlexisFR@jlai.lu
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    6 months ago

    That’s pretty telling of the state of the industry nowadays.

    How did this game even got discovered?

  • Mikina@programming.devOP
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    I love this so much :D That reads like something I’d expect from ZA/UM, but it also thankfully alleviates most of the major issues I had with the game, which I’ve already talked about here on Lemmy. I really liked the game, but there was a lot of red flags point to it being just a quick corporate cash grab, where they decided to basically re-skin heir previous game based on with as low effort as possible, to quickly sell it and cash in on the Pokemon thing. It just smelled with corporate greed, and that they did not really cared about the game too much.

    But assuming this screenshot is true, I’d say that it’s clear that it wasn’t development driven and pushed by corporate greed, but really just a few of guys trying their best.

    • ReallyKinda@kbin.social
      link
      fedilink
      arrow-up
      0
      ·
      6 months ago

      As a craftopia player palworld definitely feels like a bit of a reskin, but one that gives players a lot of what they wanted (mainly being able to explore freely in multiplayer mode which is severely limited in craftopia).

      One element palworld leaves out is being able to create your own automated processes (like automating a farm with a series of conveyer belts, chests, and various machines). They say they’re still planning to develop craftopia so I am pretty excited to get the elegance of the pal world pets (which craftopia had too, but not as shiny) and the fun of automating your own homestead instead of setting up prefab stations.

  • mozz@mbin.grits.dev
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    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.

      • mozz@mbin.grits.dev
        link
        fedilink
        arrow-up
        0
        ·
        6 months ago

        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.

  • DarkGamer@kbin.social
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    Madness, if you ever have multiple devs touching the same files, this will lead to nightmare scenarios integrating code.

    • NuXCOM_90Percent@lemmy.zip
      link
      fedilink
      arrow-up
      0
      ·
      6 months ago

      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”.

      • Tamo240@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        6 months ago

        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.

        • NuXCOM_90Percent@lemmy.zip
          link
          fedilink
          arrow-up
          0
          ·
          6 months ago

          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.

          • fruitycoder@sh.itjust.works
            link
            fedilink
            arrow-up
            0
            ·
            6 months ago

            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?

            • NuXCOM_90Percent@lemmy.zip
              link
              fedilink
              arrow-up
              0
              ·
              6 months ago

              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”

              • FrostyCaveman@lemm.ee
                link
                fedilink
                arrow-up
                0
                ·
                edit-2
                6 months ago

                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!

                • NuXCOM_90Percent@lemmy.zip
                  link
                  fedilink
                  arrow-up
                  0
                  ·
                  6 months ago

                  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.

          • Mikina@programming.devOP
            link
            fedilink
            arrow-up
            0
            ·
            6 months ago

            I had no idea git-bisect exists, and we’ve been doing binary search for broken stuff by hand every time. Thank you for this mention!

            We’re just in the middle of investigation a performance issue, and this will definitely make it a lot easier.

    • asyncrosaurus@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      6 months ago

      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.