Showing Graphs for a Round

[Sufficient]

You would do it timewise for basing. Time on the x AND y axis =) (flag time on the y axis tho =D).

[MetalKid]

Yes, it would require a lot of data in the database in order to do this. If this was implemented, I would propose only keeping the data around for 24 hours. After that, you could simply delete the data. Heck, 1 hour might even be enough. If it was an awesome comeback, someone would print screen it and save it somewhere, so you wouldn't need the data anymore.

At the very least, I think it would be cool to have this in TWL. It wouldn't take that much coding since the bot is already recording the kills/deaths, so it would be simple to create a timestamp of when the kill was recorded. Maybe just make a bunch of textfiles that output data in an easy to use format for excel or something that people can take the next step, if they want to. Or someone can make a quick program to read in the data to make a graph. That way, it wouldn't impact the database.

[Reaver]

Nice idea, but half of TW can't read graphs.

[Zerzera]

Nice idea, but half of TW can't read graphs.

rofl.

[leroy]

When you have a database, everything looks like a record.

Most of the data being pulled from the database could be better served as static (or at least XML based) content.

TWD rounds are a good example, how many times are players going to switch sides in a round that was played a month ago? Cache the data in external XML files, let the database handle new/uncached queries only.

With graphs for kills/time (or flag time / time), dump the data to a SVG file and forget about it. Then either the users browser can render the graph or a server side script does (for IE, FF < 1.5, etc).

The upshot of caching xml files of things like games is finally squadsites can predictably and easily get the data and results of TWD/TWL games, displaying them how they want to -- without having to do any parsing of html.

There's enough whining about how the database is under too much strain and that it's too big to add any significant new stuff (kinda true), so FIX things. It'd take maybe two days of work to get the database checking for a cached file before touching the db for each page request. Or doesn't having the site running faster and the trench db being less burdoned sound like a good thing?

Serve more cached content.

[Fait]

oh oh how about editorial comments next to kills, or an announcer. The game has never gotten past click and shoot, so why not leave it there.