Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[fetdaniel]

Hello dear fellow dwarf fortress community.

I am making a game in java and I would like to implement something similar to the raw text files in my game to facilitate for modding. Without any real knowledge about dwarf fortress programming I still guess that it's a combination of c++ interfaced openGL, and a scriptlanguage. A very uninformed guess it is but nonetheless..

I have the general engine data structure sort of implemented but when it comes to specific implementations of things like entities, flora, actions/events, storage containers, etc.. I have no good idea how to do this with text files without preloading all texts as instances of predefinied classes, to me that makes modding a bit too inflexible. My other solution is trough the use of interfaces and mostly using one class per object. This flexibility is mainly to make as small memory footprint as possible with each object since there will be tens of thousands of them. Yes indeed enough to win the siege of helms deep actually. Which is well over 9000, as the perceptive will note... I am trying reach one million active entities, simulated over an area 25% of the earths area with one tile = 1sqm. And that is why memory is a big issue, as is implementation of actions since they will be happening alot. In short the game is based on an old idea I had that is similar to dwarf fortress, especially world gen, that I had before I found this wonderful gem.

I'm self learned in Java except for a simple university course that thought the basic syntax and some very simple instancing. Now I use eclipse and my skill has improved with learning by doing it wrong, and trying again. Fearless and passionate as I am about my design, (leaning dangerously towards careless and stupid) this is my first big project and I haven't made any previous games only small keyboard input + graphic vectorfun funky stuff. Any wizards out there who can explain to a layman or point me in a good direction on how to flexibly and as performance friendly as possible implement such a datastructure that ideally ALSO implements textfile reading like the raw:s. Sincerely hoping I am making sense.

PS: A good solution implies and would aim to make adding objects a breeze, the magic would be in the framework. I thought it would be good to be clear about that, since I'm writing at 4am swedish time.

//Daniel H

[Montague]

Java is buggy, filled with its own spaghetti programing and it is memory/ram intensive.

You could always write it in machine code.

[Xgamer4]

Java is perfectly fine and only really suffers from old, incredibly pervasive, rumors about speed. Ignore Montague.

As for your guesses on Dwarf Fortress, from I understand, there isn't a scripting language and the raws are parsed in at world creation was instances of predefined classes. So, basically, exactly what you said.

As far as I'm aware, I may be wrong. Only Toady knows the real answer, and he's never really been much of a fan of talking about specific code details or implementations.

[Caldfir]

It would probably be easiest to pick up some information about writing/parsing xml files.  Had xml been as popular at DF's inception as it is now, it is very likely Toady might have opted to use it in stead of writing his own scripting language from scratch. 

[Cyntrox]

I agree with the XML suggestion - it is at least as powerful as the raws are, and there's no doubt java libraries for it.

[jaked122]

I honestly don't like XML, you do not want Java for Dwarf Fortress, it is an interpreted language, it does not compile into machine code, it goes to bytecode: this bytecode must be interpreted by the VM, hence good java is almost always slower than mediocre C++. Besides, If you were going to write the raws in XML, then you certainly don't need to resort to Java, there are plenty of C++ libraries for it: TinyXML and Xerces XML libraries for that.
There is another problem with XML, I cannot envision how it would be used to parse the Body structures, they seem to be sequential, and XML is fine for nesting, but I find it difficult to envision the way that the data in such a structure would be stored elegantly, the only way that I have been able to visualize the syntax of the structure is just spagetti data.

[Umune]

From what I gather, the real problem is that Java doesn't scale well to larger projects. It can be fantastic for smaller jobs, but just fails for the larger ones.

[YetAnotherStupidDorf]

I find here so much misinformation and misconceptions about Java... this is utterly hilarious. About only true thing spoken here is about slowness of Java (sorry Xgamer4, you seem to live in denial). Especially Montague is obvious troll with his "advice" about programming in machine code. Lol.

Oh, and BTW raws are not script language - this is just data. If you really want scripts, not data easy to change by players, I would got interested in something that was already written by others, like Lua. I do not know if Lua will fit your needs, but why reinvent wheel for milionth time?

[fetdaniel]

Java is buggy, filled with its own spaghetti programing and it is memory/ram intensive.

You could always write it in machine code.

AFAIK java is written in C and many classes are quite fast as a consequence, thus benchmarks exist where Java is almost as fast as C, but since I use selfmade classes prominently Im not sure how it compares to C and its peers, I'm guessing its quite slow. But I have tried using my objects in large extended tests and found that it's really sufficient for my game as long as I am aware and clever in my implementation.

Spaghetti programming is really goto programming, I did it myself 15 years ago when I played around in simple commodore 64 basic/and later Qbasic. Since java doesn't have a GOTO argument I'm not sure what you're getting at...

Java is what it is, I use it because I know sort of how it works in this context, and I really like OO because of the type of logic, flexibility and great performance it brings. The biggest real issue in language programming performance is wether it takes me two or fifteen years to implement the game. Instead of just barely making something hold together with stitches after quadruple time spent with C, I implement fast and can increase performance and still implement faster and have a more agile design document. Java is very forgiving and failfast when I mess up, and debugging has so far been really good, and eclipse is a simply awesome IDE. The current data structures are really fast and efficient and with a semi modern computer (>1GHZ) you wouldn't believe how man operations is possible per second...

Dwarf fortress implements very consuming pathfinding and temperature calculations and flowmechanics. etc, which C probably is a better language for.

Bottom line is I know Java and the speed won't be an issue. And I simply don't speak 01010, I'm sorry.

[fetdaniel]

Java is perfectly fine and only really suffers from old, incredibly pervasive, rumors about speed. Ignore Montague.

As for your guesses on Dwarf Fortress, from I understand, there isn't a scripting language and the raws are parsed in at world creation was instances of predefined classes. So, basically, exactly what you said.

As far as I'm aware, I may be wrong. Only Toady knows the real answer, and he's never really been much of a fan of talking about specific code details or implementations.

Thank you, you are probably right. The reason I ask is since I'm just guessing there are really advanced ways of dealing with classes in c++, and I wonder if that how it was done. Java has reflection, which along with interfaces can make really flexible classes at runtime, but I just guess it's painfully slow.

I just want it clean and fast enough, and really make it simple to make ingame objects and definitions. Perhaps I'll learn a scripting language, or I'll just use interfaces and forget about modability.

Or I'll use predefined classes and try to compress memory footprint at runtime, as you guessed DF does it.

[fetdaniel]

It would probably be easiest to pick up some information about writing/parsing xml files.  Had xml been as popular at DF's inception as it is now, it is very likely Toady might have opted to use it in stead of writing his own scripting language from scratch.

I've heard alot of good things about xml. Thanks I'll look into it! Thanks to Cyntrox too.

[fetdaniel]

I honestly don't like XML, you do not want Java for Dwarf Fortress, it is an interpreted language, it does not compile into machine code, it goes to bytecode: this bytecode must be interpreted by the VM, hence good java is almost always slower than mediocre C++. Besides, If you were going to write the raws in XML, then you certainly don't need to resort to Java, there are plenty of C++ libraries for it: TinyXML and Xerces XML libraries for that.
There is another problem with XML, I cannot envision how it would be used to parse the Body structures, they seem to be sequential, and XML is fine for nesting, but I find it difficult to envision the way that the data in such a structure would be stored elegantly, the only way that I have been able to visualize the syntax of the structure is just spagetti data.

I'll heed your warning about XML, I will look it up really and only use it if it feels alright. About Java, I've heard it slower, I do think its slower but haven't compared myself. The thing is that it's probably fast enough for my featurelist and It's really fast to implement stuff and OO keeps the code structured and easy to read. Java is failfast in many situations, and there are LOTS of times I have tried to access uninstanced references of arrays... Writing 1 and 0 where it's not supposed to be in memory is a pretty big ouch I figure...

Regarding speed I must say implementation > language speed. In the beginning Java was said to be 20 times slower which I guess means the worst case scenario these days, if JIT messes up. Compare this to unnecessary access, or instancing of 2d arrays the size of 8000x8000 * alot... Instead I access smaller chunks of 20x20 which is considerably smaller but the interface is still the same as the previous example due to some semiclever quadtree-like structure. This is what makes a difference. Having a schedule-coupled-with-queue check entity changes instead of looping trough each and every entity at each frame makes a difference. Checking entities far away once every tenth second instead of every frame makes a difference in the size of 4000 times per ms! (Making clever interpolations when approaching entities instead.)

I could go on, but my point has been elucidated as far as I'm concerned. But hey, I'm not saying you're wrong I'm just saying I'll manage.

[fetdaniel]

From what I gather, the real problem is that Java doesn't scale well to larger projects. It can be fantastic for smaller jobs, but just fails for the larger ones.

This might be true. But it's not very uncommon with Java in enterprise programming AFAIK. The thing that i personally don't like with Java is that some part of the API is really clunky interfacewise. The challenge with API:s is really to try and think like they did, which is not really easy and goes beyond the simpler logic of making everything yourself at a low level, but this is true for all code reuse.

[fetdaniel]

I find here so much misinformation and misconceptions about Java... this is utterly hilarious. About only true thing spoken here is about slowness of Java (sorry Xgamer4, you seem to live in denial). Especially Montague is obvious troll with his "advice" about programming in machine code. Lol.

Oh, and BTW raws are not script language - this is just data. If you really want scripts, not data easy to change by players, I would got interested in something that was already written by others, like Lua. I do not know if Lua will fit your needs, but why reinvent wheel for milionth time?

Thanks, i've seen lua in proffesional applications and heard good about it before. I will probably check it out.