Policy Change: Open Source Code

[loftar]

After some discussions, Jorb and I have decided to make the source code for the client open source. Most of the aspects of it are covered on the documentation page about it, but I'll go over the most important aspects here:

* What we are releasing is the code for the client proper -- not the game resources, not the server and nothing in between.
* The client code will be released under the LGPLv3.
* If you write anything and would like it accepted back into the mainline client, our main condition is that you transfer ownership of the code you wrote to us (like the FSF does).
* The source code is available in a Git repository.
* No significant cheating should be possible by hacking the client.
* You may not like my coding style.

Again, all these points are covered more in detail on the documentation page. Please read that page before reflecting on the short, short summary above. For the legal details please see the COPYING file of the source tree itself.

[loftar]

If I may add a wish-list of my own, my main lacking while writing the client is in knowledge and experience of OpenGL. I would really like it if someone who has actually used OpenGL for anything outside of just drawing sprites with it would check out why it's so ungodly slow, especially on some hardware. (It should be mentioned in regards to that, that the client used Java2D originally, but it turned out to be completely unbelievably slow when drawing anything that was alpha-transparent, and that was our main reason for switching to OpenGL)

[skrylar]

I believe some of the performance will be difficult to track down because of how schizophrenic the client is laid out, I've been reading parts of the java since before this announcement and been looking in to how to properly rewrite most of this to be better organized than it seems to be and have a better interface (a few goons and I already use a modified sound pack).

Since you've opened up the source (yay) I'd like to offer (with your blessing, of course) to start a new client from scratch that will be built by myself and a few members of the community that I know are already interested and willing to do this as well as help improve the general game GUI. I ask because in doing so if we are going to help redesign and reskin the interface, we will need to set up some kind of communication method to send improvements that you have to implement on the server side (as the current GUI code is too thin to do this ourselves). This new client will also be open source, but written to run on mono/.net cleanly (meaning it'll keep working everywhere it's being played now) and avoid having to use some of the horrible hack-arounds Java forces on you (the wav reading code for example, is a mess full of overflow checks because Sun decided unsigned types aren't needed).

Looking forward to working with you if you so choose,
-Skry

[loftar]

Well, I can't really bless anything written in the abomination that is the CLR. I have to admit that I wouldn't replace the current client with something written for it. I may dislike Java, but there are things I dislike worse (though I do have to regard the .NET guys slightly higher than the Java guys at least in the aspects of adding tail-call optimization and, indeed, unsigned integer types). However, if you want to do that and maintain a "second" client, then all the luck to you.

When you speak of server changes, what, more exactly, would you be referring to? A large part of the UI protocol is very much intended to be as it is to keep the freedom on the server side as large as possible and to decrease, to the greatest possible amount, any possibility of cheating on the client side.

[skrylar]

Well, I can't really bless anything written in the abomination that is the CLR.

Understandable opinion, though I meant mostly on the project than the medium

A large part of the UI protocol is very much intended to be as it is to keep the freedom on the server side as large as possible and to decrease, to the greatest possible amount, any possibility of cheating on the client side.

Keeping the UI on the server side as it is now only serves to decrease the performance of the interface (when sending a message it has to send down window activation packets, then window send packets), if we wanted to add graphical emotes or move the chat panel to appear when you press enter (as many RTS/RPG games with haven's graphical perspective support) we would have to intercept window events and find the one with ID16. Not to mention when clicking on the action bar to the right, a packet has to be sent for the click and the server reconstructs the menu. When testing locally this shows no performance penalty, but on more restricted lines and congested connections it can cause a perceived drop in performance (perceived performance is real performance, as far as users are concerned). To support UI skinning we also need to intercept and override the server's idea of the interface and interpret it to what we want it to be, while I can surely do this it also takes about half of a second to break. World of Warcraft is perhaps one of the most prevalent examples of an MMO that allows skinning and moving parts of the UI around to benefit the player.

You would likely save bandwidth and precious server CPU time moving at least small parts of the interface handling to the client and instead sending more generic events. One example is the stamina and authority bar, which as far as I can tell are updated in separate packets and by full text. You could easily send the entire character status in a single IP packet with a CHAR_STATUS tag and save plenty of bandwidth (count the size of each update, multiply it by the amount of bars characters have weighted by how often stamina/hunger/authority are updated, multiplied by the average player count, not to mention the packet acknowledgements for each microupdate).

Most cheating comes from actions that the server is overly trusting of the client to perform, and most dupe bugs are where the server is not acting with item references atomically.

[loftar]

I do, at least half-way, agree that some parts of the UI, especially parts of the HUD, may very well benefit from abstracting the protocol a bit. I'm a bit split in the issue, though, and in fact I've been quite split on it for a very long time now. On the one hand, it's very convenient to keep as much as possible on the server, because it means I can just update game mechanics and UI in one go, without having to touch the client [which has the added benefit of not having to do any Java programming ;)]. In particular the meters of which you speak have seen quite some changes (though that was probably before you SA people got here, I think), which were made very convenient by being able to do all the work on the server alone.
On the other hand, it would make quite some sense, especially now that I've publicized the code, to make the UI more alterable by users -- that is, without having to touch the client.

As for the particular problem of having to send multiple packets for simple things, though, I had rather planned on fixing that by sending several "sequenced messages" in one single IP packet; that would have many benefits anyway, but it requires changes to some data structures on the server (if it weren't for that, I'd have done it long ago).

As for WoW, I've read through parts of its protocol at some time (on a reverse-engineering site, that is), and I think the problem with that, which I want to avoid, is that the protocol is burdened with a message type for every little thing. It's just ugly. As for Haven, there are better ways of making the UI skinnable, and I think I can promise you that I'll be thinking about them, at the very least.

However,

Understandable opinion, though I meant mostly on the project than the medium

It strikes me, now that you mention it, that you'll be having trouble making a feature-complete client on the CLR, at least without running Java bytecode. Some resources contain some integrated Java code that is loaded on demand -- in particular, such things as some special sprites and some of the rarer UI elements.

[kimya]

i think this is a very good and somehow brave decision! im totally looking forward to a lot of interesting and practical changes in the ui

[loftar]

im totally looking forward to a lot of interesting and practical changes in the ui :)

Are you implying that there are aspects of the UI which are somehow... suboptimal? :)

[Coriander]

The opinion of an admitted, non-tech savvy, game player:
I am all for fewer glitches, increased reliability and less lag. However, I think I would rather put up with these issues than have a hackable game that can give one or more individuals an unearned advantage. If exploited, such an advantage could be a game killer.
Again, I look forward to the possible improvements.
Great work guys and Thank you!

[Delamore]

The opinion of an admitted, non-tech savvy, game player:
I am all for fewer glitches, increased reliability and less lag. However, I think I would rather put up with these issues than have a hackable game that can give one or more individuals an unearned advantage. If exploited, such an advantage could be a game killer.
Again, I look forward to the possible improvements.
Great work guys and Thank you!

Java can be opened with no issues at all, any hacks that were going to be made could have already been made regardless.