trollson

Ohh congrats on the success Mr Mind! I seriously look forward to reading your paper.

Link to topic discussing map interactions in my sig.

To acquire a complete decrypted set of strings somebody would have to play through the quest, at which point they can just publish a quest walk-through as already happens. But even if you had a decrypted string table - what information does it give you? You don't know the context in which the string would appear in the game - where? from whom? or in what situation? Variable or non-translatable elements (or proper names[1]) wouldn't appear in the strings in the string table - but be included in the server message as substitution tokens (cf. printf format string). A separate encryption seed would be used for each string. I'd use a RNG which generates an uncorrelated bit stream, and XOR the stream with the string to encrypt and decrypt. This is a low cost operation (negligible compared to the other operations that the client has to do). The encrypted string is then a series of uncorrelated bits, which does not contain any information other than its length (which can be obscurated by padding). [1] Proper names sent as substitution tokens could still be translated separately using another translation map - in fact, if this was intended, then in-game names (of items, NPCs, places, etc) could be sent as an index rather than a string.

As bad or worse as storing the info in plain text (ignoring the update problem which was one argument against client side texts). The client is open source, so everyone can get the source code. From there, it's very easy to modify the code so that it gives you the seeds If your client has received the seed to decrypt the string, then you can legitimately see the decoded text anyway. The string table would be part of the downloadable game content, to permit updates and new translations. Since it is periodically updated anyway, the encryption seeds would only have a valid lifetime of that release of the string table. You need to decide what weight you give to data security, verses supporting an international player community.

Encrypt your client-side string table. Instead of the server sending the string, it sends the string id, decrypt key or seed, and field text for insertion.

...except that statement has it the wrong way around, as I explained later in that thread.

Why not just let 'experience' harvests be mini-event free? Initially thought that would be interesting (even the absolute harvest limit). However, if I was a farmer I'd just build ten characters in place of one, and cycle through them (still only needing one logged in at a time...). An MMORPG really needs to be designed from scratch to avoid the problem of farmers -- and that mainly means no character advancement through grind (in wealth or experience) which the farmers can exploit.

Why not just modify the price for any sigil by how many the character already has? Say that it becomes more difficult to "teach" a sigil as you learn more. This could also give a reason to have a "unlearn" option. Although, I think that Entropy was intending to replace the sigil magic system with separate spells. That would be a shame, as the sigil could be developed to give a very flexible and imaginative system...

Most relevant previous discussion I recall would be the "Duel feature implementation" topic. For the system to support duelling, I would favour reusing the "trade" window. This would allow the players to accept a duel, as well as placing a stake on the outcome (which would be removed to a "safe place" if the challenge is accepted). Of course, fleeing would count as losing the fight.

Most items, if stored correctly, will last longer than we would care to account for; and I would presume that the storage company know how to do this. Flowers etc intended for alchemical use could be dried and stored for a long time. It is only some food stuffs that would be subject to decay (especially raw meat), and it would be simpler to make these non-storable. However, who is to say that the apple you deposited on C1 is the same apple to withdraw on C2? You could assume that storage worked more like a bank, since there are no unique items. On the other hand, if this was implemented, it would have to be based on player-time, not game time, to allow for occasional players. Each storage slot as a time-stamp for last-access, and when accessed the time difference is used in a half-life calculation and applied to the quantity in storage, before any transaction. Apply this as a binomial random number rather than a flat percentage avoids a no-risk situation from frequent access.

Depleteable resources are good iff implemented fairly. I've voted "yes", but implementation needs careful thought. Consider using a "depletion level" rather than fixed quotas for each resource. Each resource site has a "depletion level" and "timestamp". The "depletion level" adds to the difficulty of harvesting that resource, so harvest yields per hour decrease as the depletion gets worse, but never actually run out. Storing a "timestamp" allows the resource to be restocked when harvest attempts are made, rather than having a background task update unvisited resources. Illustrated through the fine art of pseudo code: on harvest attempt: if current time > timestamp decrease depletion level (current time - timestamp) if depletion level decreased timestamp = current time + offset endif endif make harvest attempt (skill level vs resource level+depletion level) if harvest successful increase depletion level endif end harvest attempt You can then choose how the depletion level gets increased/decreases (I'd suggest an exponential decay as the decrease, with a half-life dependant on the resource type). The time "offset" is an optimisation to avoid calling decrease depletion too often. With this approach, for any group of harvesters around a single resource there is a point at which the rate of depletion is balanced by the rate of recovery. For a single low level harvester, this could be a profitable level, but for a crowd around the lupines it would unprofitable. (This implementation costs two integers per resource.)

Firstly option: Books which can be bought from an NPC could be sold to that NPC to remove them from the game. Though this releases more gold into the economy. Second option: Books could be used as optional ingredients to related recipes, which, say, increase the change of producing an enhanced item. This would use up surplus books, raise their market price, and consequently reducing the number of new characters who read the book. There would be a marginal increase in the number of enhanced items, which would depend on modified applied for each book added to the recipe. Whether you want to separate books which can be bought, from books which can be added to a recipe would be a balancing decision. Buying books to increase your chance of making an enhanced item would then be another gold sink to balance those being sold back to the NPCs. Not every item has an enhanced (or mod'able) form, but I've always thought that they should (mod'able leather pants!)...

That option was discussed when Augmented Armour was being designed, and rejected. Augmented Armour occupies a particular niche of cheap-and-disposable, strong-but-short-lived.

The summoning skill went into the creation of the stones, not the use of them, so no experience from "stoned" creatures! Conversely, directly summoning creatures, if their actions gave summoning experience, would mean summon-and-use could be a better source of experience than making stones. I guess that a perception bonus would apply for "stoned" creatures, though I think there should be some test-of-will if you use a stone to summon a creature that is too powerful for you to control...

Quick tuppence of thoughts: Let summoned creatures increase your perception range - you are aware of what your creatures can see - useful now we have limited perception and ranging. Limitations still apply however. Let experience earned by your summoned creatures go to your Summoning skill - previously suggested and rejected, but I still think its a viable option.

Items with a timer for their existance may be outside of the game design at the moment. However there is an interesting idea in this suggestion: An item representing a set number of a (non-stackable) item. For example, an item "Box of Pickaxes" representing 10 normal Pickaxes. Similar things have been suggested before, but here I think there is a feasible implementation: The "collection" item represents a set number of an item - no more, no less. The "collection" item can be used (consumed,opened) to generate the individual items, presumably into a bag at the characters feet. What it wouldn't support: Adding/removing single items from a collection - the collection has to be of the set number. Things which could be considered in future: Means for a character to generate a collection from a bag. There would have to be some costs involved. Encumbrance could be the total for the items in the collection, but this may vary (encumbrance is not just weight). Since the "useful" individual items are not accessible without "using" the collection and picking up the items from the resultant bag, it should not impact crisis management. However, if the "collection" item was a general concept applicable to all (non-collection) items, then if applied to non-stackable consumables it would result in changes in tactics. Such concerns could be mitigated by assigning greater encumbrance that the total of the parts - eg., a crate of potions would require additional padding and packaging which increases the weight. The value of collections for stackable items is dubious unless there is an encumbrance saving, and I presume that collections themselves would not be stackable.

Simplest point-in-polygon algorithm would be the ray cast one. From the point, "draw" a line in a given direction, and count the number of line-segments of the polygon it crosses. If this is an odd number then the point is within the polygon, otherwise it is outside. This works for convex and non-convex polygons, and does not depend on winding (for a flat plane at least). Determining the bounding box for the polygon gives an easy optimisation. Of course, you also will always use the same direction for the ray from the point, due north (+y) say, which simplifies the tests. For this application, we need not be overly concerned with boundary conditions (eg, the point lies on an edge or vertex). Pseudo code for ray cast algorithm (unchecked C-ish): (code example deleted due to bug) (while waiting for things to build...)

It would be bad if this meant that formula became "hard coded" in the client; the should be the opportunity for formula to be secret or variable (and the cyclopaedia need not be accurate or complete) However, possible as a client-side-only mechanism: Players could define "sets" of items as named macros, which can be listed/selected as part of the storage interface. The client can then send the requests for each item (or quantity of). This would be applicable to fighters (defining sets of equipment) as well as mixers. It would make mixing at storage much easier; but if that is an issue, I'd ban any mixing in range of storage (which has been done at certain sites in the past), or give better reasons to carry ingredients from storage to more advantageous mixing locations.

Inflicting damage to attributes other than health is not daft, but perfectly feasible in the game, and I think I've mentioned this in the past. It would make things a bit more interesting, as people would have to re-evaluate their strategies. Attributes and Skills already recover towards their permanent level at 1 point/minute (like health for that matter), and can be boosted (and thus recovered) using existing potions. However, EL would need to close the exploit where characters gain advantage from having lower-than-normal skills (eg, Arena access, combat experience); those would have to use the permanent value rather than the current. "Damage" to attributes and skills could come through other means; for example, if a skill failure cost 1 point, then it would impact relentless training and act as a leveller in the battle field -- a powerful fighter _could_ be overwhelmed (tired out) by waves of suicidal newbies... (involuntary skill use, eg defense, may have to be handled slightly differently though).

A set amount of experience already decreases in "value" as level increases, viewed relative to the amount required for the next level. In other words, that is the job of the experience level table. As an alternative, it would be interesting to only give xp for *failing* a task, and not for success, which I think has a stronger rational -- you may learn a lot making your first 100 leather helmets, but what more do you learn in making the next 70,000...? Experience on failure [1] should result in more lost ingredients (economic effect), more attempts at difficult tasks, and less mass production of low level items. Effectively, soft "level caps" will exist relative to the most difficult tasks available in any skill (except PvP combat...). This mechanism would also apply to combat experience, and could replace the secondary xp adjustment for relative levels. While it would make PK against weaker opponents a zero-experience activity, combat would not suffer the same "soft level cap" as other skills, as equally matched pairs would continue to earn experience. This suggests that something else would have to be added to the game to give the same opportunity for other skills. However, switching from experience-on-success to experience-on-failure would likely be unpopular. [1] Gain experience on normal failure and critical success, no experience gained on normal success or critical failures.

That information is probably more relevant to Entropy, who already know the quantities of items in the game -- a new item should not make another redundant, otherwise what was the point of adding it? Either parameters or processes would then be tweeked to add a balance.

The best use for platinum coins I think arose in the "Use For Platinum" thread: Platinum Coins are bought from the EL Shop for RL money. Certain NPCs sell/buy certain items not available elsewhere in game exclusively for platinum. No in-game route (ie, via NPCs) to convert between gold and platinum. This simplifies the EL Shop, and platinum coins become a commodity traded between players - which should establish a gold:platinum exchange rate which may vary over time. I would be tempted to extend this somewhat, and also have gold/silver/copper coins for different types of goods, to split up the economy into three (four) levels. Copper for the peasants, silver for the merchants and artisans, and gold for the nobles. The only exchange between these currencies is through NPC trades (or by value-add by players - buy ingredients for coppers, make item to sell for silver).

This could be interesting, but how would you gather the information? The server could log information from each trade between PCs, and between PCs and NPCs (separate process); recording figures each day. But this would miss out bag trades and trades which take more than one transaction, but that would probably be okay as while its good to have some information, its bad for the game if its too accurate or reliable. There would have to be a method of accounting for barter trades, or exchanges of multiple items; in which case determine the "value" for each item in the trade by converting each other item to its last-known gold value. In addition, there would have to be a way to distinguish gifts and extreme outliers; ignore any trade where an item is valued at +/- 3 SIGMA from its last known value. So during each transaction, for each item, add the number traded, the price-per-unit, and the price-per-unit-squared, to accumulators. At the end of the day (or other period) you then know the volume traded, the mean price, and the volatility in the price (the standard deviation, SIGMA). While this would give a "spot" value for the day, its probably better to use a rolling mean to determine the "current value" for barter trades, to reduce the effect of idle days; for example exotic items only trade infrequently, so there may be no data for them on most days.

See also: "Waquan"

Platinum pieces.