Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How do we want to define players? #15

Open
RubyNova opened this issue May 4, 2018 · 2 comments
Open

How do we want to define players? #15

RubyNova opened this issue May 4, 2018 · 2 comments
Labels
Discussion For features we are unsure about and wish to discuss before implementing.

Comments

@RubyNova
Copy link
Owner

RubyNova commented May 4, 2018

I don't want the engine to be restrictive like Unreal Engine 4, whereby if you're not making an FPS you're out of luck. I want to keep the engine as open-ended as possible, but since it's a MUD engine there's the issue of characters and how we wish to handle their stats and inventories.

Is this something we add into the engine? If so, how? I don't personally think we shold write this ourselves, or at least not entirely.

I want the engine to be used in as many RPG-esque contexts as possible.

@RubyNova RubyNova added the Discussion For features we are unsure about and wish to discuss before implementing. label May 4, 2018
@RyadaProductions
Copy link
Collaborator

What we could do is maybe add a POCO option for the player. And let everything else be handled by an InputManager of some kind.

The reason why a POCO might be a good idea is because it would supply the option to use them with ECS as well as completely decoupling input from the player object.
This is a benefit for the netcode as well as we only need to send values and we can send a complete state back to the client. Although i am unsure how this would behave with other people their MUD clients.

@RubyNova
Copy link
Owner Author

Ive been currently looking into IO and player representation being separated in the first revision of the prototype. Should be out in a few days.

The IIOHandler handles all input and ohtput as it currently stands. This is the centralised point of entry and exit.

In the first revision, input entities will be used as a means for command context. The input entity used to run the command will be determined by command source data which users of the engine can define.

If the POCO locks it to the engine's own sister client then well need a way to send standard telnet protocol to other MUD clients.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion For features we are unsure about and wish to discuss before implementing.
Projects
None yet
Development

No branches or pull requests

2 participants