Very needed balance changes (0.19.2009)

[erdrik]

...
Also I don't understand why you think that making floors claimable will require significant dev time to implement. I don't know how excatly it's working now but I imagine that there are different terrain classes with different properties. You just add property "claim" to that like you added property "wealth" before. It's no big deal.
You say that mechanically adding this property is hard. On what information you base that statement?

First off let me add a disclaimer in that Im not fully familiar with Rimworld's code, and trying to learn/explain programming in detail is not easy(it can be self taught, but there is schooling for it for a reason). So take what Im about to say as a general idea.

I am a programmer, as a hobby since I was in high school back in 1996, and recently Im attempting to develop my own game. Ive also looked into modding Rimworld and its code. (I admit I haven't looked since alpha13)

Programming is not as simple as "just adding a property" and expecting everything to start working with it. Anything and everything that you want done, must have code specifically telling the program how, when, and where to do it. And each class needs equally as extensive code relating to how to interact with the property of other classes. OOP(object oriented programming) allows "child" classes to "inherit" functions of the "parent" class, but that still means you have to specify how classes outside that hierarchy interact with the hierarchy's properties and functions. (and you may want specific classes to interact with existing inherited functions differently than its siblings, which will require a manual rewrite specific to that child class)

Rimworld has passed many iterations and at this point likely has many specific interactions with its various class hierarchies.

As a small example:
You suggested simply adding "claim" property to terrain.
But you can only "un-claim" or "claim" by first selecting an object, or with the "claim" tool.
The "claim" tool doesn't interact with terrain, and you can't select terrain.
So you would need to add "selecting terrain" functionality to the game.
Don't forget to add a "selected Terrain info panel", like how a normal selectable object gets.
How do players select terrain that a normal selectable object is on top of?
Now that terrain is selectable, how does a player "deselect" or clear all selections? (since they can't simply click empty terrain space anymore)
Should terrain be included in band box selections?
How should terrain selection handle selection through double clicking?


This is just the tip of the iceberg. Nothing in programming(as complex as most game programming) is ever as simple as "just add property".  Programming is like trying to build your own custom reality. You have to literally create your program's "physics", and manually build every interaction. If you don't, it doesn't happen. You can setup emergent behavior and reacting interactions. But the more complex those interactions become the more difficult it is to keep them in check when you add anything new.

[5thHorseman]

In general, if you don't know how to code something yourself yet think it'd be easy, it's actually hard. If you think it'd be hard hard, it's impossible.

This is my experience over decades and it is just about 100% true.

[BLACK_FR]

Guys if I'm not coding myself that doesn't mean that I don't know how it works (I learned python for example). I've participated in development of several programs. I usually write algorithms for them and suggest ways to circumvent problems. Sometimes it work, sometimes it doesn't. In cases when it doesn't work you just need another solution. When I said about participation I meant that.

In general, if you don't know how to code something yourself yet think it'd be easy, it's actually hard. If you think it'd be hard hard, it's impossible.

I had many instances when there was a problem that my hired programmer thought was very hard to solve. But when I suggested solution that he didn't think before he replied like "oh, that would be easy to do". Too much expertise allows you to evaluate option correctly but it doesn't help you to generate those options.

@erdrik
I understand what you are saying, as I said I was participaiting in development of software. But I'm willing to identify problems and suggest solutions. If there is problem with that solution you just need to generate another one to solve problem. That's not easy but that's the right way in my opinion.
So in your example:
Easy way to circumvent that problem (if that's a real problem that exists in Rimworld code) is to make unclaimed ancient ruin floors not a terrain but a structure (like walls). When they are claimed they should become "normal" floors.
Problem solved)
Any other problems?)

[vzoxz0]

I am a programmer, as a hobby since I was in high school back in 1996, and recently Im attempting to develop my own game. Ive also looked into modding Rimworld and its code. (I admit I haven't looked since alpha13)

Programming is not as simple as "just adding a property" and expecting everything to start working with it. Anything and everything that you want done, must have code specifically telling the program how, when, and where to do it. And each class needs equally as extensive code relating to how to interact with the property of other classes. OOP(object oriented programming) allows "child" classes to "inherit" functions of the "parent" class, but that still means you have to specify how classes outside that hierarchy interact with the hierarchy's properties and functions. (and you may want specific classes to interact with existing inherited functions differently than its siblings, which will require a manual rewrite specific to that child class)

Rimworld has passed many iterations and at this point likely has many specific interactions with its various class hierarchies.

As a small example:
You suggested simply adding "claim" property to terrain.
But you can only "un-claim" or "claim" by first selecting an object, or with the "claim" tool.
The "claim" tool doesn't interact with terrain, and you can't select terrain.
So you would need to add "selecting terrain" functionality to the game.
Don't forget to add a "selected Terrain info panel", like how a normal selectable object gets.
How do players select terrain that a normal selectable object is on top of?
Now that terrain is selectable, how does a player "deselect" or clear all selections? (since they can't simply click empty terrain space anymore)
Should terrain be included in band box selections?
How should terrain selection handle selection through double clicking?


This is just the tip of the iceberg. Nothing in programming(as complex as most game programming) is ever as simple as "just add property".  Programming is like trying to build your own custom reality. You have to literally create your program's "physics", and manually build every interaction. If you don't, it doesn't happen. You can setup emergent behavior and reacting interactions. But the more complex those interactions become the more difficult it is to keep them in check when you add anything new.

You realize there are such things as terrain-specific tools already, right? There is a lot of stuff already in place that would let Tynan and his team do this with ease.

Programming is easy. Balancing is hard.

[Actarion]

if you wanna play around rules like here https://ludeon.com/forums/index.php?topic=45664.0 well... do it ?

and if you don't want to, well... don't do it ?

Some ppl play whit infinite savegame, some not, etc etc ...
This game is a HUGE sandbox and nobody is here telling you how to play x_O If you find something imbalanced it's up to you not to use it ?

[BLACK_FR]

if you wanna play around rules like here https://ludeon.com/forums/index.php?topic=45664.0 well... do it ?

and if you don't want to, well... don't do it ?

Some ppl play whit infinite savegame, some not, etc etc ...
This game is a HUGE sandbox and nobody is here telling you how to play x_O If you find something imbalanced it's up to you not to use it ?

I answered that question already in my topic that you gave link. Reason why it's not possible is because if you intentionally play game badly - it's not interesting. And if one of the mechanics of the game is badly balanced - you can't just "consciously don't use that". Because you will play worse than casual players. If that's your solution (just play worse than bad players) - it's bad one. My solution is to fix the balance/mechanics (still don't see a difference).

And also I really don't understand why you oppose balance changes in suggestion section of the forum. Especially with argument like "game don't need balance improvement ever because people can just not use bad balance to their advantage".

[5thHorseman]

In general, if you don't know how to code something yourself yet think it'd be easy, it's actually hard. If you think it'd be hard hard, it's impossible.

I had many instances when there was a problem that my hired programmer thought was very hard to solve. But when I suggested solution that he didn't think before he replied like "oh, that would be easy to do". Too much expertise allows you to evaluate option correctly but it doesn't help you to generate those options.

Well then you should definitely become a programmer. There are a lot of problems that a lot of non-programmers think are easy and a lot of programmers think are hard. Think of all the joy you could bring to the world.

[vzoxz0]

I have had many instances of convincing my boss he had my good idea. I think that's what you experienced BLACK_FR.

[BLACK_FR]

@5thHorseman
You have limited time in the world. I'm more interested in developing my thinking than developing my programming skills. And posting on forum of the game I like of course.
As long as I can get what I want by making good specifications there is no need to change my work for programming (amount of money you earn is important after all).

@vzoxz0
Do my solution to erdrik's problem of terrain seems like he convinced me about his good idea? Because that's the example of how I suggest solutions to "hard problems" that I was talking about.
You don't have to guess how that work. You can just check examples in this topics (both on proposed changes and on solving problems). If after that you still would be thinking that those ideas come from "smart subordinates that have to convince their boss to make changes"... I still would be thinking that you are wrong but won't argue because it's offtop already and because arguing in internet is not very productive.

[5thHorseman]

@5thHorseman
You have limited time in the world. I'm more interested in developing my thinking than developing my programming skills. And posting on forum of the game I like of course.
As long as I can get what I want by making good specifications there is no need to change my work for programming (amount of money you earn is important after all).

Sounds good let me know how that goes for you. My time too is limited and I've spent enough of it on this topic.

[Actarion]

so, playing around rules is normal, and trying to enjoy a game like he should be played isn't ?

nobody (except yourself) force you to stop building art right before finishing it. And why in hell whould you do that in first place ?
only cause you can "play around the rule" that give value to it only when it's finished.

It's like someone told you to "stir the salad" so you take the bowl and shake it... You played around the words, you'r somewhat right, but that's the wrong way to do it.

[BLACK_FR]

Your reply is more appropriate in my topic in general discussion (where I listed all available tactics), not in this topic in suggestions, where I suggest how to fix those things (unless you oppose the idea to fix them).

But anyway. You have to decide if using that trick is ok or not. If it's ok - then there should be no objections for using it. If it's not ok - then you should agree that fixing it is a good idea.

Also you took least consequential point that doesn't change much. If you don't use that you still don't pass minimum wealth threshold, so it's not a solution. Most consequential points are how health of items affect wealth and idea of raid multiplier based on time.

And even in this example you assume that you and only you know how game should be played. Why you think that your vision of how this mechanic should work is right? If I don't finish bill with 10% work remaining - is it ok? If I stop working after 1% completion - is it ok? Can I start new bill if I didn't finish last one and why?
All this statements are arbitrary. It's like saying "you play too well, just play bad like me and you will have challenge". It's like saying to chess grandmaster that you can't use certain moves because they are too good.

Again, I want to play on the hardest difficulty possible and use all mechanics that are availible in the game. If I see that some mechanics are poorly balanced - I write about that in order to make them better. But your idea "dont improve anything, just play badly". May be you can enjoy game by intentionally playing it badly, I can't.

[Actarion]

"you assume that you and only you know how game should be played."

Not really, i just want to say, ppl play the game the way they want, and nobody have to tell them how to play it.

If you wanna play around rules and optimise every aspect of the game, do it, if you enjoy it that's great !
If you wanna play in basebuild just to enjoy building something whitout any seatback, do it !

It's a game, the only point of it is to enjoy your time, and you do it your hown way.

My problem whit that topic is that you say "YOU ABSOLUTLY NEED TO REBALANCE THE GAME CAUSE...." but, no, for you it's crucial, but mostly for you...

[BLACK_FR]

If you can play merciless naked brutality like regular peaceful game after first year - than there is clearly a problem with balance. Hardest possible difficulty should be at least a little bit hard. Do you disagree?

Also do you think that my proposed changes are bad?

[bobucles]

Rimworld's threat generation is a central game mechanic and its proper functioning is essential for the bulk of enjoyable content in the game. It makes sense to eliminate exploits that take away from that experience. No, partially crafting a hundred items to subdue enemy raid points is not fun and there's nothing intuitive about it. It won't be missed.