I, as a college student game dev, have stated before to the players that there will be an update as well as a revamped game mechanic. As I discussed further and explained the reasons why this game mechanic is better, why the old one has numerous issues, and why maintaining the old one is difficult for me, players are now unhappy with it.

One of the many players explained that the game mechanic makes the game not enjoyable, not fun to play, and unintuitive to use. They would like for me to keep the old mechanics.

I reluctantly disagreed and said I will not revert back, but I still kept getting topics about this. I wanted to know if I am doing the right thing. I wanted to know that I should trust my gut, even when there's a looming danger that I will lose some of my players. Any advice?

(Note: my game is a very small one. I am not paid for the game, nor am I selling it. It's just that one of its mechanics made the group of players split into two polarized sides.)

Hi. It depends, what's your goal?
If it's getting a wide as possible player base, I'd simply listen to them (if most of them give this feedback). If you're trying to build up to a new game and gathering experience, you might wanna continue as you do, and explain them why you're going this way.

There's no universal answer to choosing between listening to players and following your gut feeling.

Did you make the game for you to play it or for others to play it? If the later then listen to them, what matters is if they enjoy it, make a poll (because people are vocal when unhappy but not so much when happy and it may actually be a minority that dislikes the feature) asking wether to keep it or leave it and making it clear that you'll follow the poll and decide then.

Would it be viable to implement both? Perhaps have the player choose between the two based on their preference.

Could you briefly describe said mechanics?

Overall IMO you should trust your user base and suck up your personal pride. A poll, as mentioned, would be a good place to start.

The question is formulated so abstract that its near impossible to answer.
Who knows if they just need some time to adapt, if they dont hate the new mechanic but dont know how to explain that and there is just some quirk you need to fix, if its just a few complainers and the silent majority likes it, or if its really bad?

The question is formulated so abstract that its near impossible to answer.
Who knows if they just need some time to adapt, if they dont hate the new mechanic but dont know how to explain that and there is just some quirk you need to fix, if its just a few complainers and the silent majority likes it, or if its really bad?

You're right. I didn't realize the question is abstract.

The game mechanic I made involves "friendly fire". This means that entities that fire projectiles will affect whatever gets hit by it. For me, it makes realistic gameplay, it makes game development easier to work with, and it makes the game challenging to play. However, players are not enjoying it and they are suffering from the side effects because of it. For instance, "friendly fire" kills their owned entities if placed in such a way that projectiles hit themselves. "Friendly fire" can also cause the loss of a game round for the fact that it kills off their king entity if the king gets hit a few times.

The two sides to this are groups with almost equal numbers. I can tell because we're a pretty big class. One side insists that "friendly fire" creates necessary challenges for the game to be satisfying, while the other side insists that "friendly fire" causes the game to be "unintuitive", "unenjoyable", and "downright stupid" for the fact that player-owned entities can be killed off without knowing it.

I build "friendly fire" because without it, it is getting way too difficult to develop the game. I would rather have "friendly fire" than "unplayable lag", which is what the old game mechanic suffers from, and I need to remove that because of the lag.

The people who develop a game, should NEVER be the ones to test it.

The game mechanic may sound great on paper or in your head, BUT if you are receiving a lot of negative feedback about it, you may have implemented something that genuinely makes the whole gaming experience unenjoyable for others.

Not listening to the general consensus of your alpha/beta testers can lead to a lot of problems down the road.

On a side note - a projectile is nothing more than an object. Why is it so difficult to include which team fired it ? Just about every other FPS arena shooter does this WITHOUT lagging out the game.

I would recommend finding out WHY it's causing lag, instead of ignoring it.

On another note, how do you deal with griefers / immature kids? There are a few FPS games with "friendly fire" I have played in the past, that griefers love to kill their own teammates.

The question is formulated so abstract that its near impossible to answer.
Who knows if they just need some time to adapt, if they dont hate the new mechanic but dont know how to explain that and there is just some quirk you need to fix, if its just a few complainers and the silent majority likes it, or if its really bad?

You're right. I didn't realize the question is abstract.

The game mechanic I made involves "friendly fire". This means that entities that fire projectiles will affect whatever gets hit by it. For me, it makes realistic gameplay, it makes game development easier to work with, and it makes the game challenging to play. However, players are not enjoying it and they are suffering from the side effects because of it. For instance, "friendly fire" kills their owned entities if placed in such a way that projectiles hit themselves. "Friendly fire" can also cause the loss of a game round for the fact that it kills off their king entity if the king gets hit a few times.

The two sides to this are groups with almost equal numbers. I can tell because we're a pretty big class. One side insists that "friendly fire" creates necessary challenges for the game to be satisfying, while the other side insists that "friendly fire" causes the game to be "unintuitive", "unenjoyable", and "downright stupid" for the fact that player-owned entities can be killed off without knowing it.

I build "friendly fire" because without it, it is getting way too difficult to develop the game. I would rather have "friendly fire" than "unplayable lag", which is what the old game mechanic suffers from, and I need to remove that because of the lag.

You don't fix a problem by adding another problem, and you definately don't introduce a new mechanic because it "makes developement easier" or "enhances performance", you do it because you want that mechanic in the game.

If your game is slow, profile it, find out why and fix it, don't fix it by having it "do less" but by figuring out where YOU failed to make it perform correctly. Plenty of games do this just fine so there's no reason you can't do it too.

For something like friendly fire, personally, I'd implement it as an option you can toggle. Plenty of games let you disable friendly fire (for good reason, it's a divisive mechanic in the game world :P Some people love it, some people hate it).

Like others mentioned though, these things are rather subjective. I think they also depend on how big your sample size is. I know I can sometimes get feedback from a handful of people, but I think realistically, there's not enough data there to extrapolate meaningfully from. Those handful of people could easily be an anomaly (almost certainly are if they're demographically similar. Say, other students at your university, friends, family. It's not necessarily representative of the general public of people who may play your game).

I would imagine toggling off friendly fire would be easier on resources than including it, but I have no idea how you've built your game. Generally, I find ignoring things to be less resource intensive than including them :P But, that's likely situational.

I'm going to go out on a limb and suggest that maybe the underlying code is a bit broken and should be refactored/improved anyway. Judging whether or not to apply damage to a character should not be a performance issue if the code is well-designed. Perhaps he is trying to determine in advance whether or not to perform the check to begin with on a per-character basis when in fact he should go ahead and do it as he is right now but simply calculate the damage per character hit, after the character has been hit? The damage calculation can simply be nullified if the character is friendly. Hard to say without seeing the code but I'd be very surprised if there aren't multiple candidates in the code for improvement that would make this issue go away entirely.