Hello,
First of all I would like to thank you for the great project that is Nakama. We’re going to start evaluating him (on a practical level) for a project we’re working on.
Our “game” is not a common game, we are making a training platform for cyber security, that is, our game servers are not an instance where we have the game logic and several clients connected, but for each game we have an infrastructure of machines raised.
For the backend part, we have a lot of Nakama. But I have some doubts about how to implement some features that we need:
a) When our player creates a new game, we need an associated logic to instantiate our virtual machines where the game will be played. We already have a service that does that, so the logic would be as simple as executing a RPC or HTTP call to another external service, but if we need to be able to have a logic of states associated to the current game. The way in Nakama would be with “Autorithative Player”?
b) The code that is running in the game servers during the game needs to connect sometimes with the backend… Would the way in Nakama be with “Autorithative Player”? With the server-to-server?
c) The storage engine fits us but we need to be able to make requests for item listings with filters. Is it possible to extend the data request options in Nakama to have more powerful filters?
d) Apart from these filters, we want to be able to intercept requests to certain collections because we need to apply custom logic to modify some values. For example: we have a collection of missions but according to some progress of the player there are missions that the player could not play. Could we do this in storage engine service? Would it be better to extend the server with an own RPC request that does this?
Regards!
Welcome @fjggarrido 
. I’ll answer your questions as best I can below.
as simple as executing a RPC or HTTP call to another external service, but if we need to be able to have a logic of states associated to the current game. The way in Nakama would be with “Autorithative Player”?
What are the “logic states” in this use case? Do you want to tie together the information about your virtual machines to some game logic in Nakama?
Would the way in Nakama be with “Autorithative Player”? With the server-to-server?
Yes we’ve worked with many game teams that have to integrate with other HTTP/cloud services which talk back to the game server as an RPC function call (server to server).
Is it possible to extend the data request options in Nakama to have more powerful filters?
The storage engine already has support to do listings over objects in a collection. I guess what you want is to provide key filters on the list operations as an access pattern for the data? Do you have an example of the structure of your data and how you want to filter over it?
Could we do this in storage engine service? Would it be better to extend the server with an own RPC request that does this?
There’s two ways to handle this requirement. You could create a before hook on the write operation to storage and use that to apply logic to prevent players from reading objects (in your case missions) that they don’t have access to yet. The second option is to just move the logic into an RPC function that calls the storage engine internally and filter out whatever missions the player should not be able to see.
I would probably use the second approach but it depends on how complex the logic you have that could affect what missions the player can see.
Hope this helps.
1 Like
What are the “logic states” in this use case? Do you want to tie together the information about your virtual machines to some game logic in Nakama?
When a customer creates a game I need to have a mini status machine that will run custom logic. For example, when nakama tells me that the game is created, I would be in a state that by doing “on enter” would send an HTTP message to another service to create servers in the cloud. During the “on update” of that state I would be asking if the servers are already created and then notifying the player that he can play. I would have to save these game states in some database. I see that the multiplayer part has a game mode that gives you callbacks from Nakama, I imagine that this would be the place and that I could use the storage engine to save the status of the game instance… but I don’t know if it’s the most suitable way.
The storage engine already has support to do listings over objects in a collection. I guess what you want is to provide key filters on the list operations as an access pattern for the data? Do you have an example of the structure of your data and how you want to filter over it?
Yes, I would like to be able to request a list of elements and apply a filter on a key. In the structure below I would like to make a request with several filters: category of the course and level of the module.
Perhaps a valid approach would be to have several more automated collections and make several requests for a list of elements or even as you indicate make your own endpoint where to perform this logic by accessing the storage engine from the server.
Example:
{
.Courses:
[
{
Title: “hello world”,
Category: “programming”
.Modules:
[
{
Title “Hello World Module 01”,
“Level”: Basic
}
]
}
]
}
I would probably use the second approach but it depends on how complex the logic you have that could affect what missions the player can see.
I think the same thing.
The key is that I want the player to receive the object (the mission) but with a value indicating that he cannot play. This value is not in the storage engine because it is not a generic value of the objective, but it is a dynamic value according to the player and other conditions that could expand over time. Therefore, I can’t simply give you the list of missions, but in the response information from the server I need to make modifications based on my own logic.
Regards!!!
but I don’t know if it’s the most suitable way.
This is quite a unique use case but I can see two ways to handle it:
- Use the authoritative multiplayer engine to start a match handler (a goroutine) which you interact with over a socket. This will look and feel like its own lifecycle that’s independent of connected peers so perhaps its a good abstraction but without more specific details its hard to be sure.
- Spin up your own goroutine from an RPC function with your Go code and use that to manage the specific lifecycle of the communication between your dedicated server instances and the clients that need to know about it.
Perhaps a valid approach would be to have several more automated collections and make several requests for a list of elements
Yep. I’m not certain that you really need key filters for this use case. You can just place the modules into storage objects under different collections. You could also just store all the information under a few large keys.
Therefore, I can’t simply give you the list of missions, but in the response information from the server I need to make modifications based on my own logic.
In this case an RPC function is the right place to control the rules around the courses/modules and return a domain specific JSON response that fits the data model for your game client code.