Active Player Pool System

[Bue]

I'm experimenting with some ideas to improve the social aspect of a private server.

Particularly with small servers and centralized population versus large servers and sparse population; for example, on small servers, active players tend to pool around the main city, while on large servers, AFK, autotrade, and autobot makes active players less distinguishable, also players tend to 'get away from the crowd.'

The idea is very simple; allow players to provide some 'presence' as well as providing information about other's 'presence.' Furthermore, players can decide how much 'presence' they want to show; for example, if you want to party up for a dungeon, then let other active players know that.

So the resulting idea is the 'active player pool system.' Since players on private servers often refresh and respawn at some location frequently, players can also opt-in the APP system for free supplies, such as scrolls, potions, and other power-ups.

Upon opt-in, the NPC will display information about other active players (either in chat window or NPC dialog) ordered relative to the player's level (or by pvp rating, hueheu). The player may also opt-in for other things like searching for party or guild, which will add them to a separate pool.

Moreover, the system allows GMs to gauge the active server population and analyse the information to see what kind of events to throw, hell, you can even throw in the support system in it as well.

Finally, the APP system is self-maintained, the system logs in the time the player previously opt-in and deleted APP entries every X minutes / hours, depending on how reliable you want the system to be. In addition, the system removes entries when players log out.

Other 'presence' solutions 1) announcement, 2) @main chat, and 3) drama are somewhat lacking.

So gentleman, and ladies, what do you think? (Particularly that british fellow.)

TL;DR: Players can frequently opt-in the active player pool system for free supplies (limited only to the player), as well as maintaining presence and staying inform of other players (relative to the player's statistics) and activities. APP system will reset the active status of the player depending on some time period.

[Axiom]

Sounds like too much trouble for a simple fix. Shouting out over at @main or a simple /b ought to catch the attention of anyone active. At least, as far as running activities is concerned. Now, for studying how many people are active in contrast to AFKs, vends, etc, it may be useful. Personally, I can get accurate enough estimates over @who3 and @users though but that's just me.

[Bue]

It is more complicated than a simple @main.

It is the accessibility of information at the right time at the right place; safe location, resupplied, and ready to go.

Pretty much like how google tailors your search results and ads based on your search history, except in this case, the information is optional and mutually beneficial.

The basic implementation is very simple since it is information based, but you can add in complicated features that can expand on the idea of moving information between players and other social features.

[Axiom]

Giving players the option of opting in or not would yield inaccurate data, wouldn't it?

[Bue]

You need to opt-in for the supplies, otherwise the system is broken. lol

It is very discrete; player opt-in for supplies, system handles players additional information (almost like advertising), and players can also choose to use the system.

Information can range from trading to recruitment to anything.

For example, on my server, when you opt-in: you'll get scrolls, potions, and field items that increase your survivability; since I practically made the entire server a living death trap except certain areas, strict economy, and sparse resources. Other players within the area will be displayed and ordered by level and pvp rating.

[Axiom]

Sorry if I was vague, but my concern with using such a system to monitor activity is not every active account may choose to opt-in. There can be many causes for that, ranging from new players not aware of the system or old ones who simply no longer fiind any benefit to it. Given these factors, the system is prone to yielding an active count smaller than it may actually be. As far as this being a tool for collecting server data, there are simpler ways to get more reliable data. 

Now as far as creating a pool or queue for players joining parties and active events go, I'd say this is a great idea.

[Bue]

In this case, you've a very limited imagination.

New players won't be aware of a system that hands out information and supplies, and may possibly be placed right next to the healer and warper? Or the supplies and information cannot change to match the statistics of the current player?

This system is always beneficial and provides plenty of opportunities given the information that can be harness. Even if the system doesn't hand out free supplies, the idea is that you can still use it to advertise your guild, find a party, or trade something.

For example, if you're guild-less, then you may go into the APP and opt for the guild recruitment pool. A guild leader looking to recruit can access the APP and contact you while you're active, furthermore, why not throw in a function that allows the guild recruit to warp to the location of the guild leader?

Also, this is very important to note, while in-game the active player pool system is not name the active player pool system. You can mask it under the label Kafra Corp. It's all about imagination.

[Axiom]

Lack of imagination indeed. I apologize, but let's act grown-up here and skip the pot shots.

If the APP were positioned as a multifunctional hub NPC of sorts, then it may just work. Kafra may be risky as bots are bound to access it as well.

[Bue]

Given the capability of the item database files, which allows storage, trade, and sell restriction along with stack limit and among other scripting possibilities; bots cannot benefit anymore from the supplies than players can with both supplies and information.

Bots can participate in the active player pool all they want; makes my job much easier if you know what I mean.

At this point, It'll be more interesting if you can come up with a better solution...

Afterall, you must be doing something with Chu! And you need to forgive me, if I sound rude, been coming up with plenty of ideas recently.

[Axiom]

Oh no, my concern regarding the bots isn't so much about them getting the free items. There are easy workarounds to that. It's more along the lines of making sure whether or not the APP can tell between human or bot, at least for the APP NPCs bots are likely to use (warper, stirage and healer types?). Mistaking bots for humans can throw off statistics unless we can differentiate.

As far as stat tracking goes, I think adding a log on the warper (if there is one available) is the best place for it. People use it a lot, and the number of unique uses it gets hourly should show you how much traffic you get in your server throughout the day and when it's busiest. Adding a sort of captcha system in (I've seen some servers with the system before) to prevent bot use can also take bots out of the computation of statistics (and prevent them from using the NPC, natch).

The more social implications of it (queueing, recruitment, etc) is conceptually sound. It's just a matter of integrating it properly in-game.

[Bue]

Oh no, my concern regarding the bots isn't so much about them getting the free items. There are easy workarounds to that. It's more along the lines of making sure whether or not the APP can tell between human or bot, at least for the APP NPCs bots are likely to use (warper, stirage and healer types?). Mistaking bots for humans can throw off statistics unless we can differentiate.

As far as stat tracking goes, I think adding a log on the warper (if there is one available) is the best place for it. People use it a lot, and the number of unique uses it gets hourly should show you how much traffic you get in your server throughout the day and when it's busiest. Adding a sort of captcha system in (I've seen some servers with the system before) to prevent bot use can also take bots out of the computation of statistics (and prevent them from using the NPC, natch).

The more social implications of it (queueing, recruitment, etc) is conceptually sound. It's just a matter of integrating it properly in-game.

The only statistic that the APP system track is the # of active players.

For example, the APP system pushes an active player onto the SQL table 'active_player' or some data structure like an array, which stores only it's character / account ID. From this, you can obtain information across other SQL tables or from the scripting engine; you can even attach the player onto scripts without the player even clicking on a NPC.

For example, say you've an array of account IDs, then you can use attachrid <account ID> and run a script with that player attached; this allows GMs to either warp all active players to a particular location or send out messages only to the players in the APP system; in fact you can built some exclusive messaging systems this way, but would probably be very inefficient.

Spoiler

*attachrid(<account ID>)
*detachrid;

These commands allow the manipulation of the script's currently attached player.
While attachrid allows attaching of a different player by using it's account id
for the parameter rid, detachrid makes the following commands run, as if the
script was never invoked by a player.

In case, that the player cannot be attached, such as, when the player went
offline in the mean time, attachrid returns 0, otherwise 1.

[close]

Spoiler

*dispbottom "<message>";

This command will send the given message into the invoking character's chat
window.

[close]

Spoiler

OnWhisperGlobal:

[close]

The statistic tracking methods you're describing is quantitative and less discrete, since the number of active players is inferred, which can be inaccurate given the wrong correlation equations. Other quantitative methods like the ones used in old warping scripts uses the idea of displaying the # of players on a specific map as the player invoke the menu, but if you look at the complexity of the system, it is actually very inefficient because every time you call the menu O(M) * Frequency * Players instructions will run; M is number of maps. This idea applies to all quantitative tracking methods.

With the APP system, players opt-in optionally every other time period, this way you've O(1) * CONSTANT * Players; and you know for sure that the player is active; if there is any doubt, you can even run some scripts to double check since you've the account ID.

Furthermore, you never want to impose restrictive systems like captcha if you can avoided it. If you do it to something so trivial, it practically screams "I am very incompetent!" It would be interesting to see what happens if bots opt-in regularly on the APP system, whether the system can be self-policing would be very interesting.

[Bue]

Since I've gotten more ideas out of our discussion than I initially thought off, I don't mind developing a basic version of the APP system for you to test and used on your server.

Although, at the current standpoint, everything is still conceptual, whether or not it will actually work requires some testing.

[Axiom]

I'd be happy to test whatever you come up with. Mind, my server only tops at 20-30 on active hours though.

[Bue]

I'd be happy to test whatever you come up with. Mind, my server only tops at 20-30 on active hours though.

Here is what I can conclude from our discussion:
1. Active Player Pool System
- Complementary medium for social interaction; active player, party, and guild pooling.
- Allows Game Masters to easily manage all active players via scripting and communication, specified.

2. Game Relay Chat System
- Third mode of communication through in-game chat window.
- Practical applications include guild-alliance chat and GM support chat, specified.

The difficulty now is making these system as efficient, user-friend, and intuitive as possible. Getting players to initially try out the system requires some incentive though; and whether or not they continue to use the system would determine whether the idea is a bust or not.

I've work and school, so getting these systems scripted and tested might take some time. >.> Doesn't seem like anyone else is interested though. = =

[Triper]

Dunno why, it can be an easy and simple way to check stuff instead of using the usual ways.
I just dunno if it will be enough to be better then the RO map+where players are system. It's a really good system for checks but mixed with this it can even be a better option! It could be like an "upgrade" =P