Forum Discussion
12 years ago
Thanks for the compliments about my writing. I happen to be an attorney by trade, so good guess. I understand both sides of the argument, and completely appreciate the fact that a glitch affecting players enjoyment of the game serves as a sufficient basis for people to be against the reimplementation of the code should it risk a similar redundancy.
However, as they say, there is "more than one way to skin a cat". In spirit of that statement, code could still be implemented to satisfy these opposing concerns about the payouts.
EA could simply increase the payouts all together based on the players total friend base. Whereas, instead of reimplementing complex code gradually increasing payouts with each visit, the payout for each unit would be a variable flat rate based on the total friend count of each player. By example, one page of friends nets "x", two pages of friends nets, "y", so on and so forth. That is a lot cleaner code structure than implementing a multiplier with each progressive unit return. Since the code defines the payments based on the users total friend count, the payouts are simpler eliminating complex code that may result in server and client instability while satisfying players who desire these rewards.
By these means, people are incentivized to add friends to their count, over and above the singular benefit of netting more frequent holiday rewards. While, the earlier purported "glitchy" code is not reinstated risking a replay of the earlier problem.
That is a much simpler code to implement, and reduces or minimizes the risk of the problematic hacking that the earlier code and players experienced. As I said, there is more than one way to make things work as a happy medium to satisfy everyone.
However, as they say, there is "more than one way to skin a cat". In spirit of that statement, code could still be implemented to satisfy these opposing concerns about the payouts.
EA could simply increase the payouts all together based on the players total friend base. Whereas, instead of reimplementing complex code gradually increasing payouts with each visit, the payout for each unit would be a variable flat rate based on the total friend count of each player. By example, one page of friends nets "x", two pages of friends nets, "y", so on and so forth. That is a lot cleaner code structure than implementing a multiplier with each progressive unit return. Since the code defines the payments based on the users total friend count, the payouts are simpler eliminating complex code that may result in server and client instability while satisfying players who desire these rewards.
By these means, people are incentivized to add friends to their count, over and above the singular benefit of netting more frequent holiday rewards. While, the earlier purported "glitchy" code is not reinstated risking a replay of the earlier problem.
That is a much simpler code to implement, and reduces or minimizes the risk of the problematic hacking that the earlier code and players experienced. As I said, there is more than one way to make things work as a happy medium to satisfy everyone.
About The Simpsons Tapped Out General Discussion
Talk about your The Simpsons: Tapped Out experience with other TSTO players.
49,405 PostsLatest Activity: 2 days agoRelated Posts
Recent Discussions
Taps part 1,2 and 3
Solved2 days ago- 8 days ago
- 8 days ago
- 11 days ago