Closed Xyseer764 closed 2 years ago
jcsnider
commented
3 years ago Can you give an example of what a player to player interaction with dictionaries might look like? I do not fully understand the benefits of having this.
Events can be really powerful, and game changing, but they are also performance heavy. Just because they can do something doesn't mean you should. Hard coded systems, while more complex, will always be vastly more efficient.
Xyseer764
commented
3 years ago Dictionaries would allow stuff like:
Events can be really powerful, and game changing, but they are also performance heavy. Just because they can do something doesn't mean you should. Hard coded systems, while more complex, will always be vastly more efficient.
I really wonder how strong the "vastly" is in that sentence, because I'm getting the feeling you think the Event System is unusable for creating any system that's more complicated than the utter basics, as it'd grind the server to a halt. But if it's not that bad and the server can handle a decent amount of dictionary calls from the Event System, then I see no reason why we shouldn't have an option to use them.
If it were my code base and I had made it from scratch, I wouldn't be asking for these additions, as I'd just be hard coding everything myself. But because the source is huge and is lacking in comments I'd much rather work through the Event System whenever I can and bite the servers costs if that's what it takes. This is also coming from someone with decent programming experience - I can't imagine what it's like for people who stumble upon the engine because it looks user friendly and are unable to implement anything but the most basic of systems from the editor.
Cheshire92
commented
3 years ago I really wonder how strong the "vastly" is in that sentence, because I'm getting the feeling you think the Event System is unusable for creating any system that's more complicated than the utter basics, as it'd grind the server to a halt. But if it's not that bad and the server can handle a decent amount of dictionary calls from the Event System, then I see no reason why we shouldn't have an option to use them.
We've seen performance drop from reasonable to slowing down an entire area with like 10-20 events per player running 80+ players in an area.
If it were my code base and I had made it from scratch, I wouldn't be asking for these additions, as I'd just be hard coding everything myself. But because the source is huge and is lacking in comments I'd much rather work through the Event System whenever I can and bite the servers costs if that's what it takes.
You're free to do that if you wish, but all of us are firm believers that some thing should simply not be done through the event system outside of prototyping. As for comments, it's open source and just a few volunteers working on it. You're free to help documenting the source if it bugs you.
Xyseer764
commented
3 years ago We've seen performance drop from reasonable to slowing down an entire area with like 10-20 events per player running 80+ players in an area.
The question is how complex were these events (unless for some reasons all events have a massive computational load on default). A completely empty, global event with no conditions and no autorun shouldn't be much more demanding for the server than a simple tile.
You're free to do that if you wish, but all of us are firm believers that some thing should simply not be done through the event system outside of prototyping. As for comments, it's open source and just a few volunteers working on it. You're free to help documenting the source if it bugs you.
I consider the project a great undertaking and the fact that you were able to handle all of the back-end networking is amazing and I'd love to help. The lack of comments doesn't "bug" me, it just makes it very difficult for me to understand how to implement any feature into the engine.
jcsnider
commented
3 years ago
- Being able to affect an another player's game state, like directly helping them complete a quest (for example some quest requiring you to find the support of 3 different people).
This can somewhat be done right now with Party Sync when setting variables. Not great but might help in the meantime.
- A wide range of reputations could be held by players and be publicly seen - stuff like their kill count, quests completed, ect.. This can be further expanded to have effects on gameplay.
I can understand this. I haven't really come across a reason for it in my own projects as of yet.
- Ability to expand guild functionality - you could for example add guild points for each guilds that are gathered by different members and serve some gameplay purpose.
I'm not opposed to this request by any means, but it's a lot of development time that impacts a large amount of of the event system and requires a ton of form/db work to get working properly. It also isn't something I see a ton of use cases for -- but I still might not be thinking far enough out of the box.
Regardless, like always, open to a PR for anyone who wants to take this on.
Xyseer764
commented
3 years ago If that's too laborious to implement, could we at least have access to Player variables of other players? That would be a limited version of this feature, but it'd still allow for a large chunk of the functionality I mentioned (2/3 suggestions above).
We'd need access to the player ID, a way to receive that player ID as another player and an Event Command that accesses Player Variables by Player ID and not just implicitly the hosts ID.
jcsnider
commented
3 years ago How do you know which player id you want? I guess on PvpKill, PvpDeath, or PlayerInteract you could grab the player on the other end, otherwise events would have no idea what player variable to give you.
Same as above. I am open to a PR from anyone who wants to take it on. I've got dozens of other enhancements/features that I am working on with much higher demand, along with my own game which is being developed using this engine. So there is really no telling when I'd wrap back around to this.
Xyseer764
commented
3 years ago Yeah, that's exactly what I was thinking - you could read the ID from those.
lodicolo
commented
3 years ago
- Being able to affect an another player's game state, like directly helping them complete a quest (for example some quest requiring you to find the support of 3 different people).
Like JC mentioned this should already sort of be supported, and honestly something like this should be baked in.
- A wide range of reputations could be held by players and be publicly seen - stuff like their kill count, quests completed, ect.. This can be further expanded to have effects on gameplay. We already have performance metrics in the engine, this would be "content" metrics. This should also be baked in because it's useful in general for content develoeprs.
If it were my code base and I had made it from scratch, I wouldn't be asking for these additions, as I'd just be hard coding everything myself. But because the source is huge and is lacking in comments I'd much rather work through the Event System whenever I can and bite the servers costs if that's what it takes. This is also coming from someone with decent programming experience - I can't imagine what it's like for people who stumble upon the engine because it looks user friendly and are unable to implement anything but the most basic of systems from the editor.
As a programmer myself, the event system is the one thing I avoid touching if all possible. It's slow, and not ergonomic when I know exactly what I want to be doing.
Is your feature request related to a problem? Please describe. Currently, the Event System is severely limited, as we have no access to any form of list. Any system that requires some form of cross-player interaction requires this data object, otherwise there's no scalability beyond debug-purposes. Currently, your only option is to copy-paste global variables and manually assign them to each player you expect to play your game. Any developer that wants to develop for the MMO part from the "MMORPG" will currently run into a brick wall, as any cross-player interaction system has to be hard-coded.
A good example of this limitation is how the Guild system was implemented in the Intersect Engine. Here I'm only talking about the functionality part, as I understand that something like a UI editor that allows you to access player variables is still extremely far down on the priority list. The functionality of Guilds should've been implementable from the start through things like variable manipulation and the Event System, as Guilds are an extremely simple and basic system - they register who signed up for them and allow those players to interact with each other in some way that should be easily programmable through the Event System. Instead it was impossible to even make the registration system without running into scalability issues.
Describe the solution you'd like Currently, we have Player Variables and Global Variables, my proposition is to add a Dictionary Variables (they'd be only global, player dictionaries would be neat, but for now I just want to have the basics covered) in which we can store data. I'm proposing a dictionary instead of an Array, as it'd give far more freedom to the developer in regards to how they want to structure their data than a simple Array and it's very similar in the development time to an Array. The implementation in the editor itself would need these things:
This would be a copy of the Variable Editor, allowing to create dictionaries, folders, and select the dictionary Key type (bool, integer, string) and their stored Data type (bool, integer, string).This would take the dictionary you want to use and the Key to the value (key is static value or variable). It'd spit out the value or a hard-coded default (in case the specified Key has no value assigned).This would be the copy of the "Variable Is..." condition, but instead of a variable it'd take a chosen dictionary and a chosen Key (key is static value or variable).This isn't directly dictionary-related, but without this small thing dictionaries would be a lot more hostile to use. Adding this would allow us to easily relay data between different players.Additional context The feature I'm proposing is general, basic, not that hard to implement (unless you're dealing with some limitations in your database I'm not aware of), doesn't require a more demanding net code (you're never sending dictionaries through packets, but dictionary values and keys) and would cut down the need for hard-coding small systems and features, as it'd allow the developer to implement them straight from the Event System. Any game that wants to create custom player to player interaction will be very welcoming of this feature, as it'd mean they can spend more time on developing rather than having to mess with the source code when implementing every little thing.
Personal Note I've discovered the engine recently and I'm examining its functionality for my project. I come from a Unity/Godot environment, but my plan to make an MMO made me go looking for alternatives better than just coding the entire thing myself (from my experiences, I really hate dealing with net code). I'm impressed with the engine's back-end as it handles all of the networking bull-crap I didn't want to deal with. Unfortunately, every time I try to implement something using the editor, I find it extremely lacking in basic functionality, which is why I'll be creating a few feature suggestions which I think would massively improve the engine's functionality and are really general to the entire MMORPG experience. I want to contribute to the project in the future, but the lackluster (most of the time completely absent) use of comments in the code and no code documentation multiply the amount of time I'll need to grasp the code base a hundred-fold.