Specifics after the jump! bonus points if you know what “famous person” HiroProtagonist is. :p

I would have used my own xbox live gamercard, but i don’t have a 360, so i don’t have any interesting status to see.

I got the idea from xfire’s mini profile and seeing live’s gamercards all over the place. I like the xbox live look better than xfire’s default profiles, but i’m hoping stuff like this will make the xfire crew look at a couple little things it could do to make this easier for users. Especially since the xfire client has skinning support, why shouldn’t the mini profiles? If they turned the profile site into an xml / soap / something service, this would be super easy, and nobody would be wasting bandwidth downloading the whole profile page and parsing out stuff.

I got the code for scraping the xfire profile page from Jason Reading at http://customsigs.free.fr. He has a whole bunch of utilities there to make profiles and all kinds of cool things from your xfire data. The code that i wrote is now hosted there, since i started from Jason’s stuff.

The gamercard driven by your xfire stats from your profile page. My code uses same setup, syntax as the xbox live one does. Unlike the microsoft one, there are only links to your xfire profile and not to the games themselves, because the xfire profile site doesn’t have any info or urls for games. The icon mouseover does indicate your week/alltime playing times for each game.

Examples

Parameters

script:

• xfire_card.php.
  See CXS Custom Xfire Sigs for the official source and README

required:

• username – xfire username

optional:

• style – either “gold” (default) or “silver”. this goes with the gold/silver status of live members and changes the color of the top.
• avatar – url to image to use as avatar. note that this is in a url, so special chars should be url encoded.
  the code sets this image to 64×64, so smaller images are scaled up by the browser(like your xfire standard avatar, game icons) or large images scaled down to fit.
• css – url to cascading style sheet to use. by default, uses microsoft’s standard gamercard css. again note urlencoding
• link – url to where you want clicks on your avatar to go.

Possible Improvements

• Make the script output as an image. Many people have complained about live’s iframe gamercard,
  and many online solutions exist to get image versions or flash versions to embed into websites, sigs.
  This is probably pretty easy, as the background is an image in the css, all that is required is drawing the text parts.
  Images remove most hyperlinking, so that’s a downside there. I think thats why the flash versions exist.
• Make more things clickable. right now clicking goes to your xfire profile, but externalizing the link would be trivial.
• get xfire to publish this stuff through xml or soap or something so we don’t have to parse html. thats
  just wasting bandwidth for us AND for xfire.
• get xfire to use bigger images for games. the 16×16′s are getting scaled up and look goofy.
  alternately, write a small script in php/etc that would smooth scale on the fly and cached the scaled versions
  alternately, get bigger/custom images for all the games, and use those instead of xfire’s

My XFire “Gamercard” hack. was originally posted at John's Random Review.

Multiplayer Game Architecture Done (Game Development Class 4) was originally posted at John's Random Review.

I have written 3 plug-ins for Asheron’s Call using decal; one which tracks monsters you kill and “trophy” items you recieve, and submits it to a website (Trophy Hunter), another which acts as a shopping cart when interacting with players who are running special “Trade Bot” plug-ins to act as vendors (Bargain Hunter), and one which tracks Player vs Player kills (PK Hunter). This article covers some design and implementation details that third plug-in, PKHunter.

Background

One feature that exists in almost any form of multiplayer game is some facet of “player vs. player” gameplay, or “PvP”, where players directly attack each other. Commonly, it is also known as “player killing”, or “PK”. In most games this aspect is optional, meaning that players cannot attack other players unless that player has flagged themselves somehow, by completing a special quest, or checking a checkbox somewhere in the game’s interface. However, most of these games also have specific servers where player vs player is always on, so that players have no choice. In Asheron’s Call, this server is called “Darktide”, abbreviated simply as DT. Because players who are “PK” appear as red dots in a player’s radar, the players are commonly called “red”, as well as servers of the PvP only type being called “red” servers.

Unlike many games with PvP, Asheron’s Call has no in game rating or ranking system of player killing activities. Because I had already written one plug-in which tracked player vs monster (PvM) activities, i decided to expand that out to another plug-in that tracked PK activity and would attempt to assign some kind of ratings to players.

How it works

Security details omitted

Figure 1: client side details

The plug-in uses various facilities within Decal to watch the network stream going from the client to the server. When it sees special “Player Killed” message go by, it looks at the UID (unique identifier) for each person involved. If both of these UID’s resolve to player characters, the plug-in adds that time and those two user UID’s to a list. Every few minutes (or by pressing button in the UI) and when the player logs out of the game, the plug-in submits that information to the PKHunter website.

Figure 2: PKHunter UI

The client plug-in also has a few other functionalities, including a list that shows the players own kills and deaths, as well as other player vs player kills that they witnessed. “Witnessed” is used lightly here, as a player may not have actually watched a player kill another, he might have just been near enough for the AC server to send the “Player killed” packet to that player. The AC client itself may filter that out, so the player might never be informed of the event. To see some details about the AC protocol, as reverse engineered by players, see Example these (out of date) insanity inc protocol docs. You might want to right click and “save as” that baby, as it’s around 675k!

Figure 3: server side details

The website does more than just serve up pages to users outside of the game like a regular website. It also has several scripts which are used by the plug-in to validate users, submit results, and retrieve player info to display in game. The website is written in entirely in PHP. Some of the PHP scripts are used by cron jobs to regularly generate static html that is used for the front page and some other high traffic pages to avoid them going to the database for no reason. The PHP scripts that handle submissions do the bare minimum of work, doing some very basic security checks, and then dump the rest of the submission into the database and immediately return to the client. This attempts to minimize any delay within the AC client itself.

The service is a java application which runs 24/7 on the database server. The service processes the raw submissions from the client at its leisure, parsing the xml, validating them, and culling any duplicates that were submitted by other players. The service takes each submission in turn, looking up each player involved, computes the rating change based on each player’s current rating, and then updates each player.

The database is a simple MySQL database, with only a few important tables: One holds submissions, one holds processed and validated kills, and a third holds player details and statistics. A few other tables are used for bookkeeping, site statistics, service stats, but aren’t interesting enough to be discussed here

Technologies used

Client side:

• “Decal” plug-in: c++

Server Side:

• Web site: PHP
• Service: Java
• Database: MySQL
• OS: Currently Mandrake (now Mandriva?) Linux. Because the rest of the technologies used are cross platform, I can set up the server on almost any operating system, though.

Some statistics

Original Release: PKHunter 1.0.0.1 10/20/2002
Number of Releases: in just under 3 years, only 5 updates, the last of which was 11/24/2002.
Number of “Characters” in the Database: 186,152. This does not imply “users” of the plug-in, only people who have been witnessed as a killer or victim.
Number of “Plug-in Users”: 73,519. This is player characters who have submitted results.
“Unique” Users:15,203. This is the closest to actual “users” that i can get with the information i track. I don’t track anything specific enough to identify people having multiple accounts or anything like that.
Users submitting results in last year:4100
Number of kills tracked:3,334,216
Number of kills in the last year:1,108,350
Website hits per month:235,485
Website bandwidth per month:1.61 GB
Website hits YTD: 1,539,861
Website bandwidth YTD: 9.74 GB
Electricity consumed by servers: 1.21 GW. kidding. thats from back to the figure. But probably a lot!

Future…

The current system only tracks killer and victim, but a lot of people have complained that the person who gets the “killshot” is not necessarily the “killer” that has looting rights.

What i’d like to do is add extra stuff, so that the system can find the corpse created when a player dies, get details from that (text on the corpse indicates who was the actual “killer”), and have the system track both “real” killer, and also have an entry for the “killshot” player. This would allow some more statistics like kills:killshots, to see if people are real PK’s or just are ganking people at the end .
I’d also like to switch back over to an actual “ladder” style rating system instead of using the “modified” glicko system i’m using now.

PK Hunter architecture was originally posted at John's Random Review.

The adv graphics class was, like the first class, taught by Bretton Wade, who works in the XBox group at Microsoft. I don’t know exactly what his title is, but he’s neck deep in the graphics part of the X360, so he’s in the know. (If you google him, you’ll find all kinds of papers and stuff. He’s the BSP tree FAQ maintainer too.

Other details, as well as my final presentation with screenshots and all that is available after the jump.

The third class was about advanced graphics topics in games. Almost all of them are acronyms! Stuff like PRT, HDR, BSP. The non acronym ones were various shadow methods, ambient occlusion, animation, normal/light maps, height fields, all kinds of stuff. We also covered lots of general things like GPU architecture, comparisons of X360 and PS3 and Revolution architectures after all the E3 announcements, floating point things every programmer should know.

Instead of lots of specific homework, we had to pick at least 2 topics from the advanced tech list and integrate them into our game engine. An unlisted topic was converting from the fixed function pipeline to using shaders too. (If you didn’t do that already, you almost needed to to do some of the advanced topics…). So i picked:

• Converting to use srogrammable shader, because i didn’t do that the first ‘mester
• Level of Detail
• Particle Systems

Here’s a screenshot:

You can obviously see the particles used for the fireworks, snow, and explosion. The cubes in the background are the placeholder “low detail” models to draw in the distance. I have no art skill, so all i made were cubes to show that different art is being used for the different LoD’s.

Here is my final presentation including more screenshots, and other details. If you want to actually download the game and play it, email me. it has some wierd requirements to run, so i’m not just gonna post it all up.

All in all it was a pretty cool class! The next one, the 4th and last class in the certificate program, is about networking and advanced UI. It should be pretty cool too!

Advanced Graphics Class Done (Game Development Class 3) was originally posted at John's Random Review.

The AI class, taught by Steve Rabin of the AI Game Programming Wisdom series of books, was pretty awesome! We added debug graphics, a real time profiler, a state machine system, flocking, A* pathfinding, coordinated behavior, terrain analysis, and gameplay to our game engines created for the first class. More details about the content after the jump.

The second class had a lot more rigid structure than the first, including assignments due every week. The assignments were due 2 weeks after being assigned, so there was at least one week of class that covered the material before we had to do it. And this semester, we had to give a presentation at the end of the class to show off what we’d done, so there was some pressure there.

Also, I thought the content of this class was a lot more interesting, personally. I’m not much of a graphics person, i’m semi creative at the 10000 ft level, but when it comes to real details and modelling and texturing and such, i have a 0 skill level. The debugging graphics content, like drawing text and lines was super useful for debugging, and would have been tremendously useful in the first semester.

I didn’t get as much done in my engine as i wanted to, and with work heating up again, i’m not sure i’ll get to do all the stuff i want next semester either!

But, at the end of the class, i did have a fully “functional” game, a kind-of “South Park” themed “Pac-Man”, or “South-Pac” if you will. You are chef, and run around eating yellow pellets in the maze. 3 of each of the south park boys chase you about the maze, with a group coordinator only allowing one of the 12 to actively plan a path (read: cheat) at any given time. It also has an intro, title, pause, and credits scenes. Oh, and the “You go to hell and you die!” Mr Garrison sound when you die, so thats cool!

AI Class Done (Game Development Class 2) was originally posted at John's Random Review.

Game Development Class was originally posted at John's Random Review.

Updates to BargainHunter was originally posted at John's Random Review.

Strategist was originally posted at John's Random Review.