Working on a new client

[shubla]

Migration from JOGL to LWJGL currently is impossible - because you need to somehow get rid of AWT. There are a lot of hooks and mixing of jogl and AWT, it's hell.

Isn't AWT mostly used for some windowing stuff and input? Probably isn't too difficult to transition to lwjgl.

[nikitron]

Migration from JOGL to LWJGL currently is impossible - because you need to somehow get rid of AWT. There are a lot of hooks and mixing of jogl and AWT, it's hell.

Isn't AWT mostly used for some windowing stuff and input? Probably isn't too difficult to transition to lwjgl.

I try to do a small experiment and for me - it's complicated. I try to use https://github.com/LWJGLX/lwjgl3-awt , but it still requires a lot of modification and refactorings. By desine LWJGL manage user input and context by self. In current code, I see a lot of reimplementing the default AWT behaviors, so it requires complete understanding......

[APXEOLOG]

TL;DR: JOGL or LWJGL? I'd have to figure out a solution either way

The main problem of the client rewrite is rendering. There are 2 ways:
1. Dead end way - pick any OpenGL binding and reimplement the current rendering. The problem here is that to obtain the best performance you need to have a deep knowledge of the rendering pipeline and techniques. People spend decades of 40-hour/week paid job to master that skill and move game engines forward. You definitely don't want to do that
2. Impossible way - pick any mature game engine (Unity, Unreal) and use it to render the game. The problem here is that all game assets are packed in a very specific handcrafted format. To re-use models, animations, textures, and everything else you will need to invest time creating a resource converter. There were converters to/from a very simple obj model format (and I did one myself), but the obj format lacks complexity and "better" formats are hard to grasp. There is also a possibility that we simply do not have some crucial info required to convert res into a mature 3d format

Due to the reasons above, I would not pick Java for the game client. Even for the (1) approach, it is better to use some mature game engine (at least with some built-in UI toolkit). Really, there is no reason to use Java - the game client "logic", apart from the UI (which ideally should be reused from some game engine), took me 3k lines of code to implement with zero code reuse from the original client (I'm talking about networking, resource handling, message processing, remote UI, and maintaining the "game world state" visible to the client)

[shubla]

I'm not too familiar with resource formats but I doubt that its impossible to convert them into more sensible formats. Difficult but not impossible. After all the client eventually passes them to OpenGL in which its very standardized how data should be loaded in, so you could try to reverse your way from how the data is loaded into OpenGL to figure things out maybe?

[telum12]

It doesn't matter. This dude was doing this because he though he could make money off of it by running a closed-source client he would sell access to. He also had nowhere near the level of expertise to do a client-rewrite.

[AlexNT]

took me 3k lines of code to implement with zero code reuse from the original client (I'm talking about networking, resource handling, message processing, remote UI, and maintaining the "game world state" visible to the client)

Would you mind sharing how you handled the code that is loaded as part of resources ( InfoFactory Resource.getcode() )? Looking at the client code, this is the biggest pain point for me as of now.

[shubla]

took me 3k lines of code to implement with zero code reuse from the original client (I'm talking about networking, resource handling, message processing, remote UI, and maintaining the "game world state" visible to the client)

Would you mind sharing how you handled the code that is loaded as part of resources ( InfoFactory Resource.getcode() )? Looking at the client code, this is the biggest pain point for me as of now.

You manually implement every single class like that, that's the trick. I've tried to persuade loftar to make the code files part of the client but he refuses.

[Kwing]

Hi OP,

Here is my attempt to write new client from scratch.
https://github.com/alloploha/HHSwarm
Take any part of the code you need.

As noted by someone - use Unity. Separate GUI from network and from game model.
As per "executable resources" - the only option is to manually replicate and maintain them. Don't use Java. Java is dead.
I agree that original codebase design is the main issue of 99% of problems with stability and performance.

--
Sincerely,
Me

[APXEOLOG]

took me 3k lines of code to implement with zero code reuse from the original client (I'm talking about networking, resource handling, message processing, remote UI, and maintaining the "game world state" visible to the client)

Would you mind sharing how you handled the code that is loaded as part of resources ( InfoFactory Resource.getcode() )? Looking at the client code, this is the biggest pain point for me as of now.

As it's been mentioned already, you do not want to "run" code resources, just handle the logic manually. All custom code is initied with array of argument which can be interpreted by you anyway. For example the `ui/tt/q/quality` resource which handles the item quality accepts one number as argument, so you can just create "quality" field on your item and store that number when encountering such resource type

[OblongNoodle]

This ever get anywhere