I can say, unequivocally, if you’re starting a new game project, do not use Unity. If you started a project 4 months ago, it’s worth switching to something else. Unity is quite simply not a company to be trusted.

It’s on developers to sort through these two types of costs, meaning Unity has added a bunch of admin work for us, while making it extremely costly for games like Vampire Survivor to sell their game at the price they do. Vampire Survivor’s edge was their price, now doing something like that is completely unfeasible. Imagine releasing a game for 99 cents under the personal plan, where Steam takes 30% off the top for their platform fee, and then unity takes 20 cents per install, and now you’re making a maximum of 46 cents on the dollar. As a developer who starts a game under the personal plan, because you’re not sure how well it’ll do, you’re punished, astoundingly so, for being a breakout success. Not to mention that sales will now be more costly for developers since Unity is not asking for a percentage, but a flat fee. If I reduce the price of my game, the price unity asks for doesn’t decrease.

  • @InfiniteLoop@lemm.ee
    link
    fedilink
    English
    121 year ago

    are unity and unreal so different that your 10 years of experience in one isn’t helpful for the other? i’m not a game developer but I had assumed it was similar to web frameworks - definitely high switching costs for porting an existing project, but as a developer looking for a job there are still many portable skills.

    i’d guess it also depends on what parts of the engine you are working in?

    • PonyOfWar
      link
      fedilink
      111 year ago

      To an extent I can apply my knowledge to other engines, sure. I’m working on my third Unreal project currently, and while it’s not like starting from scratch, I’m definitely way slower working with it. It also doesn’t replace Unity completely. It’s great for high-spec 3D stuff, but almost useless for mobile 3D/AR apps, which is a lot of what I do (not making games but mainly industrial interactive 3d applications).

        • @Piers@beehaw.org
          link
          fedilink
          English
          21 year ago

          I’m not so sure about that. Godot is fantastic for making the sorts of projects they are describing. But if the relatively minor difference between Unity and Unreal’s workflow are a turn off for them, then the consciously different workflow in Godot is probably going to be a significant barrier. Personally, whilst I love Godot because it’s FOSS and lightweight and a great platform for building smaller scale games: a big part of the appeal for me is that I find the Unreal and Unity ways of doing things stupid, confusing and clumsy and the Godot way clever, clear and elegant. I know lots of people feel the exact opposite.

      • @HerrLewakaas@feddit.de
        link
        fedilink
        41 year ago

        Hey same here, although I’m just getting started in the industry. I’ll look into Unreal soon I guess, been wanting to do that for a while anyways, and maybe also experiment with godot

        • @Piers@beehaw.org
          link
          fedilink
          English
          21 year ago

          Unreal is good if you want to work on big expensive projects at big companies. Godot is good if you want to work on your own projects today and potentially but not definitly work on small to middle-sized projects at small to middle-sized at small to middle-sized companies in the future. Unity is fine if you want to work on small to middle-sized projects at small to middle-sized companies now and potentially in the future.

          Which sucks. There ought to be a clear and unambiguous path to chose for someone moving into game development today but since Unity keeps making weird choices that are hostile to developers whilst not continuing to improve at a good pace, it’s hard to say for sure which engine will fill in the not-Unreal Engine part of the market unless you have a crystal ball.

          Realistically the best thing is to have as strong a foundation in programming generally as you can so that switching engines is minimally disruptive (as there will always be a need to do so eventually. There’s very little chance one single engine will continue to be the standard over the 40+ years of a career.)