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

Feature/importer rework #120

Draft
wants to merge 6 commits into
base: master
Choose a base branch
from
Draft

Feature/importer rework #120

wants to merge 6 commits into from

Conversation

KirmesBude
Copy link
Contributor

No description provided.

@KirmesBude
Copy link
Contributor Author

I have been thinking about this @ataulien
A lot of the functionality seems to be a copy of ImportZen in BsZenLib - the remaining part is the Vob importing and to a lesser degree the Waynet importing.
Could we not keep this all contained in BsZenLib with the addition of importing waynet and vobs?
Either as classes we can inherit or function pointers.
E.g.
We would have an importVobs function in BsZenLib that is provided to the importZEN function by default, but can manually come from REGoth.

@ataulien
Copy link
Contributor

I'm currently hesitating in whether we should keep using bsf, as it seems like the Creator was forced to stop working on it after getting a new job. See the bsf Discord-announcements channel for more information on that.

The bsf-renderer itself, while modern and nice, is not flexible enough for our needs. The physics system, utility library, component system and all that is nice, though...

I do have a prototype rendering library with a simple interface made to render gothic-assets on my local machine, which is an approach that I found to work really well! It also uses ZenLib and bgfx, which allowed me to borrow a lot of code from REGoth.

@KirmesBude
Copy link
Contributor Author

KirmesBude commented Mar 11, 2020

I was still holding out hope he was coming back, since he only set the banshee repository to private. But I guess there has been no news in almost half a year.
Really unfortuante - I can't speak for the renderer, but from the little I had worked with it I actually kind of liked it - especially the way the GUI was handled.

Let's see this as a new opportunity to do it right from the start ... again :D. Maybe we can look to other engine recreations to see what libraries/frameworks are a good fit for this kind of thing https://en.wikipedia.org/wiki/List_of_game_engine_recreations.

As for your prototype - sounds great. Let me know if you got something going.

@ataulien
Copy link
Contributor

I was actually playing around with some simple gothic-multiplayer thingy. Current multiplayer projects try to sync full games between each other with a simple server in between AFAIK. I got decent results pretty quick with a different approach:

Run the original game as server, have the clients be "thin":

  • Clients are completely custom, no original game there. Uses ZenLib and the rendering library for
    display purposes.
  • The clients then only send keypresses and other minimal data to the server.
  • Whenever the server receives keypresses from the clients, it applies them to that clients controlled NPC.
  • The server syncs only the visual state to the clients (along with some minimal other info).
  • There is next to no logic on the client.

That is why I wanted a nice separation between the engine and the renderer - turns out that is a pretty nice idea anyways! And we can reuse a lot of code from both REGoths.

With OpenGothic leaving REGoth far behind in terms of progress, it might be time to go join forces or go into different directions anyways. And Coop-Gothic is something I've wanted for a long time ;)

@KirmesBude
Copy link
Contributor Author

KirmesBude commented Mar 11, 2020

I was actually playing around with some simple gothic-multiplayer thingy. Current multiplayer projects try to sync full games between each other with a simple server in between AFAIK. I got decent results pretty quick with a different approach:

Run the original game as server, have the clients be "thin":

* Clients are completely custom, no original game there. Uses ZenLib and the rendering library for
  display purposes.

* The clients then only send keypresses and other minimal data to the server.

* Whenever the server receives keypresses from the clients, it applies them to that clients controlled NPC.

* The server syncs only the visual state to the clients (along with some minimal other info).

* There is next to no logic on the client.

That is why I wanted a nice separation between the engine and the renderer - turns out that is a pretty nice idea anyways! And we can reuse a lot of code from both REGoths.

Seems like the only sane solution to multiplayer if you put it that way :D.
So the server handles everything, but rendering and only sends data relevant for the specific client character (only in the vicinty or something)?

With OpenGothic leaving REGoth far behind in terms of progress, it might be time to go join forces or go into different directions anyways. And Coop-Gothic is something I've wanted for a long time ;)

I still remember when (I think) Zerxes was working on a coop multiplayer gothic. Sadly nothing came of it. Did not know that there was quite some progress in the meantime - sadly nothing for coop, it seems.
OpenGothic's progress is quite impressive, but sadly there is next to no documentation. And I dont see it every properly supporting anything besides Windows.
I feel like even with going the direction of coop-Gothic we would end up building the whole engine anyways - only without any rendering, at least for the server :D

@ataulien
Copy link
Contributor

I feel like even with going the direction of coop-Gothic we would end up building the whole engine anyways - only without any rendering, at least for the server :D

My prototype hooks into the original game, which was surprisingly simple. The Server is also encapsulated into a library which should make it possible to plug it into OpenGothic or whatever. It is all a prototype, but maybe I'll get around to put the code up soon!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants