Hacker News Reader

Comment by kaolinite | Hacker News Reader

Maybe he just wants to make his game, perhaps not a game for you or many other people - but his game. For him. Not everything has to be simplified and dumbed down. We have plenty of those kinds of games.

Also, I'm confused by your shock that an ASCII game can bring an 8 core desktop to a crawl. Just because most games spend most of the system resources on displaying pretty graphics, doesn't mean that DF has to as well.

View on HN

I'm sure he does just want to make his game. I'm also free to criticize the glaring shortcomings. There is VAST room for improvements without dumbing anything down. A perfect example of this is the fact there are two ways to draw rectangles for designating areas for trash vs mining. What on earth could be the reasoning behind that and how would fixing that be 'dumbing' it down?

What about the nonesense up/down stairs. How many thousands of dwarfs have perished at the bottom of a Down only stairway they have just dug, only for the mistake of not designating the stairway as both capable of upward/downward movement. So you watch, helplessly as all of your miners slowly die of thirst in a hole 6 feet deep a foot away from everyone else.

Playing chess by moving the pieces around with your hands is surely easier than rolling them around with your nose, but I would hardly call it 'dumbing down' the game.

First make it work. Then make it elegant. Then make it fast.

DF is at stage 1 now, and I think it's very reasonable to postpone ui polishing and optimisations till all the features are in place. Otherways he would need to constantly rewrite optimizations and the structures that allows speeding the game up, to kep up with new features. Which will take much longer in the end, and could kill his enthusiasm, ending the project.

Isn't the game 11 years old? What is a reasonable amount of time to spend before moving to stage 2?

As long as he wants - it's his project.

Amen to that. Where does everyone find their sense of entitlement?

I don't feel entitled I feel a tragic sense of loss knowing how much better it could be.

Eh, I don't know. Part of what makes Dwarf Fortress unique is its meticulous attention to detail. Tarn has so far been able to concentrate so fully on the game's simulation aspects by mostly ignoring things like the UI and optimization.

Could he hire on another person to work on the non-simulation bits? Perhaps. But that takes money. Tarn makes donation information public, and he makes between $40k-50k a year before taxes and the ~$800 a month he pays his brother for the help he provides. Enough to support himself, but not nearly enough to hire on another full time person.

Not to mention there are already other games out there attempting to emulate Dwarf Fortress (Gnomoria and Towns immediately come to mind) in a more user friendly form, but neither of them yet come close to intricacy and scale of Dwarf Fortress.

If he opened up the code I'm sure people would do it for free. If he doesn't want to open up more of the code I bet there are scads of people who would do it for a cut of the profits. And yes if he doesn't improve things eventually a competitor will mop the floor with him.

Tarn, the creator, has said that Dwarf Fortress might be the last game he ever creates. He may still be working on it 20 years from now, and it may still be in a pre-release state at that time.

> Isn't the game 11 years old? What is a reasonable amount of time to spend before moving to stage 2?

I'm guessing you don't program?

I am of the opinion that beyond a certain level of complexity Stage one depends on Stage two. DF has been there for quite a while. Stage 2 should be done in tandem with stage 1.

That's cute. :-)

Complexity is like beauty though. A programmer can turn something as trivial as a command line calculator into one of the worlds greatest feats of engineering.

Where you are mistaken is your assumption that given enough time, every programmer will follow a predetermined structure.

Our tools may require logic, but that doesn't mean we must behave logically.

I understand that no two people will design any system identically, but for many situations there are 'obvious' solutions.

Regardless of that, well engineered code is far easier, more flexible and waaaay faster to maintain in the long run when compared to a mess of quick dirty hacks to get passable results. It takes no time at all for the hacks to impede your ability to make changes to the system.

Early in a project it's often difficult to get the design perfect. Requirements are refined and unforeseen engineering challenges crop up. When this happens your existing design pattern may no longer be a perfect fit. This is how I approach it:

I think about what the new 'ideal' or obvious solution is considering the new challenge.

If that solution is not practical to implement. I may try to engineer around the problem in a way that is consistent with the design of the rest of the system. While it may not be the 'optimal' solution the next developer who needs to get in there and change something will readily understand what's going on if they are familiar with other parts of the system. I like to call this 'fractal' design.

I rarely encounter a situation that I cannot solve via the ideal or fractal approach. But only after I have ruled out both do I allow myself to resort to hacks.

Regarding the inefficiency of the engine. There is something seriously FUBAR with the design when you must choose the size of simulation (the rendered rows and columns of ASCII representing the playable zone in the window not the physical dimensions) at the beginning of a game before embarking. The performance of the game is directly proportional to the number of blocks in this zone + the number of dwarfs and NOT the actual stuff happening to them.

The bad part is that you have to completely start over and embark with new dwarfs if you decide that your system can/can't do a bit more and you wish to adjust the size of the zone.

Current hypothesis on the forums is that he uses some simplistic variant of A*; in extreme situations everything pathfinds to everything else once a tick in a totally serial program. The player base sometimes resorts to weird hacks and layouts to reduce the branching complexity of the path finding, but ultimately the more loose stone and objects you have to pathfind off and the more things you have pathfinding the worse everything gets. You don't even have to have a large number of dwarves for it to crop up; sheep are capable of bringing your machine to its knees if you don't ruthlessly cull them, or notoriously the catsplosion problem.

Last time I played it, it wasn't that bad. It was like a year ago, before that minecart updates. People are exaggerating a bit or performance went worse?

Nope, it's about the same, if anything I believe there are some improvements...which just mean your system gets pushed to its knees doing something even more crazy.

I would love to see a bunch of hard hitting engineers focus on optimizing DF with multithreading and GPGPU stuff. It would probably require a full rewrite. Having some experience with AI and pyopencl physics simulations I have no doubt that DF could be many orders of magnitude faster and capable of sooooo much more. That's really where my angst stems from.

> [...] focus on optimizing DF with multithreading and GPGPU stuff.

You should probably start with algorithmic improvements.

It could go either way IMO, GPGPUs are super great for naively simulating a bunch of different blocks in parallel.

> There is something seriously FUBAR with the design when you must choose the size of simulation (the rendered rows and columns of ASCII representing the playable zone in the window not the physical dimensions) at the beginning of a game before embarking.

Minecraft does that (the fog distance).

Fog distance can be changed on the fly, though. You don't need to start a new game to adjust it.

"There is something seriously FUBAR with the design..." I call shenanigans.

I would like you to point out another reality simulator where you can dynamically resize the simulation. Can you ask SimCity "hey, generate me a few extra acres of The World around my periphery"? Or chop it back off again?

A fixed-size simulation is the norm. Anything else is fairly exceptional (and even Minecraft has caveats). What's different here is that you get to choose the size of the simulation in a very customizable manner.

I wrote a nbody gravity simulation that allowed this at one time. http://code.google.com/p/stableorbit

I believe that the ASCII isn't true ASCII, though, as I believe gnabarian said - which is part of the problem.

This post has more: http://gaming.stackexchange.com/questions/24693/pseudo-ascii...

Normally the DF executable works like a terminal emulator, rendering the glyphs using GL or such. You can however run dwarf fortress in a console (ie, to run it over SSH) by changing the configuration file, and then it is a true text game.

BTW it doesn't use only ASCII but a larger subset of unicode. ASCII would be a very restricted set of characters to use.

> to run it over SSH

Cloud gaming. I like it.

multiplayer next?

More a matter, I think, of being able to run it in a screen session at home, then detach and pick up again from elsewhere.

It uses a mix of graphical tiles and text, it's not all just an array of unicode. They're sufficiently decoupled now that you can have most text rendered nicely using truetype fonts alongside whatever graphics set you're using.

Reply on news.ycombinator.com