Technical details about the development of H&H

[ArvinJA]

I'd be interested to read about the technical bits of H&H, the process and so on.
What things have not been implemented because of lag/performance issues? What are some bottlenecks that have appeared after going with a certain model of how the game should work? What strokes of genius were had during development (solutions you would be proud to share)? Basically I'm interested in the technical story behind H&H, it could be how the world is rendered, how everything is stored and so on.

[RangerRyan]

I'm not one to know, but after a few weeks playing these forums, I learned a little bit from threads here and there.

1)The client is run via Java
2)Almost all of the storage is on a server-dedicated computer (Not sure about this)
3)Most of the lag is from so much information going through ONE(1) computer, and also the time that it takes for the information to go back and forth.
4)Jorb draws the sprites (How else do you think the 1-million-and-1 cod related sprites got on here?)
5)Loftar implements the coding and so on.

That's all I know. If any of this is wrong, someone feel free to correct me.

Oh yah, almost forgot this one:
6)The server is run through SQL/CSS I believe, I'm not sure on that one.


Edit: Accidently wrote "Javascript" instead of "Java"

[boshaw]

1)The client is run via Javascript

Java, not Javascript

[RangerRyan]

Sorry, slight typo

[Zampfeo]

3)Most of the lag is from so much information going through ONE(1) computer, and also the time that it takes for the information to go back and forth.

According to Loftorb, lag is due to hardware issues with their NIC that causes it to "trip".

[MagicManICT]

Server is written in C if I recall correctly.

[loftar]

Hm, I can't really think of any particular tidbit that might be of special interest. If anything, I think the future is more interesting than the past.

There are quite a few things that have turned out to be hard to implement because the current object system of the server has broken down a bit under increasing requirements for code modularity and genericness, such as the new substance system I've long wanted to implement, general combinations of mechanisms or quite a few AI mechanics. And that is by no means an exclusive list.

Therefore, after quite some time of deliberation, I started working on a new object system for the server during the spring of last year. I had just gotten the basic system working and was in the early stages of rewriting the actual game mechanics of Haven using the new system when Salem came knocking on the door, which interrupted work on it for some time. Then, on the other hand, when I really started working on the Salem server, I finally got to use the new object system for it, given how there was none to little existing mechanics that had to be reimplemented in it, and it has been quite a joyous process so far. I am, even more than previously, looking forward to reimplementing Haven in it as soon as work on Salem allows for it.

The new system is heavily influenced by the CLOS but, of course, adapted for use with C instead of Lisp. It features a type system with multiple (interned) inheritance (using CLOS' topological type sorting), but with a slot management based on a single C datatype per type instead of CLOS' slot combination system. It also has generic functions with fast multiple dispatch and dynamic method combination (the current implementation calls an external C compiler to produce effective methods), and I've found that there are actually advantages with specifying the system in C, rather than Lisp, in terms of method definition, because I can easily define multiple methods for the exact same specializer lists, whereas CLOS has to intern the specializer lists and replace previous a method with the same specification. This means, for example, that I can declare multiple interaction modes for the same object in several different source files, leading to much improved code modularity (for instance, I could define the "Memorize" action on player objects in the source file that handles all other aspects of kin management, rather than having to do it in the source file that defines most of the player object code, while declaring the "Spar" action in the fighting system source code). Perhaps even more importantly, the decoupling of methods and their containing generic functions means that I can define new mechanics for existing objects in completely unrelated source files; for instance, Jorb has many times wanted to add mechanics that would involve such things as placing existing objects, like perhaps a wood block, on a herbalist's table or something, to produce a resource required for a new mechanic, which I have always denied him on the basis that I'd have to add mechanics to the woodblock itself (where they don't belong, and would therefore uglify the code). With the new system, I could easily declare such mechanics in the source file that contains the new resources instead, keeping all code where it properly belongs, making it much cleaner to tie together pre-existing resources with new ones. And, well, that's just one of many great advantages.

Among the user-visible systems that it has allowed me to implement so far are a new substance system, in which it is possible to drink things from any vessel in which they can be stored (though obviously, drinking wine from a bucket has to be penalized somehow), or for substances to be mixed (or decayed, or anything) into new substances, or for seeds and flour to be represented as "fluids"; and a new tooltip system where certain game mechanics can independently add tooltips for their own effects, such as food items displaying their effective, quality-modified resultant FEPs in their tooltip (of course, Salem uses another system, but just to demonstrate). Internally, it has lead to massive code cleanups in that I've finally been able to unify previously separate implementations for basically the same mechanics into one implementation. I also believe that it will enable me to produce much better AI, though I haven't played around much with that yet, so it's a bit early to predict any results.

[loftar]

6)The server is run through SQL/CSS I believe, I'm not sure on that one.

By the way, this is entirely wrong. I've stated it many times previously, but I avoid SQL like the plague. The only thing remotely related to Haven that uses SQL is this phpBB installation.

3)Most of the lag is from so much information going through ONE(1) computer, and also the time that it takes for the information to go back and forth.

According to Loftorb, lag is due to hardware issues with their NIC that causes it to "trip".

And this.

[MagicManICT]

By the way, this is entirely wrong. I've stated it many times previously, but I avoid SQL like the plague. The only thing remotely related to Haven that uses SQL is this phpBB installation.

If you don't mind me asking (I'm sure it's been asked before, I'm just being lazy), what sort of database system to you use for characters, objects, etc? I've seen some various systems available that have their own strengths and weaknesses.

[loftar]

For storing characters, I use BSDDB. For storing objects on the map, I just serialize them into flat files.