Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Dec 2002
Offline Last Active Sep 18 2016 08:33 PM

Posts I've Made

In Topic: (Research) Assuming I have 10000 concurrent players on a FPS Game, what would...

22 December 2015 - 02:38 PM

I purchase, deploy and manage network and server equipment for VoIP services out of many different tier 3 and tier 4 data centers across the US, UK and Australia.


The smart answer is don't buy hardware until you have to. Ramp up using IaaS hosts so you can run on OpEx vs CapEx. This will give you time to raise the capital necessary to get into the data center space. Onlyput stuff into your data center if you can make it reliable. Define what reliable means to you and your end users before even thinking about data center space.


First - data center space is very expensive. It will vary immensely based on contract but it all boils down to power and cooling. The more dense you get per rack, the more cooling your equipment needs. Depending on your architecture and layout of the facilities they will most likely equate a power usage to cooling ratio/sf you must abide by. For example, if you start running redundant 3-phase 60-amp 208v circuits per rack to run a bunch of blade chassis you can easily start to run into requiring thousands of sf of floor space to accommodate the cooling. I will use the term "space" to include power and cooling moving forward. This is your biggest cost.


Second - do you need a carrier hotel or are you okay with 1 or 2 major carriers? This translates into cost for cross connects and DIA circuits and most of all reachability. In most cases with that many concurrent players you will want to peer with multiple carriers like Level3, Verizon, Comcast (and other residential cable/broadband providers) so you can reduce the number of hops it takes for the majority of your players to reach you as well as provide contingency against major fiber cuts that cause providers to route over long distances drastically increasing latency (Ohio I am looking in your direction...). This is your second biggest cost.


The monthly recurring costs of a data center even with only 2 racks can easily be over $100k depending on hardware choices, network requirements and space (remember power and cooling have a defined ratio with square footage) requirements.  If you want to help bring in a more accurate number it really comes down to specifying hardware ( such as blade chassis and blades or stand alone servers etc.) and how many you intend to put in a rack. You also need to figure out if you will deploy racks as kind of a stand alone entity with top of the rack switching or if you will deploy centralized networking with patch panels. It is usually a combination of both but this will play a major role in your ability to automate and orchestrate via smart hands which either way will result in further overhead costs.


Again, I cannot stress this enough - don't get into the data center game unless you absolutely have to. It is rare these days to have an application that cannot work within the offerings/confines of an IaaS provider. There is a tipping point at which IaaS is more costly (operating margins) than running your own data center but by that time your recurring revenue should pay for that transition or you have done something very, very wrong.

In Topic: How can I improve my network performance?

09 October 2015 - 03:49 PM

As hplus0603 and ProfBeeman have suggested the send/recv calls don't always align especially when network traffic picks up as you have suggested it does.


Some middleware libraries like 0MQ (ZeroMQ) wrap this for you and provide messaging patterns like you are looking for.

In Topic: Real-Time WebSockets and REST

03 October 2015 - 07:21 PM

I always applaud the idea of using well known, highly used authentication and authorization methods. The only other response I have at this time is the group will probably be more help if you begin implementing your system and ask specific questions. The architecture side of things will always be debatable and to be honest nothing you are suggesting is standout wrong per say. That being said I would imagine your troubles here won't be with your architecture so much as the network jitter and delay interpolation etc on a space shmup.


One suggestion when writing apps on AWS:

I have been using redis a lot for a bunch of work projects as a lightweight message bus (as opposed to the bulky more feature rich and complex enterprise ready RabbitMQ) that supports pubsub and message queuing and it has worked out really well for being that general abstraction layer between applications. Instead of applications working with databases or filesystems for data stores for example they work with a very thin request/response API over redis and then I have connectors for the various databases/data stores on the back end for various APIs. It takes a bit of extra work up front but has saved me a bunch on the back side when various design decisions and features suddenly change requirements and scope. It has also really made scaling very easy (multiple instances of single threaded apps).

In Topic: Generating and initializing content for a text RPG

10 September 2015 - 08:34 AM

+1 for SQLite


Having worked on many text based MUDs in the past the one thing that holds true is that the easier it is to manage the data the better because the content is your game.


A few reasons I like SQLite:

- the callbacks for executing queries map nicely to constructing objects (1 row - 1 object)

- ACID compliant - you would be surprised how often this can be an issue

- in a text based world, SQL is just plain useful.

- SQLite has a lot of external editors that - to me anyway - are much more suited for structured text / game data

- If you outgrow SQLite you can very easily move data to nearly any larger SQL database

In Topic: Making a text-based adventure game with Ruby

06 July 2015 - 07:56 PM

There are countless codebases (not many good for tutorial purposes) for text based MUDs on the interwebs. They were super popular in the early 90s and some had rebuilds in the 2000s in languages like perl and python that are probably much more relevant to what you are looking for.

The point is many are still actually active and I would recommend playing a few to get ideas on what you want to accomplish in terms of differentiating you game from existing ones. For the most part one can get away with renaming things in the area files as a start and fiddling with existing code to see how it affects the rest of the game.