I have recently began working with multiplayer games in Unity. I am not using Photon Unity Networking but rather the built in networking inside Unity.
In the game I am trying to create, each player has their own money, and inventory variables. My original plan was to store these variable client-side, but I realized this was a bad idea.
What would be the best way to store these variable like money and inventory on the server? I tried making a "Player" class on the server, and created an instance of the class for every player that connected. However, after days of research and experiments, I was unable to find a way to do so successfully.
I'm sure this is a common concept for multiplayer games. So I was wondering if someone could point me in the right direction on how to do so.
The way we choose to do it, was to create a very basic webservice (REST) which the server (and the server only) could talk to.
The webservice was written in Perl with MongoDB as storage backend, but the options here are almost endless, so use whatever you think is best for you.
Related
I am working on a small project trying to control some steps of a workflow in a web application using MS teams. My idea is to use R as an intermediate step between the application (which has a number of API endpoints I can call from R) and Microsoft Teams chats (or channels). Users would then use a set of keywords in the chat to lead to an action in the application. For example they might use "publish ABC-123" in a specific chat and this would lead to the application publishing document ABC-123 somewhere via R which would orchestrate everything.
I have a couple of ideas but there are drawbacks:
I thought originally about using microsoft365r. We have an app registered in Microsoft 365 which would allow us to monitor a specific chat for messages that trigger actions in R. The problem with this approach is that we would need to have the R code running and checking MS Teams every couple of minutes. It is certainly doable, but not very elegant.
Another option could be setting up a plumber API and an outgoing webhook in MS Teams. This seems like the ideal way to do it, but webhooks in MS Teams require https and as far as I understand this is not straightforward to implement in plumber.
I would appreciate any ideas on how to do this. I know I am not very specific, but mostly looking for high level pointers of what I could look at. Many thanks!
You actually have a bunch of options for this:
Create a bot directly in code, e.g. per https://learn.microsoft.com/en-us/microsoftteams/platform/bots/what-are-bots . There's a bit of a learning curve of course, and it depends on whether you have development skills outside of r, e.g. python, .net, whatever. The bot would then call your code as needed.
Create a no-code bot using Power Virtual Agents. This is the equivalent, for bots, of Power Apps or Power Automate, if you're familiar with those.
Create a workflow, either in Power Automate or Azure Logic Apps, that can listen for and respond to messages. This is kind of similar to a bot, but with finer scope (and therefore less capability). If you want it to call out to your app, e.g. to an endpoint, you'd need a Premium Connecter for Power Automate, or you can use an Azure Logic App directly (uses the same engine, but the pricing model is different for these and Power Automate is a little easier to work with.
Outgoing webhook - you can implement these as standalone, but actually from your use case it sounds like a bot would be better anyway, and it's kind of what you need to build to make this kind of webhook work properly anyway.
Does Game Maker have the capability to do multiplayer in the form of many different rooms. I'm trying to create an online Arena style gladiator type game, and I can't have an obscene amount of characters in one arena, so I need many different rooms, created upon need. Can I have different rooms functioning at the same time in game maker, or so I need to cycle thru them to accomplish everything? The game will be turn based, and will be one where you'd log on to take your action, similar to how Frozen Synapse can be run over an extended length of time. Does anyone have any ideas of how to accomplish this or something similar?
Yes you can have multiple rooms funtioning at the same time. I haven't worked much with GameMaker multiplayer, but it is possible since you can do all basic networking stuff.
How hard it is depends on how you want the game to work: Peer to peer or with a host-server.
You an take a look at this tutorial about servers and clients if you haven't already: https://help.yoyogames.com/hc/en-us/articles/216754698-Networking-Overview
If you're using a gamemaker server, short answer is no.
However, if you'd like to use a dedicated server, you can make it possible, because then the server hosts and stores all game information, and the client (players) only render the information that is important to them.
Gamemaker Studio can not by its own run two rooms at the same time naturally, so if you'd like to create something more complex, it's the safest to create a dedicated server elsewhere.
Dedicated servers only transact information, but the game renders from the client.
I'm starting to learn about google's firebase, seems really cool for real time applications. The auto-synced database seems very easy to use and I feel like diving into it.. I plan to start learning by building a simple checkers multiplayer game, but I still have an important question about it..
Firebase auto-syncs between users and devices using their 'magic' Database, which stores data and sends out to 'subscribers' of that db. Now what if I want to have some server processing of this data in between? For example, when a player makes a move, I want something that is not on client-side to make sure that is a valid move.. what would be the architecture to accomplish that?
Having a trusted process that sits between the users is a common scenario when using Firebase. Have a look at our classic blog post Where does Firebase fit in your app?, it would fit closest to pattern 2 there.
Typically you'll want to use the firebase-queue for this. Your users write their "requests" (probably moves in your case) into the queue, the server processes those and updates the actual board.
Another great thing about this is that it's easy to secure. The users can only write to the queue, while the server is the only one that can read the queue and update the board. A lot simpler to capture in security rules than many other approaches.
I have been given access to a real time data feed which provides location information, and I would like to build a website around this, but I am a little unsure on what architecture to use to achieve my needs.
Unfortunately the feed I have access to will only allow a single connection per IP address, therefore building a website that talks directly to the feed is out - as each user would generate a new request, which would be rejected. It would also be desirable to perform some pre-processing on the data, so I guess I will need some kind of back end which retrieves the data, processes it, then makes it available to a website.
From a front end connection perspective, web services sounds like it may work, but would this also create multiple connections to the feed for each user? I would also like the back end connection to be persistent, so that data is retrieved and processed even when the site is not being visited, I believe IIS will recycle web services and websites when they are idle?
I would like to keep the design fairly flexible - in future I will be adding some mobile clients, so the API needs to support remote connections.
The simple solution would have been to log all the processed data to a database, which could then be picked up by the website, but this loses the real-time aspect of the data. Ideally I would be looking to push the data to the website every time the data changes or now data is received.
What is the best way of achieving this, and what technologies are there out there that may assist here? Comet architecture sounds close to what I need, but that would require building a back end that can handle multiple web based queries at once, which seems like quite a task.
Ideally I would be looking for a C# / ASP.NET based solution with Javascript client side, although I guess this question is more based on architecture and concepts than technological implementations of these.
Thanks in advance for all advice!
Realtime Data Consumer
The simplest solution would seem to be having one component that is dedicated to reading the realtime feed. It could then publish the received data on to a queue (or multiple queues) for consumption by other components within your architecture.
This component (A) would be a standalone process, maybe a service.
Queue consumers
The queue(s) can be read by:
a component (B) dedicated to persisting data for future retrieval or querying. If the amount of data is large you could add more components that read from the persistence queue.
a component (C) that publishes the data directly to any connected subscribers. It could also do some processing, but if you are looking at doing large amounts of processing you may need multiple components that perform this task.
Realtime web technology components (D)
If you are using a .NET stack then it seems like SignalR is getting the most traction. You could also look at XSockets (there are more options in my realtime web tech guide. Just search for '.NET'.
You'll want to use signalR to manage subscriptions and then to publish messages to registered client (PubSub - this SO post seems relevant, maybe you can ask for a bit more info).
You could also look at offloading the PubSub component to a hosted service such as Pusher, who I work for. This will handle managing subscriptions and component C would just need to publish data to an appropriate channel. There are other options all listed in the realtime web tech guide.
All these components come with a JavaScript library.
Summary
Components:
A - .NET service - that publishes info to queue(s)
Queues - MSMQ, NServiceBus etc.
B - Could also be a simple .NET service that reads a queue.
C - this really depends on D since some realtime web technologies will be able to directly integrate. But it could also just be a simple .NET service that reads a queue.
D - Realtime web technology that offers a simple way of routing information to subscribers (PubSub).
If you provide any more info I'll update my answer.
A good solution to this would be something like http://rubyeventmachine.com/ or http://nodejs.org/ . It's not asp.net, but it can easily solve the issue of distributing real time data to other users. Since user connections, subscriptions and broadcasting to channels are built in to each, that will make coding the rest super simple. Your clients would just connect over standard tcp.
If you needed clients to poll for updates then you would need a que system to store info for the next request. That could be a simple array, or a more complicated que system depending on your requirements and number of users.
There may be solutions for .net that I am not aware of that do the same thing, but those are the 2 I know of.
We are preparing to scale the API side of an API-heavy web application. My (technically savvy) client proposes a rather unconventional approach to this: instead of balancing the load to several app servers, which would talk to a sharded database, he wants us to:
“shard the app servers”, putting both app server code and db on each physical server, so that the app server only connects to its own db shard;
have the app servers talk to each other when they need to access other shards (instead of talking to another shard's DB directly);
have the API client pick an app shard itself (on the client side, based on some stable hash) and talk directly to it.
The underlying reasoning is that this is the most natural thing to do it, and that this would allow us to move to a multisite distributed system in the future.
(The stack is PHP + Node.js on MySQL, although at this point a transition to MongoDB is considered too.)
Now, I don't see huge problems with it off the shelf. It might get somewhat cumbersome to code these server-to-server interactions, but then it will surely have its own benefits. Basically I'm at a loss on whether this is a good idea or not.
What pros and cons come to your mind? I'm looking for technical issues and advantages here. Thanks!
This is just plain bad for many reasons.
The API client should not know which app shard to talk to. This will limit you in ways you probably can't foresee now, but may/will become a problem in the future. The API client should play dumb so you can route requests appropriately if an app server dies, changes, gets sharded again etc.
What happens if your app code or database architecture is slow? (Not both at the same time, just one). Now you have a db shard slowing down an app shard.
Your db+app shards will need to keep both app code+memory and db code+memory in RAM. This means the CPUs will spend more time swapping code and memory in and out to perform both sets of tasks.
I'm finding it hard to put down in words, but this type of architecture screams 'bad coupling' and 'no separation of concerns' (probably not the right terminology but I hope you understand what I mean). You are putting two distinctly different types of applications (app server and database) onto one box. The management nightmare of updating them and routing around failed instances will be very difficult.
I hate to argue my point this way, but a lot of very smart people have dealt with these problems before and I've never heard of this type of architecture. There's probably a reason for it. Not to mention there's a lot of technology and resources out there that can help you handle traditional sharding and load balancing of app and database servers. If you go with your client's suggested architecture you're on your own.