I’m not sure I understand your point. RNG makes games harder to balance, because it increases variance. Instead of knowing for sure that players facing X enemy with Y health will deal Z damage per turn and take W turns, the dev of a game with RNG has to factor in possibilities like the player critting and oneshotting the enemy, or the enemy critting and oneshotting the player, etc.
If I were a new game dev, I think I would try to have as little RNG possible in my game (I might make an adventure–puzzle game, for instance).
My point was that implementing proper game balance is a tedious task that takes months to accomplish, even with a team of developers. Breaking mechanics down into governing equations with basic weights (difficulty sliders, essentially) takes a level of competence that very few devs possess on their own.
Let's take an example from the game to clarify further:
Let some nephelym be represented by a variable (i.e. colossus = c)
We want to generate a list of traits for the colossus based on its species, resulting in the following available traits:
- Meaty
- Hung
- Buxom
- Busty
- Chubby
The number of traits chosen is randomized from 0 - 3 with each training having an even chance of being picked. We'll ignore the level of the trait since that adds complexity I don't want to deal with for this example.
The resulting formula is the easiest to implement for this scenario (written in c++ for demonstration purposes):
Code:
// Trait list
trait[] = {"meaty", "hung", "buxom", "busty", "chubby"};
// Generate random number between 0 and 4
n_trait = rand() % 4;
for(i = 0; i <= n_trait; i++){
index = rand() % 4;
c[i] = trait[index];
}
That right there is what I meant when I said RNG determined values are the easiest to implement.
---------------------------------------------------------------------
Now let's look at how to potentially add a better version of this (i.e. not using "rand" functions). We'll use the same trait list to keep things simple.
The simplest implementation is assigning weights to each trait which can be thought of how common they are for a nephelym. Here's the same trait list with potential weights:
- Meaty = 50%
- Hung = 50%
- Buxom = 35%
- Busty = 35%
- Chubby = 10%
Those percentages could easily be implemented as sliders in an options menu to make it easier or harder to obtain certain traits.
An alternative approach is to take the level of the player and use that to generate the traits. This would mean each trait becomes more common to spawn as the player essentially increases the chance for traits to be present. Again, this still relies on probability, but it's a better implementation of it.
Example of implementation:
Code:
col_busty_base = 0.3;
sum = p_lvl/p_lvl_max + col_busty_base
if(sum >= 1){
col_busty = 1;
}
else{
col_busty = sum;
}
---------------------------------------------------------------------
Another implementation of traits is to add a mechanic in which you can create items that remove/add specific traits. This could be accomplished via mixing types of semen/milk for the trait, and using some other material for increasing the level of the trait. I personally dislike this method since it removes the point of breeding, but it at least allows for some control over traits.
The best implementation of traits (in my personal opinion) is through the second method under the RNG section, and adding the weights of two identical traits between nephelym together for a maximum of 100%. Since the weights of a trait are tied to the nephelym rather than a global value it's rather easy to implement and incentives players to learn about the system.
Here's an example of what I mean since describing math is obnoxious:
c_b = weight for busty trait in colossus
s_b = weight for busty trait in succubus
o_b = weight for busty trait in offspring
Code:
if(c_b + s_b >= 1){
o_b = 1;
}
else{
o_b = c_b + s_b;
}
---------------------------------------------------------------------
Author notes:
I'd like to apologize about how massive this post became. Explaining code or math in any capacity is difficult to do without providing the necessary context. I've learned this the hard way when teaching students at my community college how to accomplish certain tasks.
I'd also like to emphasize that my methods are purely for demonstration purposes and can easily be modified to make the calculations more simple/complex depending on the developer. The use of player level is a commonly used method that it's essentially standard industry practice. The game should reward the player for leveling up, and my method is the most basic implementation of it.
Finally, I only have coding knowledge that pertains to simulating or solving complex problems. I personally don't have the expertise to develop a game on my own and only offer feedback. Someone like
Drages would be far more suitable than me at fixing this game for DH.
