Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Dec 2002
Online Last Active Today, 06:33 AM

Posts I've Made

In Topic: Real-Time WebSockets and REST

Yesterday, 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.

In Topic: Back-end server communication, Http or Manual TCP?

06 July 2015 - 02:47 PM

I know this is an older thread but I just saw it and had some insight I would like to share.


I would also look at using simple middleware like redis. Redis in particular has bindings to most languages including C/C++/C#, python, ruby, javascript etc. which means you have interoperability across programs and platforms out of the box and it is dead simple to use. I use it extensively for voip applications as part of a hosted UCaaS environment for work (nearly 200k connected clients) and unless you are trying to do an MMO first person shooter, performance isn't an issue for thousands of endpoints. Yes it is single threaded but I consider this a bonus as I can deploy as many or as few instances as I want and take advantage of replication and/or clustering for horizontal scaling.


Middleware like redis has saved me ton of time over the past year and has a much smaller learning curve than say RabbitMQ. In my case, application interoperability and rapid prototyping are invaluable to me. Are there gotchas in using middleware? Absolutely but everything has pros and cons. If TCP is your protocol of choice and you want multiple applications to speak to each other, I would be hard pressed to find a simpler solution to at least start with than redis. It wraps common underlying networking paradigms nicely and you can use whatever custom protocol you want for messaging - json or your own binary format - whatever is convenient for you.


One thing - and I feel compelled to say this because I have seen web developers do this with RabbitMQ a bunch - don't expose your middleware directly to the internet. It is a security concern (especially with redis!) and frankly violates the cardinal rule regarding implicitly trusting client communications. My post was mostly about providing "trusted" inter application communication over a trusted network - preferably a LAN. A thin layer providing an API in front of the middleware is always recommended to do basic sanity checks and authentication validation.

In Topic: TCP clients-servers-servers

21 December 2014 - 03:48 PM

It comes down to server tiering and instancing, as others have mentioned. Each shard could consist of a handful of top-level world servers, and beneath each of them could be multiple region servers, and beneath each one of those many instance servers, etc. Thousands of players may be playing your game at once, but each server would only have a handful of players of connected at once (or not have to do much work per player). You'd also probably have separate servers for logging in, chat, auctioning, finding instances, persisting player data, etc., that serve very specific purposes. Basically, the work is spread out across many servers that are each designed to do one task really well.


Of course, the game design itself would have to be amendable to this sort of stratification. If you're trying to design a game where thousands of players can battle it out at once ala EVE, you'll need a whole separate bag of tricks!



By nature, in an MMO there will be a point in which state must be shared between players in some manner. I help design, build and maintain massively multi-user telco services for work on the magnitude of 100k+ users per cluster. Oddly enough this is far less complex than an MMO :)


As was mentioned, it is always preferable to push out anything not "shared" to a series of load balanced services - i.e. find the smallest thing you can do on a large scale that is not visually time sensitive and do it well, then put it behind load balancers - authentication, chat, UI responses (menus etc.). State always becomes an issue here but many times state isn't as necessary as it seems. Perception is the key concept here and it will be different based on the mechanics of every game but there are some general assumptions that will be made.


Physics and collision detection tend to be things that must be housed in an instance of a specific maximum number of players for example. Proper game design and level/area/zone distribution can do more good than innovative code in these areas many times. Distributing wealth, items, quests across a more vast landscape will allow things to spread out much more than if things are concentrated in certain places. An example of this is "the best x in the game" where "x" is something only found in one spot. If there can be only 1 then the goal of many players will be to acquire this item. If on the other hand, there are many balanced items etc. in the game, players will naturally be divided on which ones they care to quest for the most.


As a service provider, our company has many issues to overcome however uptime/availability and load distribution tend to be the biggest daily engineering feats we manage on a daily basis. I can only imagine that an MMO has similar requirements as they too are ultimately a service provider.