Over the last two years loot tracking and management in World of Warcraft has become steadily more involved. With the introduction of token items and a tiered, upgradable loot progression path the defacto standard of EQDKP has become increasingly inadequate. ZDKP is an attempt to fill it's shoes with a system built from the ground up with the aim of helping mere mortals track loot in the Burning Crusade.

Goals:
- Provide a format for writing configurable, flexible, and portable (between guilds/systems/etc) rulesets for WoW DKP/Attendance systems.
- Provide a database and web viewer that can display a wide variety of configurations and be extended by a third party (in a portable way that doesn't break the rest of the system) if their particular rule set is incompatible with the basic viewer
- Provide tools that can import and make use of the vast amount of information in the modded CTRaidtracker strings that the EQDKP import plugin carelessly throws away
- Provide robust error checking in the raid import stage to prevent common input errors, both basic (duplicate entries, looter not present at raid) and advanced (double dippers getting points for multiple timers in the same week). As well as automate many common import tasks (looking up upgrade prices, resolving token items, and obviously calculating DKP itself)
- Display all of this data in the context of the World of Warcraft Burning Crusade expansion (where most raid drops are token items and the days of single raid group guilds are numbered) and provide a way to use this data for other player management tasks.
- Open source fully self contained system that can be downloaded and installed on your guild's webserver, managed however you see fit.

How does it work
ZDKP relates the following information:
Groups of players who raid together
Raids that these groups go on
Events (bosses) completed on each raid
Exact attendance of each member
a 'DKP System' is a set of rules that maps raid attendance and drop data to point standings.
drops are charged to systems, raids credit systems.

Raid Importing
Raid information can be entered manually from a blank slate or from a base provided by an EQDKP modded CT Raidtracker string. (All data that ZDKP uses is fully backwards compatible with current EQDKP strings).

The RaidTracker import utility is being written to solve many of the annoying problems that plagued the EQDKP plugin and provide . The ZDKP importer is much better at figuring out exactly what dropped off what boss. This includes situations where items were not looted until after the raid started killing trash mobs, as well as token items that can be dropped off multiple bosses.

DKP Processing
The meat and potatoes of this system. The code that turns raids and drops into points. The alpha demo system is currently set up in a configuration common for raiding guilds this past year, a single 40 man group with multiple loose 20 man groups. There are two example DKP systems set up. One is a standard zero sum system, the other is a Non-zero sum system (do these have a name? my guild calls them pies, but I think that's just us). The example zero sum configuration uses fixed priced zero sum split into class specific/non-class specific sections, it is used for the 40 mans. The example non-zero sum sum is set up as a suicide system, where you receive a fixed point value per encounter and loose all points whenever you win a contested item.

These represent two configurable states of the two most common dkp frameworks, and will be two of (i think) three systems included in the default installation. Their [incomplete] feature sets so far are:

Basic Zero Sum
Pricing
- Fixed or variable (bidding systems)
- Automatically entry from a sharable item price/metadatabase.
- Automatic generation of item upgrade prices based on rules
Point Distribution
- Flat
- Attendance weighted
- Cap-able at item tier or dungeon level
Possible experimental features (If I find some time, or anyone is interested in helping)
+ Dynamic processing [which would allow things like]
-- DKP decay
-- Dynamic expansion/compression of the zero sum based on active/inactive players

Basic Non-Zero
Pricing
- Same as basic Zero Sum
- Several misc options frequently used in more informal systems (example: suicide)
Point Distribution
- Fixed or variable amount per raid/raid event (boss)
- Automatically generate from attendance (time based dkp)
- Fixed player adjustments

All systems include the ability to run multiple concurrent instances of themselves. If you want to do separate systems for each instance/tier or separate armor/non-armor or class specific vs non. You can also run multiple non-related systems with different configurations at the same time. (ex 1 common zero sum for the 25 mans, then multiple separate non-zero sums for each 10 man group. Or one fixed zero sum for a hardcore attendance required group, and one bidding zero sum for a more casual group) Between the two of these I believe most dkp systems in use today will be able find a proper configuration, and if not, with a bit of php knowledge your guild hacker can write your own to fit your exact needs one [and share it for fame and glory for your guild.]

(this third default system is an example of such a system)
ZDKP Crazy Insane Experimental System
An example of the what the power of a linked zero sum and attendance database can do to help solve age old dkp problems.

This system will be a weekly attendance weighted zero sum system designed for use by a single group with raid progression as a sole focus. It charges a fixed or variable price for items immediately, but defers point distribution until the instance timer resets. At this point it awards the dkp spent during the week as a function of the entire week's attendance.

If your attendance score for the week was 50% you would get 50% the points as someone with 100%. 'Attendance' in this case can be a value automatically calculated or estimated from actual attendance, a weighted score by officers, or some combination. This also allows penalties/bonuses to be awarded as attendance scores. Example: you could set it up so that there is a penalty for arriving late/leaving early. Overall this allows a much more even zero sum distribution (varies with actual effort/attendance, not with who was present at the moment of each boss kill) without breaking that sum for and penalties, rewards. and properly rewards players for raiding on wipe days.

General player management tools
While ZDKP can be used purely as DKP management software, and that is it's primary focus, it stores a ton of data that is useful for other things. These areas are among the less complete at the moment. The nexus for this information lies in the group portal pages. The group page is essentially a statistical subset of the whole system that shows only the info relevant to that group. Key features of the group portal will be a DKP leaderboard for that group's members, optional raid signup and raid bank sections, as well as news and raid statistics relevant to that group. Attendance can also be calculated separately by group so you can add trival/gimmick/optional raids to your system without messing up the serious business attendance charts.

Nifty group statistic example:
ZDKP is fully aware of all instance timers and so you can calculate which members of which groups are currently locked onto which timers based on currently entered raid information.

What I need help with
First and foremost, the current setup has been written with my own guild loosely in mind. Running a dkp/player management system for Goon Squad is a lot like running one for an entire server so I feel that I have covered a pretty wide base of interest. However, I am sure there are still things that you wish your dkp software did that this doesn't do yet. I'd like to know what those things are. So if you have a minute, browse through the alpha system, tell me what you like, what you don't like, what you think would make whatever it is you do with dkp software easier.

Perspectives I am particularly interested in:
1. Guild/group leaders/officers
2. DKP point enterers (on usability of the import utility)
3. Raiders (on general usability)

Secondly, I have not led a raid in several months and have a very short supply and limited variety of complete raidtracker strings. I am particularly interested in a string that contains a 4 Horseman kill (Raidtracker reports chest based looting slightly different than boss bodies) or any other unusual strings. Also, in general, am looking for specific feedback on how to streamline the string->raid functionality. I will post info for a limited access admin account at the end of this post if anyone is interested in testing out the raid import utility. I would love to get some feedback on that.

Thirdly, the group portal page is in an open review stage. What would you find helpful on such a page? DKP/Attendance leaderboards, signups, raid banks top the request list so far, is that list missing anything?

Relevant Links
ZDKP Alpha System
http://zdkp.zaphoyd.com/new/zdkp_mod.../view_news.php

ZDKP Alpha System EJ forum admin preview info
(to access the raid import page. the data in this system is not overly important, feel free to play around)
name: ejpreview
pass: flex

I can get you a Domo string I believe, which is another chest based string. It'd be mixed up with a Ragnaros string as well though since I wasn't entering dkp for that raid (I was helping another guild get their guy the rag drop for his thunderfury ^.^)

All in all I'm interested- especially since immortality's raid management suite has been abandoned by it's creator and has no shaman support for alliance raids (obviously a concern with the expansion) We're pretty desperate to get off EQDKP but we can't seem to find a reasonable way.

The website is a little rough- trying to figure out what you're displaying is difficult.

Officer view- Will color customization be an option? It's fairly important that I be able to match the dkp database to my websites scheme. I like that it can seem to track days or instances of raiding rather than simply per boss input.

DKP inputer view- can't find a way to input anything, so I can't really judge =) What I'd like/assume- a text box for basic cut/paste dumps out of CTRT. A way to go back and edit raids already put into the system- add/remove members and add/remove loot. A way to manually add in a raid with NO CTRT info (although it's usually a pita, sometimes it needs to be done). Regarding days/instances of loot- do the boss strings have to be entered in a block or can you enter them as you go? We update dkp from boss to boss, but would love to be able to track loot from day to day or instance to instance.

Raiders view- Looks fairly simple assuming you can edit out parts of it that you don't need/use (my guild has no class specific dkp as an example)

*edit missed login info- taking that now and going to look, will edit post shortly. Also PMing you the Domo String. I can get you a ton of strings from Naxx, but no 4hm.

As it happens I am writing a DKP solution called zsDKP which is obviously a much better name :-) It's basically the system I use for our current 40 man raiding re-written to addres the problems we have found to date. It is somewhat less ambitious than your proposal.

The most obivous difference is that my software is a Windows application and all DKP processing is done offline. There are two main reasons for this:

1) There is no reason i can think of why a php/MySQL + web server is particularly suitable for processing DKP (essentially adding up some numbers and dividing by 40). In fact it seems to make it considerably more difficult to develop, less powerful in many ways and AFACIT offers no actual benefits. Even the reporting requirements are trivial and easy to predict.

2) Lots of small to medium guilds either don't have or don't want the php/web skills and hosting required for something like eqDKP. Typically such guilds end up doing it in Excel and uploading the results (indeed this is the situation I was in that led me to write v1.0 of my software).

So zsDKP is a stand-alone windows application that anyone can setup and use (it doesn't even need a SQL database). After you process a raid it generates a bunch of static HTML pages which you then FTP to your website without any need for php/SQL. Example output from the current version can be seen a http://www.mathematicallysafe.com/dkp/ (the HTML is somewhat hacky and totally stolen from the Football results of the Guardian newspape here it's all getting re-written in the new version).

A few more features:

-- No in-game actions required you just need CT_RaidTracker installed, not even a cut and paste.

-- Based on the current version, Raid end -> Process -> Published is typically less than 2 mins.

-- Does basic fixed prices zero sum DKP with a limited number of options you can tweak as described below.

-- Upgrade prices including with auto-detection from raid history and a certain amount of configuration options in terms of how it all works.

-- Instance/tier caps (Optional)

-- Various decay models to prevent permanent wealth gaps. E.g. sliding time window, decay over time, possibly "double entry" roll forward DKP, etc. (Optional)

-- "WipeDKP" to incentivise learning encounters (DKP awarded for wiping while learning a boss is "borrowed" from future drops thus preserving zero sum and rewarding those contributing to progression the most).

-- Attendance tracking including bonus attendance credit for people running instances for which they are DKP capped and auto-detection for leechers signing up for farm content and "washing their hair" on progression nights.

-- zsDKP stores the raw data and all of the choices you make when processing raids. This means you can regenerate your entire raid history at any point including not only retrospective fixes but even price changes, changes to DKP policy, different decay models, etc. (This last but may be a really bad idea but there were times I really wanted to do it to date if only to allow a sort of "What-if" processing when we were having discussions about proposed changes to DKP prices and policy).

-- CSS based output HTML for easy implementation of your layout/colour scheme.

-- All text based storage so you can share the "database" and have multiple people do the number crunching.

-- .csv based import and export to allow arbitary one-off/custom alterations in Excel.

My overall aim is not to cover every single DKP model but to do something close to the EJ system (fixed price, zero sum, caps, upgrades) with a reasonable selection of basic options and customisation.

I am about half way through my re-write and expect to have it up and running about a month into TBC and well in time for my guild's 25 man raiding.

BTW I would also appreciate some test data from other guilds as well -- if you use the modded version of CTRT and can mail your saved variables file (they zip/rar very small) to fishslice at gmail dot com I would be very grateful.

Oh god, you couldn't pay me to upload new ftp data every time I want a change in the dkp page. o.o I enter data anywhere from 1-10 times a night, that's 1-10 alt tabs, rerunning of the data, and then ftping it back up... not to mention edits on the fly of miskeys and such (whoops that was an upgrade not full. My bad)

I'm also not keen on giving ftp access to a wider group of people than currently have it so they can uplaod the dkp, nor force them to download .exe files.

The advantage of web based processing is limited required software and limited extending of website root access.

As for the other guy, loot entering seems fairly basic and good to go. I didn't try changing anything obviously =)

You update your DKP during raids? To be honest that never occured to me that someone would do that and I am not even sure why you would let alone do it 10 times.

"The advantage of web based processing is limited required software and limited extending of website root access"

The entry cost of eqDKP (and php/mySQL in general) is the big argument against it in my view. Even if you know exactly what you are doing its complicated and error prone and installing a tiny windows application is trivial in comparison. Most raid guilds have a php/SQL type who is happy to faff about getting it all working but in my experience many more simply don't.

From a technology point of view it makes no sense either. It's like using a lathe to hammer in some nails.

I'm very interested in seeing how both of these systems turn out to be in the end. ZDKP looks the most interesting to me right now, as I do have very good web hosting for my guild. Any chance on it being released for others? or do you want it to be more developed beforehand?

The main advantages of serving dkp dynamically are that users can sort and search arbitrarily and multiple officers can easily and concurrently edit it. (also allows those on Mac OS X/Linux to use it).

It is quite common to update dkp dynamically as bosses are killed (reason being that every time you kill a boss the points standings change and many raiders like to keep track of this on the fly).

That said, my aim here is not to argue what is best, it is to ensure that when a guild makes that decision there is software that can make it happen.

As far as color and customization, the styling of the entire system is done in css. You can change it all by swapping the css file. This can be done globally or per user. ex (http://zdkp.zaphoyd.com/new/zdkp_mod...id=1&style=alt)

My goal is a reasonably feature complete and stable system by the time anyone starts raiding in TBC. I hope to have a [potentially stable] demo/beta downloadable for people to play with within a week or two . So yes, stay tuned.

SQL and DKP are exactly suited towards one another. For something relatively unnormalized, why you'd do DKP in SQL is screamingly obvious:

Transaction: Cenarion Boots dropped, Daksuo purchases, BossKill434535.
Relatives: PlayerAttending(x40+)ID, BossKill434535

(And forgive me, I spent five seconds coming up with two pseudo tables).

Now you can easily audit attendance: What? JimmyTheRogue wasn't there? DELETE FROM ATTENDERS JIMMYTHEROGUE, BOSSKILL434535.

Bubba *was* there? INSERT INTO ATTENDERS...

It wasn't Cenarion Boots that dropped, but Cenarion Shoulders? UPDATE INTO TRANSACTION...

Every time someone uses their credit card or writes a cheque, they are (essentially) adding a new line to an SQL database in their bank. It's quite a bit more complicated then that (proper SQL design is actually quite crazy - it's probably around 6 related lines), but the principle works. If you work somewhere where you handle "trouble tickets" or "incident reports" in a database... each of those fields you're filling in is going to be put into SQL.

And generating any number of reports is relatively trivial. Adjusting values for anything is also trivial - notice how the transaction there has no particular value associated with attendance and none associated with the cost of the boots. One change in the database - at any point - and all of a sudden, the entire system is ret-conned into correction. While it would be a little crazy, changing the system so you could have CBoots of one price before day X and another after is also possible.

That's the reason you do SQL. So you can make a change at any arbitrary point in your data without having to rewrite the entire beastie from scratch, and you can have any number of applications interact without needing to have any (or much) business logic.

Using PHP, if for some reason your ZDKP/EQDKP or *DKP overlords didn't foresee a reason to ever allow you to change, let's say, the name of an item once you priced it (Oops, "Ceneerian Boots" is in the database and people have bought it!"), phpMyAdmin is a common and relatively easy piece of software that a nonexpert would certainly take a lot of time to get the job done with, but could get it done with no understanding of SQL. That's really absurd when you think about it - a nontechnical user making a modification to, essentially, a piece of software (from their perspective) and it working.

Anyway, a bit of a derail, but hopefully in the discussion of DKP software, the "Oh, so that's what SQL is doing for us..." will be useful.

Sorry for my thread hijacking here.. but skimming through I just got a ... well let's call it an idea.

I've recently come to the information that the in-game API function "PlayMusic" is actually able to connect to a ice/shout/xyz-cast live audio stream on the net. What happens if you do give that function an URL is that the game connects for you to this stream and plays it back. That's cool.

Buuuut, if you're a raidleader and not really interested in background music, you could feed it "fake" URLs to your server and in fact update your guilds DKP site "in real time". Simply encode all data in the URL and that's what the server gets. You can't pull any data into the game, but this way, you could live update. This should basically also work with any exporter mods, such as ctprofiles, et al. provided there is not too much data (limit size).

Ok, enough hijacking... maybe that information was useful to some of you.

I just looked over ZDKP quickly. I like having your bosskills tied together as one raid but still accessable as single events, BUT you'd have to add a possibility to swap members in and out for the various bosskills. Otherwise you'd begin to divide your bosskills into events again to make sure one gets only the points he deserves, which would just destroy this nice overview. And as a minor note, I don't like the design yet ;P Smaller textsize and some borders would make it a lot nicer I think ;)

"When people buy stuff, they spent DKP. Even if you don't update the site, you need to carry a mental update so that people who bought something don't get priority over people who haven't."

Well quite. Updating the site seems like an inconvenient way to keep a simple running total to decide who's turn it is especially if you are not one who likes alt-tabbing out of the game. We used a simple add-on called IncDKP for a while but tbh pen and paper worked at least as well.

"You have a shared database of information and relatively technically unsavvy users. To me that *screams* remote terminal/web based application."

You mean like a simple set of static HTML pages containing all the information the users need?

More convincing reasons for having a database would be things like the users having a transactional relationship with the data, concurrent updates or ad-hoc reporting requirements. None of which apply -- from the "Unsavvy" user's point of view it's a simple, static set of highly predictable reports.

thorvoquien said "The main advantages of serving dkp dynamically are that users can sort and search arbitrarily and multiple officers can easily and concurrently edit it"

In my experience the reporting requirments are entirely predictable and certainly nobody ever once asked me to see something diferent from the obvious reports that were already provided. Similarly concurrent updates were never an issue for us at all as basically it was 1 of 3 people spending 5 mins updating the numbers 3 or 4 times a week.

We are though only a medium sized raid so maybe such things are more of an issue in larger guilds who run concurrent raids and have enough DKP maintenance activity that they need mutiple people working on it but we have none of these problems.

As I said earlier its very obvious that what you are doing is a lot more ambitious than my software which is really just a solution for me and my guild rather than a proper generic solution or anything I was particularly interested in promoting for widespread use by other guilds.

[As an aside: I did actually build a star schema out of our data at one point and DTS it all into a MSAS mult-dimensional cube but the novelty of doing various aggregations and slicing and dicing quickly wears off. I think fundamentally you have a ot of DKP data but very little actual information and that is reflected in the paucity of obvious reporting requirements.]

"That said, my aim here is not to argue what is best"

Nor mine. And I certainly didn't want to interrupt your thread and was thinking more of swapping ideas as much as anything else :-)

Dakous said "Every time someone uses their credit card or writes a cheque, they are (essentially) adding a new line to an SQL database in their bank [...] If you work somewhere where you handle "trouble tickets" or "incident reports" in a database... each of those fields you're filling in is going to be put into SQL"

Well ironcially I used to work somewhere where if you used your credit card or a cash manchine in the UK it stood a good chance of going though software and SQL databases I had a major hand in designing :-)

My point wasn't so much that SQL is a bad idea for a DKP application (indeed the opposite) but that I wanted my soluition to have minimal entry cost for guilds without technically savvy people or access to web hosting.

No, it's pretty easy.

You feed PlayMusic a stream URL. Let's say one of 2^1024th different potential streams, with the particular stream ID encoded into the stream URL. WoW connects to the server, which feeds it a dummy stream, and the server says "Oh, stream X?"

You now have a 1024 bit data packet outbound method. Incredibly inefficient, of course, but it is a current way to export data from the game client. There's no way to import via this method, though.

Ah, of course that would work. My head must have been full of NIR-based agricultural contrast plots and whatsits.

I still fully expect this to be "fixed" sooner rather than later, just like keybindings were and any other method of realtime I/O other than screenshots and UI reloads.

Awesome. I'll be looking forward to it.

Bumping this, to see if there's been any updates.