learn existing is probably good, but its current implementation is very bad

[Lotion]

I like learn, I'm glad it exists.

Right now it tracks your last four learns and allows you to learn as long you haven't learned four times within the past 166 hours (and also haven't learned the same skill twice). This means players are currently heavily incentivized to login at the same time every week to manually type a command four times into their telnet client and then possibly immediately logout. Forcing this sort of arbitrary timer on players can encourage unhealthy behavior and therefore is bad. It is bad to design mechanisms in games that encourage unhealthy behavior irregardless of whether or not the intent was to design a game system in a malicious and predatory manner. In this case I believe the design was added fully in good faith and was designed neither to be malicious nor predatory.

Thankfully, there is a good and easy to understand solution to this problem: have the learn time reset happen for every player at the same time. In my opinion the best time to choose for this would be 11:59pm on Saturday because a large majority of players live in a culture where Sunday is considered the beginning of the week.

Such a modified system would greatly reduce the burden on the player from "I must login at this specific time on this specific day every seven days or else I'm going to get less free gainz." to "As long as I type learn four times every week I won't lose out."


If you do not understand feel free to ask questions in good faith. A lot of people in Discord found this idea confusing.

[Lizzie]

Actually, it incentivizes me to log in during the middle of a Saturday - which is something I normally wouldn't do. And since I'm already logged in, I might as well play for an hour.

I'd say that's a win-win for me, and a win-win for the logged-in player count.

[helix]

I disagree. The way I see it as a programmer, this is probably by far the easiest solution to code.

I'll give you an example of why:

Having a variable present on a character for when the last time the command was used is fairly easy. The skill doesn't check any higher game systems when the command is typed, it simply tests whether or not the max number of uses has been reached within the last 166 hours and whether or not skills have been learned more than once. That's also an easy test, and only runs when the command is run, and uses a simple structure in C that is very efficient.

Having a universal timer means that some type of scheduler must be implemented - i.e. a game system that holds all player_character objects that could potentially use the command (i.e. an array, which takes up memory, or better yet, a pointer array, which takes less). The scheduler must then have methods for subscribing and unsubscribing to the scheduler. A scheduler in this case would be implemented because you don't want this running on the main game loop, or it will fire with every 'tick' of the game.

Adding and subscribing to the scheduler are necessary because as player character objects are created or die, they need to be removed from the scheduler to manage the array size.

The scheduler then sits in memory, doing nothing, for a week. Then it fires.

That is bad design.

Nothing is ever done in a program without someone (or something) telling the program to do something. Things done 'automatically' have a subsystem dedicated to making that happen. In this implementation, the check can be performed ad-hoc (i.e. at will) whenever the player decides to check learn, and doesn't have to communicate with anything else in the game, it only references itself. From an objected oriented design paradigm, that's more efficient in both cpu and memory, as well as ease of implementation.

[Dresan]

Right now it tracks your last four learns and allows you to learn as long you haven't learned four times within the past 166 hours (and also haven't learned the same skill twice).

This is feels like a nice feature, the skills most people are using learn don't ever increase unless you outright cheat or put yourself in mortal danger.

I agree with Lizzie here, I don't think its an issue and its a win-win for the game and players. If anything though wisdom stat should play a role in the learn feature. An indicator at login or a command of when you can expect learn to be available would be helpful, similar how we get one for karma.

On a side tangent, i feel the skill increase '+' notifier seems to have a similar effect of getting me to log on for an hour or two early in the morning. I would recommend staff decrease this to reset on a 4 hour interval, which is already far beyond what skills increase at especially after 'alt' stat bonuses. It will both encourage login, while decreasing skill training per session since most people will prefer to wait for '+' reset.

[Lotion]

Actually, it incentivizes me to log in during the middle of a Saturday - which is something I normally wouldn't do. And since I'm already logged in, I might as well play for an hour.

I'd say that's a win-win for me, and a win-win for the logged-in player count.

Having a timer on my phone to remind me to login, type learn four times, and then logout does not help logged-in player count.

[Lotion]

I disagree. The way I see it as a programmer, this is probably by far the easiest solution to code.

I'll give you an example of why:

Having a variable present on a character for when the last time the command was used is fairly easy. The skill doesn't check any higher game systems when the command is typed, it simply tests whether or not the max number of uses has been reached within the last 166 hours and whether or not skills have been learned more than once. That's also an easy test, and only runs when the command is run, and uses a simple structure in C that is very efficient.

Having a universal timer means that some type of scheduler must be implemented - i.e. a game system that holds all player_character objects that could potentially use the command (i.e. an array, which takes up memory, or better yet, a pointer array, which takes less). The scheduler must then have methods for subscribing and unsubscribing to the scheduler. A scheduler in this case would be implemented because you don't want this running on the main game loop, or it will fire with every 'tick' of the game.

Adding and subscribing to the scheduler are necessary because as player character objects are created or die, they need to be removed from the scheduler to manage the array size.

The scheduler then sits in memory, doing nothing, for a week. Then it fires.

That is bad design.

Nothing is ever done in a program without someone (or something) telling the program to do something. Things done 'automatically' have a subsystem dedicated to making that happen. In this implementation, the check can be performed ad-hoc (i.e. at will) whenever the player decides to check learn, and doesn't have to communicate with anything else in the game, it only references itself. From an objected oriented design paradigm, that's more efficient in both cpu and memory, as well as ease of implementation.

It's true that they could implement their own scheduler from scratch, but I think it's more likely for a successful implementation of this to use cron.

[eska]

I disagree. The way I see it as a programmer, this is probably by far the easiest solution to code.

I'll give you an example of why:

Having a variable present on a character for when the last time the command was used is fairly easy. The skill doesn't check any higher game systems when the command is typed, it simply tests whether or not the max number of uses has been reached within the last 166 hours and whether or not skills have been learned more than once. That's also an easy test, and only runs when the command is run, and uses a simple structure in C that is very efficient.

Having a universal timer means that some type of scheduler must be implemented - i.e. a game system that holds all player_character objects that could potentially use the command (i.e. an array, which takes up memory, or better yet, a pointer array, which takes less). The scheduler must then have methods for subscribing and unsubscribing to the scheduler. A scheduler in this case would be implemented because you don't want this running on the main game loop, or it will fire with every 'tick' of the game.

Adding and subscribing to the scheduler are necessary because as player character objects are created or die, they need to be removed from the scheduler to manage the array size.

The scheduler then sits in memory, doing nothing, for a week. Then it fires.

That is bad design.

Nothing is ever done in a program without someone (or something) telling the program to do something. Things done 'automatically' have a subsystem dedicated to making that happen. In this implementation, the check can be performed ad-hoc (i.e. at will) whenever the player decides to check learn, and doesn't have to communicate with anything else in the game, it only references itself. From an objected oriented design paradigm, that's more efficient in both cpu and memory, as well as ease of implementation.

As a designer I can tell that there is always an easier solution to customer needs.
All we need to do is to hold the count of learn used. Then allow the user to use the command until the counter reaches to 4.
Write a simple task that sets the counts of all users to 0. Set the timer of the task to whenever you want. And we are good.

[Riev]

I went to an interview last week, and the manager had something real poignant to say, so I will share it here:



If you gave some of these people a suitcase with a million dollars in it, they'd complain that its too heavy.

[Roon]

Having a timer on my phone to remind me to login, type learn four times, and then logout does not help logged-in player count.

Seems like overthinking it. Is it really that important to get your learns in as soon as it's mechanically possible? In some of these discussions about learn, it seems like people are afraid of potentially losing a few hours of efficiency if they don't input the command the moment they can. We're talking about a feature that lets you gain about four points per month in just four different skills. It's so miniscule that even skipping a day each week will have no measurable impact on your character's coded progress.

Realistically, skills that you can only raise via learn will never get good. Even after a full year of progress this way, you'll have gone from novice to probably low advanced. That's a whole year of fully optimized learn usage. It would take like a year and a half of that to master a skill. Conversely, if you can raise a skill through use and are just utilizing learn to speed it up a little, learn represents such a tiny fraction of your general progress that it doesn't matter if you're using it every 166, 180 or 200 hours.

[Usiku]

The concept of trying to min/max the 4pts a week from the learn skill is making me sad, and really undermines the reason why I wanted something like this in the first place. This is really just a tool to take the edge off for lower play time players so they can choose to RP over grind and still see at least a modicum of coded progress. That was the intent.

[HazelHomewrecker]

This is really just a tool to take the edge off for lower play time players so they can choose to RP over grind and still see at least a modicum of coded progress. That was the intent.

That's how I've been treating it. From my understanding, it's not even a BIG bonus. Like.. what, + 1 to the skill per time it's used? Hardly something to min-max, it's insane to me that it's being considered like that when the intention of its release has been obvious this whole time. I use it when I remember to, I'm certainly not counting down the seconds.

[Tailong]

Can't you just remember the day and time you last used the 'learn' command and do it again the follow week? That's what I do and go on about my day.

Simplest solution with zero code or programming.

[Kavrick]

I'm a notorious nit-picker and this seems a bit much even to me. The new learn system is really cool and lets people who focus on roleplay still get some gains in some skills they might not otherwise use. This is a brand new mechanic and it'll probably get tweaked, saying that the current implementation is 'very bad' is just unnecessarily harsh in my opinion.

[CirclelessBard]

I am going to lock this thread, and explain the moderation team's position on constructive critique of the game and the type of discussion we want to foster.

What we do not want, ever, is disparagement of the staff team's good-faith efforts to improve the game. Calling a system "very bad" right out of the gate is insulting. It creates unnecessary tension that colors the rest of the conversation and risks making it more combative.

It is fine - expected, even - that players will not like specific systems or find them not to their taste. It is important to separate that personal, subjective opinion from implying that something is objectively bad.

We are trying to foster a positive and constructive culture in the community. Please bear that in mind when posting suggestions or replying to suggestions and adjust your tone appropriately. This falls under Rule 1.