devtrackers.gg
over 1 year
ago -
Rocket
-
Direct link
Note the reason for this change was discussed extensively at the project level and has three core elements
1. To standardize player experience for development
It had become almost impossible to balance the and game and add content that was consistent when there were n number of conditions players could adopt.
2. To focus the experience towards an overall experience "intent"
Players often describe this as the "reason why" or "endgame". In game development this might be described as the "hook". We feel as a studio we have become quite good at making *systems* for systems based games - but we need to make those systems *matter*.
To help with this focusing the experience more allows us to develop towards a specific experience and goal. This doesn't mean we don't intend to support and allow players to craft their own experiences (which is why we left the settings in the ini), but we needed to start working towards this if we ever hope to achieve it.
3. Many of the settings were not well described, documented, named, and ranged
This means, the settings were confusing to players (and, frankly, developers themselves). Sometimes a setting might have been added that had no function, and then misunderstood and used for another purpose. Or a setting added and not used entirely, or removed from the game. Some of these orphaned settings then have a life of their own - with the rest of the game balancing around them.
At this point in the development we opted for the safest option that achieved progress towards a better game: one that was stable, cohesive, heading in a specific direction, and that was achievable. That involved leaving the settings largely alone - where we could - in the ini file, but coming up with standardized values we would push the overall goal experience towards.
1. To standardize player experience for development
It had become almost impossible to balance the and game and add content that was consistent when there were n number of conditions players could adopt.
2. To focus the experience towards an overall experience "intent"
Players often describe this as the "reason why" or "endgame". In game development this might be described as the "hook". We feel as a studio we have become quite good at making *systems* for systems based games - but we need to make those systems *matter*.
To help with this focusing the experience more allows us to develop towards a specific experience and goal. This doesn't mean we don't intend to support and allow players to craft their own experiences (which is why we left the settings in the ini), but we needed to start working towards this if we ever hope to achieve it.
3. Many of the settings were not well described, documented, named, and ranged
This means, the settings were confusing to players (and, frankly, developers themselves). Sometimes a setting might have been added that had no function, and then misunderstood and used for another purpose. Or a setting added and not used entirely, or removed from the game. Some of these orphaned settings then have a life of their own - with the rest of the game balancing around them.
At this point in the development we opted for the safest option that achieved progress towards a better game: one that was stable, cohesive, heading in a specific direction, and that was achievable. That involved leaving the settings largely alone - where we could - in the ini file, but coming up with standardized values we would push the overall goal experience towards.