Java is painful

[Potjeh]

Half the charm of building computer games lies in maintaining your own engines. Yes, X is open source, but the moment you start making significant modifications to it -- and you will want to -- you may or may not remain compatible with the future development of the main branch, and suddenly you find yourself in magical limbo land where you half-own your own problems, yet half don't, and all along you maintain a bunch of code and datastructures to support features you're never going to use. You want to do something, but do you file a feature request and wait patiently for support for that to be added to the main branch, or do you actually fix it yourself? Who knows. "Oh, but it's open source, you can do whatever you want", yeah, sure you can, but what you do needs to be in conformity with the totality of what's already there, which could be quite a bit. Rather than working on your game, you'll be spending time understanding and working around someone else's preconceived notions of what you may or may not want to do. Were I to start building a new game today, I would never for a second consider using Godot, or Unity, or UnReal Engine, or anything of the sort.

You could use the same argument for building your own virtual machine instead of using Java.

[shubla]

Half the charm of building computer games lies in maintaining your own engines. Yes, X is open source, but the moment you start making significant modifications to it -- and you will want to -- you may or may not remain compatible with the future development of the main branch, and suddenly you find yourself in magical limbo land where you half-own your own problems, yet half don't, and all along you maintain a bunch of code and datastructures to support features you're never going to use. You want to do something, but do you file a feature request and wait patiently for support for that to be added to the main branch, or do you actually fix it yourself? Who knows. "Oh, but it's open source, you can do whatever you want", yeah, sure you can, but what you do needs to be in conformity with the totality of what's already there, which could be quite a bit. Rather than working on your game, you'll be spending time understanding and working around someone else's preconceived notions of what you may or may not want to do. Were I to start building a new game today, I would never for a second consider using Godot, or Unity, or UnReal Engine, or anything of the sort.

You could use the same argument for building your own virtual machine instead of using Java.

One has to choose a middle ground between using some very high level game engine and mining your own metals for server components.

[loftar]

There are also other reasons for using Java, most importantly the ability to dynamically load code in a platform-independent manner. I'm not even sure how I'd replicate that on other platforms with less than either including a full copy of LLVM with the client or pre-compiling all dynamic code for all possible combinations of hardware and operating system that it might run on.

http://docs.godotengine.org/en/stable/g ... -resources

Correct me if I'm wrong, but it is my impression that godot-script is similar to CPython performance-wise, and yeah, of course the thought of embedding Jython or something for resource code has struck me previously, but there are several resources that contain code that is fairly performance-sensitive.

Also, as far as goes the Godot engine in its other aspects, the fact that they can't even present a "hello world" as one single and simple text-file, rather than as a whole tutorial that goes through eleventeen various levels of GUI for creating "projects" and whatnot rules it out for me right then and there. If that's the kind of stuff I wanted, I'd be using Visual Studio already.

I guess that the launcher is faster on windows if it knows which program to open it with so its one click. (On linux I use command line so its not that fast or easy)

java -jar hafen-launcher.jar -- Not sure what's supposed to be less then optimally fast about that. Especially if you, like me, bind that to a shortcut through your window manager.

There are many multi-platform games that don't seem to have any issues. Dynamically loading code? If you mean your res file system, one should not have used it in the first place.

Whyever not? I find it quite nice indeed to be able to easily push small updates for individual resources automatically, without needing users to even have to do so much as restart their clients. Especially so in the presence of custom clients.

Maybe he means some more recent OpenGL version than 15+ year old one ¦]

To be fair, I've been looking at the hardware that our players are using (through the error reports), and there are very few meaningful upgrades to the required OpenGL version that I could do without seemingly excluding a pretty large part of them. The next step will be Vulkan, not a later version of OpenGL.

You could use the same argument for building your own virtual machine instead of using Java.

That's true in and of itself, but I feel there's a rather big difference between a general-purpose language and very special-purpose library/framework. I do use other external resources as well, stuff like libz, gnutls, jorbis, &c&c, but they all have in common that they are written in a very general-purpose manner, and tend to only force the minimal required amount of structure on their users.

I only found some discussion about C# and java differences.
If somebody says that java game is as fast (or faster!) than C and C++ he is wrong.

I'm guessing this is actually the crux of the issue. And in and of itself I'm not saying you're wrong, but I would strongly argue that the difference is very much small enough that it's not worth a rewrite from scratch (the current rewrite is only of the rendering system, mind you, not of the whole client). Hotspot is a very competent compiler, and I actually don't think the performance penalty from using Java is more than perhaps 10-20%. There are really more important reasons to choose C/C++ over Java than raw performance. Memory usage would be one of them.

[MagicManICT]

Also, as far as goes the Godot engine in its other aspects, the fact that they can't even present a "hello world" as one single and simple text-file, rather than as a whole tutorial that goes through eleventeen various levels of GUI for creating "projects" and whatnot rules it out for me right then and there. If that's the kind of stuff I wanted, I'd be using Visual Studio already.

As far as simple programs in Visual Studio go, short of the basics of how to create and run code in VS outside of how you'd normally do it, it's about a 5 step process including the step "Open Visual Studio." I may be exaggerating a bit here. Been a while since I've worked on a project in it. No, it's not as simple as using vi or emacs, but then a lot of what you have to deal with via command line in simplified editors has been "managed out" in development suites so that you don't need to touch it for basic programs.

@shubla: nobody claimed Java was faster than native code. Loftar posted some research about performance of Java based apps vs native code some years ago. i don't know where that post is, but the studies are out on the Internet. I know it was within 10%, and if memory serves, it was as little as a 2% difference in performance. I believe the types of routines and code being performed has an impact as there are some things Java does well, and some things it doesn't.

The next step will be Vulkan,

I hope it truly catches on, but at this point... Glide was a superior technology at the time, and look at where it's at now.

[shubla]

Whyever not? I find it quite nice indeed to be able to easily push small updates for individual resources automatically, without needing users to even have to do so much as restart their clients. Especially so in the presence of custom clients.

It's amusing that you say that loading code from resource files is a good thing from perspective of a custom client developer, but this is not the case. I think that nearly all custom client owners that I know have cursed your resource file code system, because it makes it really difficult to access and modify some parts of the clients code. So you are doing quite the opposite of a service to them. You should release all the code that is included in resource files in the clients git repository.

Vulkan,

I hope it truly catches on, but at this point... Glide was a superior technology at the time, and look at where it's at now.

It will, OpenGL doesn't really support multi core if I have understood correctly, and multi core is perhaps one of the most important things that makes modern games with good graphics possible. And so far vulkan has been the best solution for this (if directX is not available).

[loftar]

It's amusing that you say that loading code from resource files is a good thing from perspective of a custom client developer, but this is not the case. I think that nearly all custom client owners that I know have cursed your resource file code system, because it makes it really difficult to access and modify some parts of the clients code. So you are doing quite the opposite of a service to them.

That wasn't really what I said, though; I said that it makes it very convenient for me to push simple changes, in the presence of custom clients. I am well aware that they are troublesome to authors of said clients, and I would like to remedy that in some way (if only I could think of one, which still preserves the advantages that I derive from it). Also, though most of their contact with resource classes is probably irksome, I do think custom client authors do derive more convenience from them than they perhaps realize (or are willing to admit); as a custom client author yourself, would you really prefer to need to merge new code and publish a new client with every other patch for it to remain usable at all, or to just ignore the vast majority of resource-code updates as you currently do?

You should release all the code that is included in resource files in the clients git repository.

Since some time back, the source code of the resource classes have been included in the resource files.

It will, OpenGL doesn't really support multi core if I have understood correctly, and multi core is perhaps one of the most important things that makes modern games with good graphics possible. And so far vulkan has been the best solution for this (if directX is not available).

As far as I can tell, it's the best solution even when DirectX is available; Vulkan does more than DX12 does. It's also much, much more than just multi-threading support. To me, the two most important parts of it are persistent command-lists, and the ability to use a GPU without having to go through the windowing system. I also don't really doubt that it will catch on. It's already seeing adoption in many contexts, and I don't see any reason why that should stop. If anything, I think it's more likely that OpenGL will simply become a library on top of Vulkan.

[shubla]

You should release all the code that is included in resource files in the clients git repository.

Since some time back, the source code of the resource classes have been included in the resource files.

But if you change a resource file with code in it now, how will I know that you have made changes to it?
How do I know the existence of some resource file that contains code?
Via trial and error, crash reports and weird bugs, not fun.

I don't see reason why you couldn't include them in the git repository as well, even if they would be loaded as res files like they currently are.

[Ardennesss]

You should release all the code that is included in resource files in the clients git repository.

Since some time back, the source code of the resource classes have been included in the resource files.

But if you change a resource file with code in it now, how will I know that you have made changes to it?
How do I know the existence of some resource file that contains code?
Via trial and error, crash reports and weird bugs, not fun.

I don't see reason why you couldn't include them in the git repository as well, even if they would be loaded as res files like they currently are.

Have to agree with Shubla here, the problem isn't entirely the system, it's that there's no changelog of server kept Res changes. The season patch for example changed the Trees resource which all custom clients have a client side version of to allow for various tree modifications, this caused crashes because there was no indication in the git history of a change to this class.

[loftar]

I don't see reason why you couldn't include them in the git repository as well, even if they would be loaded as res files like they currently are.

Well, mostly because they're already being tracked in our internal ressrc repository, and I wouldn't want to duplicate their history. There has to be some better way. Also, they are internally kept in a different format which is preprocessed to create the source that is actually compiled (and included in the resource file), so you wouldn't have much use for those files anyway.

You'll certainly know if they've changed by the fact that there's a new resource version available.

[Ardennesss]

I don't see reason why you couldn't include them in the git repository as well, even if they would be loaded as res files like they currently are.

Well, mostly because they're already being tracked in our internal ressrc repository, and I wouldn't want to duplicate their history. There has to be some better way. Also, they are internally kept in a different format which is preprocessed to create the source that is actually compiled (and included in the resource file), so you wouldn't have much use for those files anyway.

You'll certainly know if they've changed by the fact that there's a new resource version available.

You imply we somehow track versions, we don't, that's the problem. We have no indicator you went from Trees version 20 from 19 unless 20 causes crashes.