Jump to content
  • Advertisement

JMDeruty

Member
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

112 Neutral

About JMDeruty

  • Rank
    Newbie
  1. JMDeruty

    MMOs and modern scaling techniques

    More than one game company has died by designing something that, in the end, the engineering team couldn't actually deliver.   Fine, I cannot disagree with that But that's not the what I meant: Many companies died by designing something which was way more complicated and beautiful than what the actual need required. So without clear goal & specifications, we (myself first) tend to overthink things.   Sorry to have implied that. At the end this question is more a question of well designed development process, and evaluation. And thanks for the reference, I didn't know it.   More in line with the topic, a few years ago I had read from Bigworld about using simulated players to evaluate the scaling behavior of MMOs. With the availability of AWS or Azure, do you know if this kind of testing has been used effectively by studios? Apart from the difficulty of simulating pertinent player behaviors, are there other pitfalls?
  2. JMDeruty

    MMOs and modern scaling techniques

    In my opinion, gameplay comes first, then we imagine software to make it possible. I mean that building an angine to enable compact crowds of players with collision & physics simulation don't looks like enough to define the player experience and what really matters. Is the compact crowd (public transportation like) even something desirable to provide a good experience? If not, the issue should be dealt with before (disable collisions in crowded/marketplace areas)   And if you need that in the game (large scale -interesting- close combat battles?), I doubt that a generic engine would do.   That mean a lot of testing & tweaking, keeping in mind that what's important is not accurancy but player experience according to the gameplay mechanics. Players everywhere would mean that individuals loose significance. That's not PvP, but Mob vs Mob. Maybe some sort of LOD with precise local interactions then working with densities and statistical behaviors at longer range to reduce the quantity of informations required. In this case you have to deal with the issues listed by hplus0603. At the end it depends on the game's priorities and compromises.     PS: I have met web architects advising to use simple stateless loadbalancing for  realtime multiplayer with Redis to manage send queues and game state.  If you need physics or whatever, it won't work. Too much latency, and that's not Redis fault. The software is fine but not made for this. In my opinion, that's shoe horning REST optimisation into something which cannot be made stateless. Because there are to many player interactions. It works for chats however because: 1) There is not so much user interactions 2) latency is not really a concern.
  3. Yes, I agree with you on that. The issue can be somewhat mitigated but it's far from ideal. That's why we have UDP on the roadmap. As our first requests focused on features like chat and reliable push or duplex messaging and cross platform compatibility, websocket has been the first transport we have implemented.   Raknet becoming opensource is something that as reduced dramatically the cost of adding an satisfying UDP transport. :) So it's underway.   We didn't consider plain TCP until now because websocket is essentially TCP with an HTTP handshake. Adding your own socket listener is not feasible neither, as the firewall configuration wouldn't allow that.   Right no Stormancer is not hostable outside of our infrastructure . However it's something we have in mind, depending on customer requests.  The design is rather modular, with the game hosting servers working as a distributed app exposing its own API and pushing logs to a configurable endpoint (currently a redis queue). We have somewhat a dependency with Windows Azure for Azure Table & blob storage but we built things to be able to plug another NoSQL DB & storage system without to much hassle.(Dependency Injection + generic interfaces) . We are considering ES as a replacement for Azure Table for instance. That would enable a few interesting search features in our scene system which are not possible with Tables. 
  4. Thanks a lot for these replies and the follow-up questions :)   I wrote this post more as a starting point for discussion than a sales pitch. Developing everything would have been quite long.   That's a lot of questions, I will try to answer them all. - I understand your point about the cloud. I agree that it's easy to take any web service and put the "cloud" sticker on it. Let's just say that we built the hosting platform and we provide it as a service running on an infrastructure itself available as a service. That’s as cloud as it gets.   We are currently in the first stages of our development. We have the service working, used by developers without much network & server management skills. They are very satisfied, but the platform & tools are clearly not in the state we are targeting.   The platform is currently in beta, we don't offer strong SLA. I understand very well that it can be a real issue, but we’ve had very few outages since starting the beta (less than 8 hours in the last 12 months of beta), and we really can't ward our users against outage from our own service providers (currently Azure). However, we monitor issues & outages and communicate about them and about the resolution process. We currently offer support contracts on a case by case basis.   From a security point of view, we have put in place several security layers on our side to ensure isolation of application containers. We don't handle data storage yet because we want to be sure we can do that while enforcing a good enough security level. So right now we don't store your data. (But developers may well use databases like SQL Azure, tables or clearDB mySQL offering from the same datacenters) For better isolation & performance (and direct client-server communication) it's possible to deploy dedicated instances currently on request and in a few months from the management portal. For even more security, it could even be possible to deploy a Stormancer cluster on your own infrastructure, whether cloud based or not. We provide some security through SSL for websocket and HTTP. All API calls are secured through a symmetric key system (we may switch to JWT before the end of the beta) and monitored.   Legal protection is a tough subject. We have it for everywhere around the world... except the US & Canada. For now.     We provide an SDK which abstracts a lot of things like object serialization, communication channels (through a route system), room load balancing & lifecycle management (we call them scenes). Our SDK also offers open source multi platform client libraries (not enough platform now, we are building new libraries on request however), The server SDK is written in C#, and designed for non blocking logic The customization pattern is behavior based.   We currently provide only a few turnkey behaviors on top of this framework, it's clearly something we want to work on. We are going to open source them on github too. We are doing that only a step at a time, mostly to take the time to clean things up. For instance, if you need something as simple as a realtime push or broadcasting server, you can do that without coding anything at all on the server. But you can also customize these components with your logic (and your code!), or create something from scratch.   For instance, we are also working on a matchmaking module, and another which will handle the base features of turn based games. We also make sure (when possible) that these turnkey components can be used together.    The available tools are: - An open source command line system. Currently only works on Windows, we need to add some alternative authentication logic on the platform to port it on Linux. If needed, just ask. - A local emulator (windows only too. Same as the command line, Mono support is on the roadmap, could be moved up on request). Manageable from the cmd line, and as soon as we get the time from an included web application. - The management portal. Should go open source too, as soon as we get time to do some code cleaning. - Management libraries for .NET, PHP & javascript - Server library currently distributed through nuget. - Client libraries currently for .NET, Unity, javascript and soon C++.   Network Currently, it's websocket, so TCP (SSL) only. I agree that it requires a lot of tweaking to get the most out of it, and that's really not adequate for fast paced games. But on the good side it works almost everywhere, even behind transparent proxies for mobile games.) Good news, Raknet integration is on the way: It will bring UDP and unreliable messaging to the platform.   What did you mean when you wrote websocket only was a deal breaker? Do you need unreliable messaging (UDP) or HTTP web hosting?   HTTP web API hosting is something that some developers asked us, so it's on the roadmap, but with a low priority because it's rather easy to integrate Stormancer into an existing web application hosted elsewhere.   Right now, it's possible to build custom, authenticated HTTP APIs (curl compatible) for Stormancer server apps. This enables full control of the Stormancer app from your own web servers for instance, without having to deal with bidirectional communication.   Deployment Deployment is done through the command line (> stormancer deploy). Ultimately it's only an HTTP PUT request, so developers could very well build other tools on top of it, or integrate it into custom deployment workflows. We keep the 10 last deployments (configurable on request) and it's possible to rollback to any of them in the management app. Deploying a new version doesn't disconnect players by default, as different game versions can live side by side. However new connections happen only on the newest deployment. We might add support for different environments in the future (ie production, staging...). However the feature can be replicated by creating 2 apps.  Monitoring Monitoring is currently possible through a persistent logging system, and we should roll out a metrics system before the end of July. We are clearly not satisfied by the situation here so we are working on it. Our monitoring stack runs logstash & Elastic Search. I would be happy to get the opinion of people experienced with this subject about this stack.  We don’t do turnkey A/B testing right now, as we are focusing on the hosting/networking part. However, it should be possible to implement that through parametrized scene creation, custom metrics and some game client logic. Not trivial, but not overly complicated neither. Building something better could be definitely feasible, however I would need to think more about use cases for realtime, synchronous apps A/B testing.   Samples and benchmarks We have a few samples in Unity, javascript and native C#. For instance we made a very simple multiplayer version of Angry bots (explained I a two-part tutorial: part 1 and part 2), and a quizz game in C#. You can find more samples and tutorials on our blog. We are working on a full quizz benchmark app (requested by a customer) including Database connections and with simulated players. Apart from the free plan, Stormancer will be available as Pay as you use. Developers will be able to buy compute units of different sizes with a base cost of 20€/month (300MB RAM, 1 CPU share) .This is not set in stone however, we want to adjust that with the data from our benchmarks and feedback.
  5. Hi!   We are a small team building a cloud platform to offer free tools and affordable hosting for realtime multiplayer games. We started this project some time ago when we started such a game, and we want to share what we are building.   After much work, we have made it available for everyone as a free beta. We really would like feedbacks and suggestions about what we've created and what you would like to see.   Stormancer uses websocket (we are working on UDP communications through Raknet), works currently for javascript and Unity games, and allows developers to deploy fully customizable code in the cloud (including stuff like physics, database, culling or AI). It's mainly coded in C#, and all the logic is non blocking.   We want to open source the client SDKs soon too (We just feel a little too bad about some parts of the code to release that now :( ). The documentation is a little (too) sparse right now, feel free to ask us for help. We are friendly & helpful ;).   The next version should feature distributed hosting on several servers, and we are working hard on adding metrics/analytics to let you know what exactly is happening in your games.   What do you think about it? If you have projects, we’ll be very glad to help you too, with or without Stormancer :)   Check our website at http://www.stormancer.com/ (and some tutorials are on: http://blog.stormancer.com/).   Cheers!
  6. Wow... I didn't see that coming neither. Just awesome. We will definitely use it on our project.
  7. RT @Stormancer: A new way to approach narrative design in games: the 4 Layers Approach - by @ThomasGrip http://t.co/7SzTgFCa94 #gamedev #ga
  8. JMDeruty

    How to spawn objects near players?

    As other said, you need a spatial indexing structure, the good news is that nowadays, a lot of database vendors (SQL & noSQL) support spatial indexing , whether in memory or on disk.   You could probably use one of these out of the box implementations, and perform spatial queries on them to get the list of players to be notified when you move an object. The main drawback being that what you really want is not "querying" but rather be "notified" when you move objects around. Something that Elasticsearch does through its percolation feature... But I really don't know if the kind of load and latencies you expect are compatible with this tool. I didn't experiment the thing yet, sadly.   At the end, I think the best solution for you depends on these factors: - You require really low latencies and a lot of queries, but persistence and dataset size is not the core concern: Build your own grid memory based system. - Your main concern is the dataset size and you don't need to put everything in the process memory: an existing spatial database could possibly do the trick, with a little experimentation.
  • 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!