betty's oldies
Forum Expert
Introduction
Last month I made a recap thread explaining the server issues. The style will be the same as last time. We'll talk about some of them, a possible fix, and an explanation as to why some apparent fixes don't necessarily work. This thread has been updated as of April 30th.
Why did I start my recaps? Part of this was because there wasn't much explained in the official recap, so I figured this would focus on the issues/direction of the server instead of on the best threads. It's also a way for people to keep track as to how well the server is doing. Based on this feedback thread here (https://www.cubecraft.net/threads/need-your-feedback-aprils-issue-recap.188058/), you guys have suggested to do monthly recaps.
For this month's, we've seen the server do the following and we'll go over the following issues.
-Staff recruiting: 6 more helpers were hired, but 2 mod left (FadedRoses, zDutchie).
-Easter sale (50% off)
-Bug fixes
-FAQ
-Damage indicator mod
Shoutout to Spyro's CubeCraft analysis thread (https://www.cubecraft.net/threads/cubecraft-analysis.188057/#post-814095). We'll talk about his take on server development under "staff recruiting/handling."
Without further ado, let's begin.
Issues
Is it good to have a sale? Think the server did better this month? You're about to find out.
Conclusion
Things this month have improved since last month. So far we've had a better report system and possibly more server revenue from the Easter sale, but there's still more work to be done. Let's see how well the server can do for the next month.
Feel free to post other concerns/issues for next month’s recap.
Last month I made a recap thread explaining the server issues. The style will be the same as last time. We'll talk about some of them, a possible fix, and an explanation as to why some apparent fixes don't necessarily work. This thread has been updated as of April 30th.
Why did I start my recaps? Part of this was because there wasn't much explained in the official recap, so I figured this would focus on the issues/direction of the server instead of on the best threads. It's also a way for people to keep track as to how well the server is doing. Based on this feedback thread here (https://www.cubecraft.net/threads/need-your-feedback-aprils-issue-recap.188058/), you guys have suggested to do monthly recaps.
For this month's, we've seen the server do the following and we'll go over the following issues.
-Staff recruiting: 6 more helpers were hired, but 2 mod left (FadedRoses, zDutchie).
-Easter sale (50% off)
-Bug fixes
-FAQ
-Damage indicator mod
Shoutout to Spyro's CubeCraft analysis thread (https://www.cubecraft.net/threads/cubecraft-analysis.188057/#post-814095). We'll talk about his take on server development under "staff recruiting/handling."
Without further ado, let's begin.
Issues
Is it good to have a sale? Think the server did better this month? You're about to find out.
Although we're still at a net loss of a couple staff, the server has made a small comeback by hiring some more helpers. It's common belief here that many people believe hiring more is almost always good. For this case, this is a good outcome since the staff team is small, but not always the case. An admin on a different server noted that hiring too many staff can lead to some not having any work, thus lowering the productivity of the team.
As explained in my last month's recap regarding adding more people, we can see that that admin's server had passed the optimal number of staff to the point where hiring more does more hurt than help. Also, recruits need time to be trained and as such cannot apply their knowledge to the field immediately. The number of staff hired depends on the project size.
Consider this scenario: suppose you're a manager and you have 1 person assigned to do a task A. This person is working at 100% efficiency. Add another person to work on task A and you won't get the ideal 200% efficiency. You'll instead get a total efficiency of less than 200%, so each member works less than 100%. Adding even more reduces the efficiency of each member even further. Now let’s say we have a task B independent from task A and no one is assigned to task B. With our 2nd idle worker, we assign him to task B instead of A, giving more efficiency per member.
The scenario applies to the reports system. From the data gathered in the feedback thread, most voters responded that their reports were accepted in 1-3 days. That's faster than before where reports would take sometimes a week to get handed, but what if we have multiple players make a report against 1 player? Let's say 3 players each make a ban report against a player for hacking. 1 of those reports will get accepted but the other 2 aren't opened. A couple days later, they stay in the system and get closed because the first one was open. This results in a few minutes lost per report and this loss of efficiency builds up as more reports get processed. The fix here would be to automatically close any similar reports once one gets accepted unless the others are reporting a higher severity offense or are of completely different categories (e.g. bans and mutes).
For these reasons, we don't have 9 developers working on 1 field and why CubeCraft hires 3 different types of developers. Depending on the project size, it's better to have just a couple (1-3) than to have 4-5+ developers on the same thing. Additionally, each developer focuses on a different field. For example, one focuses on debugging, one on the anticheat, and another on web development.
ShinyRukii said:
As explained in my last month's recap regarding adding more people, we can see that that admin's server had passed the optimal number of staff to the point where hiring more does more hurt than help. Also, recruits need time to be trained and as such cannot apply their knowledge to the field immediately. The number of staff hired depends on the project size.
Consider this scenario: suppose you're a manager and you have 1 person assigned to do a task A. This person is working at 100% efficiency. Add another person to work on task A and you won't get the ideal 200% efficiency. You'll instead get a total efficiency of less than 200%, so each member works less than 100%. Adding even more reduces the efficiency of each member even further. Now let’s say we have a task B independent from task A and no one is assigned to task B. With our 2nd idle worker, we assign him to task B instead of A, giving more efficiency per member.
The scenario applies to the reports system. From the data gathered in the feedback thread, most voters responded that their reports were accepted in 1-3 days. That's faster than before where reports would take sometimes a week to get handed, but what if we have multiple players make a report against 1 player? Let's say 3 players each make a ban report against a player for hacking. 1 of those reports will get accepted but the other 2 aren't opened. A couple days later, they stay in the system and get closed because the first one was open. This results in a few minutes lost per report and this loss of efficiency builds up as more reports get processed. The fix here would be to automatically close any similar reports once one gets accepted unless the others are reporting a higher severity offense or are of completely different categories (e.g. bans and mutes).
For these reasons, we don't have 9 developers working on 1 field and why CubeCraft hires 3 different types of developers. Depending on the project size, it's better to have just a couple (1-3) than to have 4-5+ developers on the same thing. Additionally, each developer focuses on a different field. For example, one focuses on debugging, one on the anticheat, and another on web development.
In last month's thread, we briefly went over how the server was doing in terms of marketing. It looks like this month turned that around when this month's sale marked everything down by 50% for a week, encouraging many people to buy ranks on the server. So why did people buy during the sale and who are our buyers?
Considering most of the playerbase are kids or teens (some adults), not many make their own money yet. Unless they have a job, they're making nothing and thus cannot afford the rank on their own. They have to ask their parents to buy for them. Children are targeted for money making but the parents are the ones who ultimately make the purchase. This depends on a few factors, including but not limited to: income and willingness. It's not just the costs of the rank itself but also the other costs of the rank itself. Suppose we have a diamond rank worth $70 USD normally. It's not just $70 that the buyer has to pay -- it's also what he could've alternatively gotten with that $70 USD.
Now, why was the sale profitable? Depending on how many ranks were sold outside the sale, lowering the price can either be profitable or not. Let's say the server sold 20 per week, each priced at $30 USD. In this case, they made $600 USD for that week as total revenue. Let's now have the same scenario but have the 50% Easter sale come into play. Now we see 200 ranks sold and each rank priced at $15 USD. The server made $3000 USD when the sale comes in, bringing in much more revenue than it did before. It's up to the server to find the optimal price to sell their ranks at based on their data. Was it really a scam for people who bought ranks outside a sale? No; they had the willingness to buy that rank at full price but more people have the willingness to pay at a cheaper price.
Considering most of the playerbase are kids or teens (some adults), not many make their own money yet. Unless they have a job, they're making nothing and thus cannot afford the rank on their own. They have to ask their parents to buy for them. Children are targeted for money making but the parents are the ones who ultimately make the purchase. This depends on a few factors, including but not limited to: income and willingness. It's not just the costs of the rank itself but also the other costs of the rank itself. Suppose we have a diamond rank worth $70 USD normally. It's not just $70 that the buyer has to pay -- it's also what he could've alternatively gotten with that $70 USD.
Now, why was the sale profitable? Depending on how many ranks were sold outside the sale, lowering the price can either be profitable or not. Let's say the server sold 20 per week, each priced at $30 USD. In this case, they made $600 USD for that week as total revenue. Let's now have the same scenario but have the 50% Easter sale come into play. Now we see 200 ranks sold and each rank priced at $15 USD. The server made $3000 USD when the sale comes in, bringing in much more revenue than it did before. It's up to the server to find the optimal price to sell their ranks at based on their data. Was it really a scam for people who bought ranks outside a sale? No; they had the willingness to buy that rank at full price but more people have the willingness to pay at a cheaper price.
You've played a lot of games and noticed some major bugs pop up on the server. Let's look at a few notable bugs/exploits players have used on the server:
-Blockwars: Getting to the other side before combat.
-Minerware: sometimes you cannot build snow golems or you craft a crafting table but you don't pass that microgame. It's also possible to place blocks outside the arena.
-UHC: Ore clusters in specific locations.
No game should ever be won just because of exploiting or cheating. Even some of the major game-breaking bugs above can be fixed with a few things.
-Minerware: Notice that when you place blocks on the platform that they're all reset. Given that placed logs outside the arena are kept, this means that the game does not check that area. A solution would be to also affect the map borders such that those blocks get removed too. Alternatively, place a very tall wall of barrier blocks at the border during any microgame that requires or allows the player to place blocks.
-Blockwars: Same as minerware. A workaround would be to place a very tall, wide wall of bedrock to prevent players from building above or around the wall.
-UHC: A lot of people petitioned to just have vanilla UHC where ore generation relies on vanilla mechanics. Part of UHC is to encourage a dynamic world where locations should not be memorized.
The problem here is that bugs aren’t fixed right away. Even with a rule, people will still break it. As with hacking and Sentinel, implementation needs to go with the rule. Without that, how effective is it? Weak on its own, isn’t it?
-Blockwars: Getting to the other side before combat.
-Minerware: sometimes you cannot build snow golems or you craft a crafting table but you don't pass that microgame. It's also possible to place blocks outside the arena.
-UHC: Ore clusters in specific locations.
No game should ever be won just because of exploiting or cheating. Even some of the major game-breaking bugs above can be fixed with a few things.
-Minerware: Notice that when you place blocks on the platform that they're all reset. Given that placed logs outside the arena are kept, this means that the game does not check that area. A solution would be to also affect the map borders such that those blocks get removed too. Alternatively, place a very tall wall of barrier blocks at the border during any microgame that requires or allows the player to place blocks.
-Blockwars: Same as minerware. A workaround would be to place a very tall, wide wall of bedrock to prevent players from building above or around the wall.
-UHC: A lot of people petitioned to just have vanilla UHC where ore generation relies on vanilla mechanics. Part of UHC is to encourage a dynamic world where locations should not be memorized.
The problem here is that bugs aren’t fixed right away. Even with a rule, people will still break it. As with hacking and Sentinel, implementation needs to go with the rule. Without that, how effective is it? Weak on its own, isn’t it?
In my social experiment conducted weeks ago, a lot of people clearly showed that they do not like it when people post ban/mute requests. Even when they attempt to log in (ban) or chat (mute) and are given instructions as to where to appeal, people still create accounts and complain. While there's an official FAQ, it's implied from their actions that people don't read where to go. There's also no link to get the rules in-game unless one types in /rules. This command isn't shown at all.
We have a few workarounds for this issue:
1. Sticky posts in profile. For staff, this can come in handy where people often come in and barrage them with ban/mute requests. A member can write what they want pinned on their wall so that it always shows before other posts do and show as their "most recent post." These can be unpinned at any time. For example, a staff can write a post showing where to appeal and where to find the FAQ. This should theoretically reduce the number of requests people make if they read the post first.
2. Helpful links when a player logs in. The player should get the rules and FAQ links shown in the chat window (under "welcome to CubeCraft games") when they log on to the server. These shouldn't show when the player is moving from lobby to lobby however. An extra feature would be to show this only for the player's first few levels (10-20?) before they disappear or can be toggled off.
We have a few workarounds for this issue:
1. Sticky posts in profile. For staff, this can come in handy where people often come in and barrage them with ban/mute requests. A member can write what they want pinned on their wall so that it always shows before other posts do and show as their "most recent post." These can be unpinned at any time. For example, a staff can write a post showing where to appeal and where to find the FAQ. This should theoretically reduce the number of requests people make if they read the post first.
2. Helpful links when a player logs in. The player should get the rules and FAQ links shown in the chat window (under "welcome to CubeCraft games") when they log on to the server. These shouldn't show when the player is moving from lobby to lobby however. An extra feature would be to show this only for the player's first few levels (10-20?) before they disappear or can be toggled off.
From the data gathered a couple days ago, many voters agreed that the mod should be banned. You can find this thread here:
https://www.cubecraft.net/threads/damage-indicators-ban-or-keep-also-a-feedback-thread.188286/
This is probably one of the most questionable mods on this server. On paper, it gives no advantage because it shows user HP. In practice, it gives the user information that cannot be obtained without that mod. Sun Tzu said this in The Art of War:
Even @Daniel_H212 noted that the mod acts like ESP when it shows the amount of damage taken or amount healed through walls.
From this, information is roughly half of the battle. Why do you run when you're low on HP? Why do you cleanup players who have recently finished a fight? All of this is based on your decision-making and the given information. In the second example, you're cleaning them up knowing that they don't have much time to heal up completely. This is once again based on the situation.
A solution to this mod is to either block it completely server-wide (spoof healthtags to show 1HP or 20HP regardless) or enable it so every player has access to it. Banning it only isn't a definite solution -- as we've seen with prohibiting hacked clients, people will still get on the server and use illegal modifications. The server-side implementation should go with the rules.
https://www.cubecraft.net/threads/damage-indicators-ban-or-keep-also-a-feedback-thread.188286/
This is probably one of the most questionable mods on this server. On paper, it gives no advantage because it shows user HP. In practice, it gives the user information that cannot be obtained without that mod. Sun Tzu said this in The Art of War:
Even @Daniel_H212 noted that the mod acts like ESP when it shows the amount of damage taken or amount healed through walls.
From this, information is roughly half of the battle. Why do you run when you're low on HP? Why do you cleanup players who have recently finished a fight? All of this is based on your decision-making and the given information. In the second example, you're cleaning them up knowing that they don't have much time to heal up completely. This is once again based on the situation.
A solution to this mod is to either block it completely server-wide (spoof healthtags to show 1HP or 20HP regardless) or enable it so every player has access to it. Banning it only isn't a definite solution -- as we've seen with prohibiting hacked clients, people will still get on the server and use illegal modifications. The server-side implementation should go with the rules.
Conclusion
Things this month have improved since last month. So far we've had a better report system and possibly more server revenue from the Easter sale, but there's still more work to be done. Let's see how well the server can do for the next month.
Feel free to post other concerns/issues for next month’s recap.
Last edited:
