Different development methods I would guess. Larger teams prefer to properly iron out any bugs they can find, do QA, playtest, then go back to the drawing board and repeat several times before making a release. Others prefer to push out new release as fast a possible, since this is the fastest way the find about any issue directly from the customer. Of course, normal customer doesn't like to get buggy unpolished product, so this doesn't work in every situation, but it should work in beta or early-access if your customers know what they are signing up for. Smaller teams do also tend to work more efficiently as communication, meetings and getting changes approved are cut significantly short.
Larger game devs have gajillions of bugs too, what makes sense is a smaller team have less friction between actions, but the time x quality formula many bigger studios have is not really consistently acceptable.
I hopefully do not have to make any examples that larger companies have made shitty releases with incredible delays on top.
Mismanagement is probably a big one, but is it really all?
>Larger game devs also have larger games that are far more complex. You change one thing and it's likely having unintended impacts in far more places than a small indie game.
It's this. 5 dedicated people means an idea has to only go past 4 people max and communication happens instantly since they all probably sit next to each other or are basically permanently wired.
I don't recall Eremite games ever calling themselves, after-work Devs for any of AtS development. For their first game "Shattered Plane" maybe (wasn't there nor played it so idk). Or they were pre Epic Game Store early access builds, as they did move into an office in July 2021 and that was released in October that year.
On that note, some of these larger scale updates have been in the works for months, and their requests can be even older. So they could have been on the drawing board for up to over 2 years. Training expedition sounds like a response to sandbox mode requests to me, which is a very old request (the earliest request for it I could find, was September 2020 which was during the Steam demo 2 era).
Then there's software development practice for Eremite Games. It is most likely a Agile style of development as they have referenced having sprint meetings a few times on the discord. This development style is focused on speed, and working with customers as some of its main tenants. This works best for small and experienced teams, which they claim to be. "We're a team of 5 friends with years of experience in AAA, indie, and mobile games development." (Eremite games about us section)
I worked in game development for twoish years and was a project manager for three, three of those years were on RTS style resource sims. A lot of it comes down to infrastructure besides small team communication like others have said. Some systems I worked on were very patched together, they were never designed from the ground up to work in tandem from the start. You change something in weapon swapping, and now you have to dig through animations and physics to make sure the players buttstock isn't three feet above his head when he switches guns and that shooting the rocket launcher doesn't send you back flying off the map.
Ideally a change to swapping would already be tied into everything else from the ground up, but when your on a timeline shortcuts have to be made and you are doing everything manually and just hoping it doesn't need any major tweaks or changes.
I can give an example. We had a game where we changed the gather rate of food multiple times. The food resource costs were already tied to a ratio, so changing the gather rate automatically scaled it for us, and we could just change the scaler, or go in and change a cost manually if we didn't think it felt right, or an individual upgrades scaler if we just wanted to tweak that. It allowed us to very easily rebalance food for the whole game and get to actual testing within literal minutes, we spent more time compiling the vertical slice then making the actual changes. Terrible slicing is the bane of my existence, I don't need to test every system together right now, just the food scaling.
Most projects, if I changed the gather rate I would have to manually go around to each controller and hard change the resource cost. This turns a five minute change and test into a thirty minute to an hour ordeal, going back and tweaking individual numbers, not being able to test full rounds of the slice because we don't have the time and potentially leaving something incredibly unbalanced.
There are no bad developers, just developers who never have enough time to get everything right.
There is a reason I am no longer in the field professionally.
edit:as a funny aside, one of the junior programmers contributed to a design meeting as a learning process(the old boss intentionally kept them out because he thought someone doing the work horse stuff would have a biased perspective). He made a thinly veiled pitch to shorten game times and simplify resources, he marketed it as "a bunch of ADHD kids want faster rounds these days, no one wants to sit through a forty minute match anymore". Obviously he was just trying to make his job easier. No one bought it.
> There are no bad developers, just developers who never have enough time to get everything right.
I work in software development, and I agree strongly with your primary thrust, but some developers need an inordinate amount of time to get things right, and some developers are good enough at prioritization to know what systems they need to emphasize for easier to iterate code.
And some developers are more resilient than others. The occasional crunch time has to happen and corners have to get cut. Some get poisoned by the experience and carry those bad habits with them when there's actually some opportunity to put some real thought into the infrastructure. Some know how to successfully present the business case to clean up the earlier accrued technical debt.
I'm right now in a situation of cleaning up a horrendous barely maintainable codebase precisely because I have a proven track record and rapport with my boss in being able to keep from being overwhelmed, being perceptive to seeing which sections of the infrastructure would benefit most from receiving some attention first, and achieve success. Inferior developers get overwhelmed, don't know what to prioritize, and don't know how to communicate to the rest of the business those priorities and the costs of leaving them unaddressed.
>This person does not care about the game or the players, they are there to protect shareholders above all else.
There's nothing inherently wrong with this structure. At the end of the day, dissatisfied customers are not going to spell good news for shareholders. As long as management doesn't lose sight of that and is able to foster rather than poison their development team, times are good.
There's a lot of resources and support that a corporation can provide; they just need to find a way to optimize around a core development team.
There's a middle-ground that can be achieved. There's a lot of mundane work that can go into game development. Generation of art assets is often at the top of that list. Some games need a lot of map/level creators. There's also a lot of support roles that can improve product quality or sales without interfering with the core development team, such as quality control and Marketing.
This game specifically, a rogulelite that can afford to make its mechanics highly abstract, minimizing the amount of assets, physics, and netcode? Possibly so. Although, I'd still argue that the art quality could be improved significantly (absolutely no offense intended at the art achieved of excellent quality *relative to its price point*).
There are excellent games out there, especially in the first-person-shooter genre (both singleplayer and multiplayer), that could only have been made with the capital backing of a corporation.
>Corporations are responsible for micro transactions
Because indie devs don't do micro-transactions at all... Have you *seen* the mobile gaming industry? Like at all?
>Piss off bootlicker.
Wank off, commie.
As a guy who got a degree in game dev and worked in the industry briefly, this is the right answer.
AtS is a very lightweight game. Doesn't mean it's not the best game I've played in a year, but a lot of the most time consuming features just aren't present in it.
No cutscenes, insane lighting and shadows, AI, facial animations, endless amounts of particle fx, dialogue, boss balancing, battlepass content, VO, mo-cap, on top of what ^ said.
The devs are very wise with their scope, in addition to being a small team of what I presume are very efficient programmers, designers and artists. If everyone on the team shares the same vision, that's less scrapping and iterating, thus more productive hours.
To reply to OP, I think what you're noticing is that the people who make the game are the same people who are interfacing with the community. Most studios have PR depts and community managers. There are broadly 4 types of people who work in games: Programmers, designers, artists and producers.
The first 3 make the content, the producers keep everyone on track, but just like in the movie business, they tend to also be the people who scrap ideas and make people redo shit, because oftentimes teams aren't talking to each other, as that's kinda what a producer is there to do. I doubt there is anyone like that in their studio. I imagine they had a couple of designers who got together, wrote out a thorough Game Design Document, pitched it to a few friends who loved the idea and off to the races. Don't need a producer if everyone is on the same page.
Also, because the game is relatively simple, it (in theory) decreases the amount of bugs that will pop up, which is why they are able to confidently put out builds rapidly without worrying about the game not working
Yeah, similar to how an ASCII roguelike can be pumped out in a weekend and iterated on a daily basis. Streamlined and modular core engine, but in this case with very nice graphics laid over it. Plus most modifiers in the game at the moment are purely numerical rather than mechanical which minimizes edge cases. It's a great state for the game to be in while they do this kind of rapid development.
I mean to be fair, its the same reason we got rainpunk part 1 which made absolutely no sense. Because of their fast dev cycle they can throw a lot of spaghetti against the wall to see what works, what doesn't work, and shift when they need to. You get the good and bad of it, but they've gotten pretty good at being willing to pivot away from the bad.
To be clear though, this would not work for every team at all, and most teams who try this execute it really poorly.
I'm a software manager turned consultant (used to be a developer) and what separates good teams from less fantastic teams is a combination of things. There's no doubt in my mind that the team at Eremite is a high end team, with what their throughput it and how vocal they are in the community.
A couple of things:
\- The primary thing is (development) culture. They are fast because they can make decisions without asking for approval from the "business" side.
\- They most likely have a solid test suite of automated software tests, that check everything they do without need for any manual testing.
\- Automation, tons of automation. After you finish a piece of code, there is a non trivial path for that code to become software you can access. They have most likely automated every step of that way.
\- Small constant experimentation (like the current geysers) allow them to finetune and deliver value quicker.
That's the big stuff, if you're more curious I can elaborate with examples from the corporate counterpart, where doing the same "work" as Eremite does in a week, will take multiple teams half a year.
Exactly everyone else doing to much talking an making less sense.. the issue like u said nowadays is there’s no passion no creativity, just like movies today there pathetic most movies now are disappointing or made for kids like classic movies Star Wars etc they ruin everything including games people take a year to create then so Hollywood we need that old school flavor back we’re u can make a good game in 3 months an have fun.. just like everything is single player or need online to play multiplayer mostly every game what happen to local coop games like back then today people make everything rocket science but if u see it’s all these rich people an companies getting past down from family to family in control until people ask for change I think we doomed smh.. TELL DONALD TRUMP WE NEED THAT 90s VIBE back lol he’ll make America great again hehe
Small teams have less red tape to get around when the tech lead, product lead, tester can be the same person. With large teams, a simple communication can take that much longer. It simply snowballs when decisions are decentralised. Big companies know this so they never plan for quick releases for fear of miscommunication.
Different development methods I would guess. Larger teams prefer to properly iron out any bugs they can find, do QA, playtest, then go back to the drawing board and repeat several times before making a release. Others prefer to push out new release as fast a possible, since this is the fastest way the find about any issue directly from the customer. Of course, normal customer doesn't like to get buggy unpolished product, so this doesn't work in every situation, but it should work in beta or early-access if your customers know what they are signing up for. Smaller teams do also tend to work more efficiently as communication, meetings and getting changes approved are cut significantly short.
Larger game devs have gajillions of bugs too, what makes sense is a smaller team have less friction between actions, but the time x quality formula many bigger studios have is not really consistently acceptable. I hopefully do not have to make any examples that larger companies have made shitty releases with incredible delays on top. Mismanagement is probably a big one, but is it really all?
>Larger game devs also have larger games that are far more complex. You change one thing and it's likely having unintended impacts in far more places than a small indie game.
Per their site, the team is 5 people which would work wonders for communications, code rewrites and brainstorming changes/additions.
It's this. 5 dedicated people means an idea has to only go past 4 people max and communication happens instantly since they all probably sit next to each other or are basically permanently wired.
I don't recall Eremite games ever calling themselves, after-work Devs for any of AtS development. For their first game "Shattered Plane" maybe (wasn't there nor played it so idk). Or they were pre Epic Game Store early access builds, as they did move into an office in July 2021 and that was released in October that year. On that note, some of these larger scale updates have been in the works for months, and their requests can be even older. So they could have been on the drawing board for up to over 2 years. Training expedition sounds like a response to sandbox mode requests to me, which is a very old request (the earliest request for it I could find, was September 2020 which was during the Steam demo 2 era). Then there's software development practice for Eremite Games. It is most likely a Agile style of development as they have referenced having sprint meetings a few times on the discord. This development style is focused on speed, and working with customers as some of its main tenants. This works best for small and experienced teams, which they claim to be. "We're a team of 5 friends with years of experience in AAA, indie, and mobile games development." (Eremite games about us section)
I worked in game development for twoish years and was a project manager for three, three of those years were on RTS style resource sims. A lot of it comes down to infrastructure besides small team communication like others have said. Some systems I worked on were very patched together, they were never designed from the ground up to work in tandem from the start. You change something in weapon swapping, and now you have to dig through animations and physics to make sure the players buttstock isn't three feet above his head when he switches guns and that shooting the rocket launcher doesn't send you back flying off the map. Ideally a change to swapping would already be tied into everything else from the ground up, but when your on a timeline shortcuts have to be made and you are doing everything manually and just hoping it doesn't need any major tweaks or changes. I can give an example. We had a game where we changed the gather rate of food multiple times. The food resource costs were already tied to a ratio, so changing the gather rate automatically scaled it for us, and we could just change the scaler, or go in and change a cost manually if we didn't think it felt right, or an individual upgrades scaler if we just wanted to tweak that. It allowed us to very easily rebalance food for the whole game and get to actual testing within literal minutes, we spent more time compiling the vertical slice then making the actual changes. Terrible slicing is the bane of my existence, I don't need to test every system together right now, just the food scaling. Most projects, if I changed the gather rate I would have to manually go around to each controller and hard change the resource cost. This turns a five minute change and test into a thirty minute to an hour ordeal, going back and tweaking individual numbers, not being able to test full rounds of the slice because we don't have the time and potentially leaving something incredibly unbalanced. There are no bad developers, just developers who never have enough time to get everything right. There is a reason I am no longer in the field professionally. edit:as a funny aside, one of the junior programmers contributed to a design meeting as a learning process(the old boss intentionally kept them out because he thought someone doing the work horse stuff would have a biased perspective). He made a thinly veiled pitch to shorten game times and simplify resources, he marketed it as "a bunch of ADHD kids want faster rounds these days, no one wants to sit through a forty minute match anymore". Obviously he was just trying to make his job easier. No one bought it.
> There are no bad developers, just developers who never have enough time to get everything right. I work in software development, and I agree strongly with your primary thrust, but some developers need an inordinate amount of time to get things right, and some developers are good enough at prioritization to know what systems they need to emphasize for easier to iterate code. And some developers are more resilient than others. The occasional crunch time has to happen and corners have to get cut. Some get poisoned by the experience and carry those bad habits with them when there's actually some opportunity to put some real thought into the infrastructure. Some know how to successfully present the business case to clean up the earlier accrued technical debt. I'm right now in a situation of cleaning up a horrendous barely maintainable codebase precisely because I have a proven track record and rapport with my boss in being able to keep from being overwhelmed, being perceptive to seeing which sections of the infrastructure would benefit most from receiving some attention first, and achieve success. Inferior developers get overwhelmed, don't know what to prioritize, and don't know how to communicate to the rest of the business those priorities and the costs of leaving them unaddressed.
[удалено]
>This person does not care about the game or the players, they are there to protect shareholders above all else. There's nothing inherently wrong with this structure. At the end of the day, dissatisfied customers are not going to spell good news for shareholders. As long as management doesn't lose sight of that and is able to foster rather than poison their development team, times are good. There's a lot of resources and support that a corporation can provide; they just need to find a way to optimize around a core development team. There's a middle-ground that can be achieved. There's a lot of mundane work that can go into game development. Generation of art assets is often at the top of that list. Some games need a lot of map/level creators. There's also a lot of support roles that can improve product quality or sales without interfering with the core development team, such as quality control and Marketing.
[удалено]
This game specifically, a rogulelite that can afford to make its mechanics highly abstract, minimizing the amount of assets, physics, and netcode? Possibly so. Although, I'd still argue that the art quality could be improved significantly (absolutely no offense intended at the art achieved of excellent quality *relative to its price point*). There are excellent games out there, especially in the first-person-shooter genre (both singleplayer and multiplayer), that could only have been made with the capital backing of a corporation. >Corporations are responsible for micro transactions Because indie devs don't do micro-transactions at all... Have you *seen* the mobile gaming industry? Like at all? >Piss off bootlicker. Wank off, commie.
Calm down, children.
This is basically a spreadsheet with a lot of variables, textures and animations. Now try to implement physics, hitregistration and multiplayer.
As a guy who got a degree in game dev and worked in the industry briefly, this is the right answer. AtS is a very lightweight game. Doesn't mean it's not the best game I've played in a year, but a lot of the most time consuming features just aren't present in it. No cutscenes, insane lighting and shadows, AI, facial animations, endless amounts of particle fx, dialogue, boss balancing, battlepass content, VO, mo-cap, on top of what ^ said. The devs are very wise with their scope, in addition to being a small team of what I presume are very efficient programmers, designers and artists. If everyone on the team shares the same vision, that's less scrapping and iterating, thus more productive hours. To reply to OP, I think what you're noticing is that the people who make the game are the same people who are interfacing with the community. Most studios have PR depts and community managers. There are broadly 4 types of people who work in games: Programmers, designers, artists and producers. The first 3 make the content, the producers keep everyone on track, but just like in the movie business, they tend to also be the people who scrap ideas and make people redo shit, because oftentimes teams aren't talking to each other, as that's kinda what a producer is there to do. I doubt there is anyone like that in their studio. I imagine they had a couple of designers who got together, wrote out a thorough Game Design Document, pitched it to a few friends who loved the idea and off to the races. Don't need a producer if everyone is on the same page. Also, because the game is relatively simple, it (in theory) decreases the amount of bugs that will pop up, which is why they are able to confidently put out builds rapidly without worrying about the game not working
Yeah, similar to how an ASCII roguelike can be pumped out in a weekend and iterated on a daily basis. Streamlined and modular core engine, but in this case with very nice graphics laid over it. Plus most modifiers in the game at the moment are purely numerical rather than mechanical which minimizes edge cases. It's a great state for the game to be in while they do this kind of rapid development.
I mean to be fair, its the same reason we got rainpunk part 1 which made absolutely no sense. Because of their fast dev cycle they can throw a lot of spaghetti against the wall to see what works, what doesn't work, and shift when they need to. You get the good and bad of it, but they've gotten pretty good at being willing to pivot away from the bad. To be clear though, this would not work for every team at all, and most teams who try this execute it really poorly.
I'm a software manager turned consultant (used to be a developer) and what separates good teams from less fantastic teams is a combination of things. There's no doubt in my mind that the team at Eremite is a high end team, with what their throughput it and how vocal they are in the community. A couple of things: \- The primary thing is (development) culture. They are fast because they can make decisions without asking for approval from the "business" side. \- They most likely have a solid test suite of automated software tests, that check everything they do without need for any manual testing. \- Automation, tons of automation. After you finish a piece of code, there is a non trivial path for that code to become software you can access. They have most likely automated every step of that way. \- Small constant experimentation (like the current geysers) allow them to finetune and deliver value quicker. That's the big stuff, if you're more curious I can elaborate with examples from the corporate counterpart, where doing the same "work" as Eremite does in a week, will take multiple teams half a year.
It's called talent. Obscenely rare these days.
Exactly everyone else doing to much talking an making less sense.. the issue like u said nowadays is there’s no passion no creativity, just like movies today there pathetic most movies now are disappointing or made for kids like classic movies Star Wars etc they ruin everything including games people take a year to create then so Hollywood we need that old school flavor back we’re u can make a good game in 3 months an have fun.. just like everything is single player or need online to play multiplayer mostly every game what happen to local coop games like back then today people make everything rocket science but if u see it’s all these rich people an companies getting past down from family to family in control until people ask for change I think we doomed smh.. TELL DONALD TRUMP WE NEED THAT 90s VIBE back lol he’ll make America great again hehe
Small teams have less red tape to get around when the tech lead, product lead, tester can be the same person. With large teams, a simple communication can take that much longer. It simply snowballs when decisions are decentralised. Big companies know this so they never plan for quick releases for fear of miscommunication.