Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

779 Good

About evillive2

  • Rank
    Advanced Member

Personal Information

  • Role
  • Interests
  1. A quick suggestion is to allow a layer 4 proxy like haproxy to handle the dual stack side for you. There are a ton of possible benefits to this as an abstraction layer - managing ports, ipv4/ipv6, security, logging and monitoring etc. Most importantly is it lets you get back to completing the game.
  2. evillive2

    Pygame - alternatives?

    This sounds like a common problem from ages ago when game coordinates were using integer/pixel location vs floats. Every loop/iteration would lose some precision and rounding/truncating would cause jitter every few updates like you have described because pixels would be gained/lost in the math. The idea that a fluctuation of 2-5 frames/second could cause a noticeable display issue like this, as others pointed out, is a very unlikely. I wont say impossible but this all rings very familiar to me even recently when working on HTML5 canvas games where browsers have wide ranges of deltas between updates and even display rates.
  3. evillive2

    IPv6 Multicast not working

    Multicast and even broadcast can be painful when you get into anything beyond a flat network. We have had servers reboot themselves because of multicast delays (RHEL clustering used to use multicast, they may still but we moved away from that). Here are some things we have done that push this off the network layer (routers and firewalls being black magic to most developers). Have your server nodes register with a registration service which keeps tabs on the registered server's version and availability status etc. This is what we have moved to for most production servers. The registration service is also responsible for adding/removing the servers from load balancing where appropriate. Does your server provide a management port for modifying the running config, getting metrics etc.? If so, a periodic local network scan for this port is often much easier to facilitate with tools like nmap kicking off a discovery process. We do also run periodic scans in addition to having servers register themselves. SNMP on managed network gear for publishing events like ARP (unexpected new MAC address or IP failover?), physical port status etc. is ideal but not always available depending on your hosting situation. Use pub/sub/queueing/event streaming middleware instead of broadcast/multicast. In almost ever scenario the minimal latency is worth it. From Redis to RabbitMQ to Kafka, this is how things work at scale. If you are delving into network protocols beyond unicast tcp/udp there needs to be some very good justification. I am not saying there is no need for multicast or broadcast, but it is very rare beyond HA appliances that expect to be physically close to eachother which is fairly limiting in today's virtualized hosting world. The middleware is also much easier to troubleshoot than getting packet captures from a mirrored/span network port or individual servers. DNS is important. Every interface on each server has an fqdn (some of ours have multiple interfaces) and PTR record. It is also important to make use of CNAME and SRV records where appropriate for services the servers offer. DNS is here to help. Managing bare IPs is tough enough with IPv4 but after a few dozen it is just taxing keeping it straight. With IPv6, good luck. Use tools like ansible/chef/puppet to automate multiple server deployment including spinning up VMs, managing DNS and configuration management. Keep the snowflakes to a minimum. There is nothing more satisfying than kicking off an ansible playbook, going to get a cup of coffee and coming back to find a few dozen new servers deployed, packages and dependencies installed, monitoring platforms displaying the new services and automated testing/burn in kicked off. Spend the time on configuration management and automation. Your users will thank you. Your future self will thank you when you can spend time on adding features vs troubleshooting basic connectivity because of a missing route or a typo in a config.
  4. evillive2

    C# Where to get started in making a text based MUD?

    If I were to do this today, I would probably do the single page app approach (client side javascript) with nodejs (server side javascript) handling the authentication/websockets (essentially network messaging transport). Then I would use python to run the game loop/state using redis as the middleware communication layer between nodejs and python. Windows doesn't even come with telnet enabled by default and the games quickly become difficult without some client filtering and aliasing things anyway so the traditional bare tcp socket approach doesn't seem worth it to me anymore. I guess there is still a dwindling community of folks using variations of telnet clients specifically for text based MUDs and maybe that is your target audience. I still agree with hplus in that a web interface is probably the way to get the most people easy access.
  5. As mentioned, nodejs (javascript) offers some great client facing options with simple websockets and webserver support. Another reason to consider websocket support is a fairly low barrier to using TLS (letsencrypt.org) instead of the traditional in the clear text communications most telnet/MUD clients use by default. We all want to promote security right? Also, this project looks to still be active as a reference though I have not done anything more than browse the repository myself so cannot offer any opinions good or bad. https://github.com/shawncplus/ranviermud
  6. Deploy your server to a hosted solution such as AWS EC2, Azure or Digital Ocean. Avoid port forwarding and all that silliness on your home network potentially exposing you and your family to intrusion. A $5/month server is usually more than sufficient for proof of concept and you can even pay by the hour if that seems overly expensive.   That being said definitely read up on some networking like hplus said. At worst you will understand why your solution may not be working and you will be able to share your perspectives here on gamedev.
  7. A little late to the conversation but a metric in general is just a data point. How important it is to you depends on the context in which you look at it. That being said, much of your generic networking specific metrics from the server side perspective can come from outside of your application from existing network tools such as SNMP, ntop, snort and more. While the learning curve of these runs the gambit from small to zomg! they exist specifically for the reasons I believe you asked - though even more generic since they don't care if your application is a game or not. You can get packets per second, bandwidth utilization to/from specific clients, jitter, packet loss and so much more. I work at an ITSP and these tools are essential for us as we can quickly identify if a new application was introduced on our network or if an application or even specific client is acting up or having issues. There are older tools like rrdtool with C and many other language bindings that you basically send key value pairs at timed intervals to for things you would like to keep track of and also offers a way to visualize that data. Things like grafana and influxdb have taken this concept to another level of scale being used by highly distributed web services today where network and database transaction metrics help them prioritize optimizations and user experience.  As for what metrics look like - they are generally just key value pairs you export at timed intervals and some other tool helps you visualize it in the manner appropriate to you. What is interesting to you? If your application can export metrics to a message/event queue and let something else do the imports to whatever tools you want, the tools you use can change independent of your application.
  8. 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.
  9. 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.
  10. evillive2

    Real-Time WebSockets and REST

    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).
  11. evillive2

    Generating and initializing content for a text RPG

    +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
  12. 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.
  13. 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.
  14. evillive2

    TCP clients-servers-servers

        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.
  15. First - good luck. I truly mean that and not in a sarcastic manner.   Any input I would have at this point in time would be pure speculation because despite the effort to be detailed about what you are doing, it is difficult to really grok what is going on.   I will suggest on a much more basic and probably unrelated level however that TCP is the way to go until you find it is not - and then check that again. I work in telecom where some people still believe everything must be UDP because "it is faster" when really there are only a few pieces that actually need UDP (RTP for example) where others are actually much less complicated and more scalable over TCP (SIP for example). Of course I am probably getting ahead of myself because I have to build massively scalable and redundant systems with load balancers etc. where none of this will matter to you but if I can help someone avoid the pain I feel every day because of myths and half truths it will be worth it.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!