Minimally altered custom client recommendation?

[Enjoyment]

Don't be so cruel, guys. While I love romows work, it it still a modification to Loftar's)

[DPblH]

Customs are trash, stick to default and write a post in C&I suggesting what to change/add to improve it.

Default client is unplayable for me. Best FPS is about 12 in village, 40+ in the forest.

[sMartins]

Customs are trash, stick to default and write a post in C&I suggesting what to change/add to improve it.

Default client is unplayable for me. Best FPS is about 12 in village, 40+ in the forest.

Yeah that is the only argument that I approve for using them all, but worry no more ... Loftar is working on that.

[APXEOLOG]

While it's true that I don't use GitHub a lot and therefore don't check it too often, I can't say I've seen many patch suggestions at all, either via GitHub pull requests, or here in the forums, or in any other form, really.

Because due to the "remote ui" architectural concept most of ui improvements looks like (and in fact they are) ugly hack, i don't think anyone in clear mind will accept such PRs. And 90% of performance improvements are just "optionaly disable another thing that consumes cpu/gpu" which will probably not be accepted either.

There were a couple of attempts to make huge rewrite of the rendering system during this years (at leasy by me, but probably by some of the other client makers too), but all of them didn't success. The reasons are quite simple:

• 1. 3d game resources are provided in the very custom format - instead of trying to optimise render we forced to create automatic tools to transform this resources into something that can be passed to the any 3d engine. Even if i had some success with obj converter (and i think DPblH's version is even better), the problem is that obj itself is quite simple and doesn't support a lot of required features, and most of progressive 3d formats are closed or very complex
• 2. Even if you somehow managed to pass step #1 and get proper resources to work with, we hit blocker #2 - there is no high-level 3d engine for Java which supports out-of-the-box all required set of techniques used in current client. So if you want to make some things as they looks right now you either need to patch graphics engine (hard and leads to existing performance issues) or to alter some techniques (requires raw models files and basically some restrictions to techniques used by modeller)
• 3. You can bypass #2 by throwing away everything that doesn't supported by selected java 3d engine for the sake of performance, but the #4 will hit you even more in this case
• 4. You have no control over game development and should always adapt to the recent changes. Basically that means if j&l adds some new cool-looking thing that is not supported by your engine you should throw it away. And at some point it can leads to the situation where you client will looks like shit even if it will be fast and the whole work done will be pointless
• 5. I place this reason last, but honestly this is the main reason. Motivation. To make proper client you should throw a lot time into it. And all efforts can be pointless and you will not actually get much out of it personally. Good words are good, but you need to eat something, you know

In my opinion if j&l want to step closer to the real game, not just hobby project, they should:
Minimum:

• Choose some high-end java game engine and integrate it into the client - the issue here is that it will restrict their visuals by a lot and they will need to revise/remake/remove some visual ideas

Maximum:

• Drop java as a client side and pick one of the current top engines (unity / unreal engine)
• Hire someone who is good with selected engine
• Rewrite client from scratch as well as some server parts (drop remote ui, drop on-the-fly resource loading)

[loftar]

In my opinion if j&l want to step closer to the real game, not just hobby project, they should:
Minimum:

• Choose some high-end java game engine and integrate it into the client - the issue here is that it will restrict their visuals by a lot and they will need to revise/remake/remove some visual ideas

I don't really see why that would make it better. Just as you rightly say, choosing an externally developed engine would mostly just serve to restrict our choices, and I don't really see what positive would come out of it.

Rewrite client from scratch as well as some server parts (drop remote ui, drop on-the-fly resource loading)

There are lots of reasons why I've done it that way, though. Doing it otherwise would need all mechanics basically duplicated on the server and the client, and also ties them closer together, which makes future development much more cumbersome. Not to mention forces full client updates on everyone every time we want to add any little mechanic. It sounds like several steps backwards.

Hire someone who is good with selected engine

While I wouldn't mind hiring people to help out on the project, be it with an in-house or external engine, y'all will have to buy a lot more hats before that can happen. :)

3d game resources are provided in the very custom format

Pretty sure that's true for any game.

the problem is that obj itself is quite simple and doesn't support a lot of required features, and most of progressive 3d formats are closed or very complex

Internally, we use Ogre XML as the interchange format; it should be able to handle any required features. I've also seen such formats as X3D and Collada, which I believe should be able to handle all the features we use, but I haven't looked into them (seeing as how we already have Ogre XML and have no real need to switch).

[mecacat]

Sounds to me like APXEOLOG is one of those people who likes to talk entirely out of their ass, and tell developers what to do without much experience actually being a developer themselves.

I completely and categorically disagree with APXEOLOG's entire premise, and I think H&H is an absolute gem of a game, not in spite of but likely because of the fact that J&L have worked on it as a passion project and kept it true to their vision.

H&H is a good enough game, right now, to finally start to replace in my heart my old game-wife, Ultima Online, to whom I was married for over twenty years.

So sit down, young man, and let J&L do what they do best.

[shubla]

Sounds to me like APXEOLOG is one of those people who likes to talk entirely out of their ass, and tell developers what to do without much experience actually being a developer themselves.

APXEOLOG is a renowed man when it comes to HnH clients.
He has done probably more work with the HnH client than any of the other custom client devs. Thus I think that his opinions are not made up from ass, but result of working years with HnH client. And very vallid, because of that.

Using game engines such as Unity might limit the things one can do. But makes it easier to do the things that you can do. HnH is being developed by only two persons, time is a limited resource. Maybe sometimes its better to make compromises and use pre-existing things, even if they have some downsides, and use the saved time for more important features.

[loftar]

Using game engines such as Unity might limit the things one can do. But makes it easier to do the things that you can do. HnH is being developed by only two persons, time is a limited resource. Maybe sometimes its better to make compromises and use pre-existing things, even if they have some downsides, and use the saved time for more important features.

I feel it should be said that we've already had this discussion.

Because due to the "remote ui" architectural concept most of ui improvements looks like (and in fact they are) ugly hack, i don't think anyone in clear mind will accept such PRs.

Just to get back to this, I'd just like to have it said that it's not like I don't feel your pain on this, and I can certainly understand that the alternative approach you suggest would be preferable from your point of view. It's just that it makes the project worse from my point of view. I'd like to have it stated that I am open to exploring avenues that would either 1) improve the project from both our viewpoints or 2) improve it from your viewpoint but at least not leave it worse off from mine, even if that means some extra work for me. I can't say I have any suggestions myself, however, but feel free to make any.

And 90% of performance improvements are just "optionaly disable another thing that consumes cpu/gpu" which will probably not be accepted either.

That's not entirely true, though. In principle, I'm open to optimizations that disable graphics here and there; the main reason I haven't gone down that road myself yet is that I've felt that the rendering engine should be optimized for what it is first, but that's not necessarily a strong conviction, and I do plan to do things to that effect once I'm done with the engine rewrite.

[sMartins]

That's not entirely true, though. In principle, I'm open to optimizations that disable graphics here and there; the main reason I haven't gone down that road myself yet is that I've felt that the rendering engine should be optimized for what it is first, but that's not necessarily a strong conviction, and I do plan to do things to that effect once I'm done with the engine rewrite.

Interesting, that's could certainly be a valuable feature to have and I'm sure many people would benefit from that ...

[APXEOLOG]

I don't really see why that would make it better. Just as you rightly say, choosing an externally developed engine would mostly just serve to restrict our choices, and I don't really see what positive would come out of it.

The reason is that field of graphics engineering as specialized as any other field. People who create graphics engines should have specific set of skills (https://study.com/articles/Graphics_Eng ... ments.html) and up-to-date expiricence with related technologies (DirectX, OpenGL, Vendor-specific extensions and other stuff). This guys know how to make certain things both fast and cool-looking. The huge advantage of graphics engines that you don't need to have this set of skills yourself, you can just use them and benefit from built-in support of modern video cards, driver versions etc. Even huge companies who makes AAA titles prefer not to mess with custom graphics engines and stick to industry standards. You can probably write your own super-cool-and-fast engine but it will takes months or even years of nothing but graphics engineering. Do you think it is worth it?

There are lots of reasons why I've done it that way, though. Doing it otherwise would need all mechanics basically duplicated on the server and the client, and also ties them closer together, which makes future development much more cumbersome. Not to mention forces full client updates on everyone every time we want to add any little mechanic. It sounds like several steps backwards.

Well, we have different opinion on this one. I prefer to have loose coupling of the components. UI for the client side, calculations for the server side, not both on the server and nothing on the client

Internally, we use Ogre XML as the interchange format; it should be able to handle any required features. I've also seen such formats as X3D and Collada, which I believe should be able to handle all the features we use, but I haven't looked into them (seeing as how we already have Ogre XML and have no real need to switch)

I tried to look into it but it is the format from some semi-dead graphics engine which has not even proper model viewer for it. Anyway, i am not a graphics engineer or modeller, maybe it is easier for such people to distinguish between all animation techniques you use

I feel it should be said that we've already had this discussion.

Yeah, we had this discussions in the past and it didn't lead to anything. I, personally, think that client should be rewrited not only because of the graphics part, it has some general problems. Huge amount of runtime garbage (around 2 millions of Coord objects created per second iirc), questionable concurrency support, some weird code to workaround bugs in java which should be review (probably removed), not to mention code quality