Page 1 of 1

The "other" statistics website - Looking for alpha testers

Posted: 2009-12-06 22:54
by dev.pvp.vg
(In case the administrators or moderators see fit to move this thread, please do so)


Hello and welcome everyone!

I'd like to introduce you to my idea before actually stating my plea to you :)

I am working in the IT for more than ten years by now, and little by little, came to the conclusion that a job at the "plain regular" IT shop is not what I want for the next ten years. Thus I decided it would be time to look for a job in the "gaming industry" (gosh, I hate this term), doing the stuff I love: Consume data coming from games and do some "black magic" :D

To draw attention of possible employers I need a good and interesting project that yields great benefit for game shops and the actual players. I were breaking my head over that one, since all niches for BF2 were already taken. After a while toying around with server-side Python scripting I came up with really something which does not yet exist.

(Which, of course, I will not unveil until it's "baked" and ready for public access)


However, in order to actually turn this idea into reality I do need data to consume which can only by obtained by running a server-side custom Python script which will then send the data to a custom application server that will arrange and persist the received information into a database.

From there the data will be polled and displayed on a website.

Here is a diagram showing the connection between the various endpoints/services and the current infrastructure on which this service will be hosted.

Code: Select all

 PlayerA   PlayerB   PlayerC
    ^        ^         ^
    |        |         |
    '________|_________'
             |
             V
        Your PR server
             |
             V
    My application server
             |
             V
         NHIbernate
             ^
             |
   .__________________.
   |                  |
   V                  V
 MemcacheD        Database 
   ^                  ^
   |                  |
   '__________________'
             |
             V
         NHibernate
             ^
             |
             V
         Webservice

The script does only transmit information that is already available to all connected players. This includes
  • Position on the map (X,Y,Z)
  • Pitch and/or Yaw (where applicable)
  • Vehicle (where applicable)
  • Equipped weapon (where applicable)
  • Team (or faction)
  • Squad lead flag
  • Command flag (where applicable)

I am now looking for server administrators that are willing to participate in the closed alpha asap it is ready :)

If you are willing to participate, please send me a private message containing the following information:
  • With how many server(s) you will participate? (The more, the better for stress testing)
  • How many players are playing on your server(s) (See above)
Once the alpha is ready for testing, you will receive a login and password for every server that will be running the script, since there will be per-round statistics that are bound to individual servers.


If you have any questions or need clarification on things, please do ask :)



Thank you for your time and attention!

Sincerely yours,
dev.pvp.vg aka. dot45

Re: The "other" statistics website - Looking for alpha testers

Posted: 2009-12-07 06:04
by Artnez
Some questions:

1) What technology is your application server using?
2) What format are the requests sent in (from the game server)?
3) Which database server will you be using?
4) What frequency of traffic do you expect to support?

Re: The "other" statistics website - Looking for alpha testers

Posted: 2009-12-07 06:28
by dev.pvp.vg
Hello Artnez :)

Here's some details
  1. The app server is written in C# using asynchronous network reads/writes, making use of NHibernate with MemmcacheD as 2nd level cache
  2. The data submitted by game servers gets packed into byte streams and sent over the wire through Python
  3. Microsoft SqlServer 2008. To alleviate database load both app and web server will rely on MemcacheD to retrieve copies of active objects.
  4. For the webservice: Up to 200 requests/second are supported by default with expected peaks of 300-400. If requests exceed the computing capabilities of the infrastructure, a proxy can be put in front of the web server that will forcibly cache requests and serve them from memory
  5. For the app server: Knowing the spam of events on inf only servers, I can tell that there will be many incoming packets to be processed concurrently. Because of this I chose a similar design approach as it is present in the Apache web server. Having worker threads serving clients individually should take advantage of all four CPU cores.
/edit: Added clarification on the "read/write" part