I am creating a kind of MMORPG, its pretty simple, non intensive. However, the game world is split up into areas, I am thinking this can be handled by matches. However, it seems creating a match by name is not server authoritive based on this documentation? Heroic Labs Documentation | Godot 4
Is there a way around this? I want all actions to be handled by the server, not player. How can I create a match on the server or using a specific system user and keep those matches open indefinitely and allow players to leave and join those matches?
Some extra questions, if you get past that one.
Is using a system user the best way of handling storage for things like items and loot tables?
Is there a good example for handling and creating AI enemies for a match?
Can the server initiate a match with a player? For context, while exploring a zone(match), there could be enemy AI with which the player can attack or be attacked by, which would then put that particular AI and the player in a new combat match. After the match the player is returned to the previous match.
I wonder these things too and I haven’t gotten that far yet, at the moment I’m just experimenting and trying to get used to the source. But I would love to share my thoughts with the community.
In order to maximize what Nakama can do, I plan to unregister all default APIs and use Nakama only as a library, basically make my own extension with my implementations, based on the existing ones. By doing this I will have complete control over all valid calls and everything that happens in the back-end.
I’ve decided to pursue my idea using a custom UDP server. I’d rather not have to cobble together stuff thats not made to be used the way I intend it to be used. However, the matchmaking and session based gameplay of Nakama seems pretty nice and robust so I may use it in other ideas I have,
You should be able to create matches per zone on the start of the server and give them labels that could be used later to list specific matches. Our project-template could be worth checking out.
Regarding question 1, you can do that just don’t forget setting checking the read permission. 2 and 3, the match handle logic should let you express your game logic. AI based or not.
Im willing to give it another shot. I have managed to create a storage workflow for updating various game data but thats as far as I’ve really gotten. If I can create matches ahead of time in a server module that have authority over player actions that would be helpful.
I actually see no documentation or examples on handling AI, which is a bigger issue. The official documentation is pretty messy and confusing so please correct me if I am missing the AI section. For context, I want to be able to add AI characters to different matches and have some idle actions they do, like moving around or even moving to a different area/match. Is this just something I handle after creating the match? Just manage the match state in my own logic during a match loop of sorts?
Currently I feel like what I am trying to do is too complex for what Nakama is trying to achieve.
Also it looks like the links in that repo are broken. Kind of a good example of messy documentation when the links change and most random posts I find are also linking to broken or out date docs. Documentation is probably my biggest gripe. I am actually willing to create a series of documentation for the things I can accomplish, if I can actually accomplish them.
I actually see no documentation or examples on handling AI, which is a bigger issue. The official documentation is pretty messy and confusing so please correct me if I am missing the AI section.
At the moment we don’t have a guide for that but Nakama as far as I know should not limit you on the code you write to achieve that.
Good catch. We have worked on our documentation but we have still to update the links in that repo. Thank you for pointing it out.
In the project-template repo, you have this file with the match logic that I hope you find useful. It should provide the base.
If you have suggestions on how to improve our documentation, we are more than happy to hear them. We want to make it as accessible as possible.
