Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Kdansky

Pages: [1] 2
1
DF Suggestions / Re: Partial Reveal
« on: October 01, 2009, 01:37:49 pm »
One can always talk about what would make good default settings. But forcing everyone to play at a difficulty which you like is not a sensible thing. Nothing bad about cheating.

I would very much like a standard quit-without-save option, so I can try stuff and experiment with the game (for example, with magma physics). If you don't want to save/load, then don't do so. No reason to forbid it to me.

Of course you can mod your dwarves to be invincible, but it's rarely going to be very interesting in the end. But would you as a beginner want to play Federer in a Tennis-match? Or would you rather prefer to start with someone a bit closer to your own level?

2
DF Suggestions / Re: multithreading
« on: October 01, 2009, 01:29:16 pm »
It might be a good idea if those who do not have actual experience on this very intrinsicate detail of software design* would not bother to comment. This thread is quite painful to read for someone doing this on a professional level, as then nonsense sproutet knows no bounds.

A very feasible way to do MT in DF would be to wait for some open source people to re-implement Grand Central Dispatch (google it) as a C-lib, and then refactor the whole game with those techniques in mind. That is rather easy to do and the library should take care of all the difficult stuff. In the meantime, having to bother with synchronisation locks and all that crap is just not worth the hassle, especially for a single-person team who might not have much experience on that matter. And last but not least: On two cores you get +100% FPS in the perfect case (assuming it is just about distributing load evenly). Which frankly, is not a lot, considering you'd have to re-implement everything. If you could just make your one bottleneck algorithm twice as fast, you'd get the same performance boost, without even needing to touch MT. Most programs have very prominent bottlenecks and are rather easy to optimize in such a way. I doubt that DF get profiled on a regular basis.

*MT is not by default difficult. Every piece of software uses it, to prevent the horrible "application does not react at all while doing X". That stuff is fairly easy, and rarely problematic in implementation. But for DF, that's not the issue, it's about performance, and *that* is not trivial at all.

3
DF Suggestions / Re: Partial Reveal
« on: October 01, 2009, 04:04:33 am »
And you seem to be missing a major point.

Highlighting the different minerals from embark is cheating.

Are you telling me that my way of playing a game is wrong?

There is no such thing as cheating in a game where you cannot win against another player.

4
DF Suggestions / Re: Making the game faster
« on: September 30, 2009, 11:09:04 am »
Ask yourself if you would even play DF if the user interface was important to you. And if you don't play DF, you probably are not in this forum. Therefore we rarely see people here complaining about the UI. They also get flamed every time they bring this issue up ;)

And I'm also excited about the detail and ludicrousness. But I would gladly miss out on 10% of that if I could get a halfway decent UI in exchange.

5
DF Suggestions / Re: Making the game faster
« on: September 30, 2009, 09:57:47 am »
Quote
You can't seriously improve the UI until most of the other features are finished.

Wrong. Putting the entries in alphabetical order would improve them. They would still not be great, but at least you could read them instead of having to memorize them by heart. I have not played DF for half a year and picked it up yesterday. It's such a pain when you want to build some building and cannot find it in the unordered menu.

The game already has a sorting mechanism for entries in menus (seen in the job manager), therefore this would be very simple to accomplish.

And this is only an example of what could be done with very little effort but high reward. Of course complicated interfaces cannot be finished before the mechanics work, but that is not what I am rooting for (yet). It's like those games which limit your hotkeys to a small number such as 8. Easy to fix, worthwhile result.

6
DF Suggestions / Re: Making the game faster
« on: September 30, 2009, 09:04:04 am »
double post, I'm stupid.

7
DF Suggestions / Re: Making the game faster
« on: September 30, 2009, 09:00:46 am »
It is a difference in marketing. Dwarf Fortress is based upon being ambitious and almost entirely uncompromosing in its vision. That is why people like it and that is the whole point to the game.
If Toady concentrated only on what was needed to make this game fun. It would be done by now except you wouldn't be here (and likely I wouldn't be either). Except that wouldn't be Dwarf Fortress.
Now years down the road when the game finally gets closer to release a lot of these features you want (such as improved UI) will be added to the game. You just need to be patient until then.
I find it risky to delay important features five years into the future and instead add eyelids to all creatures. Toady might lose interest, get sick or have no time. And then we'll never see those features. I know too much about game or software development to be patient for such a long time (Duke Nukem called and said he agrees with me).

Quote
No. If games have taught me anything is that developers loathe AI.
Sadly true. Even though it's such a fascinating topic and a lot of fun to work at. DF is no exception here. But that's beside the point: If you can spend your time on a project, figure out where it matters most. Do you really have to render the jiggling of boobs in excruciating detail before you even get basic gameplay done? (Graphics are a major offender for big-name titles, they swallow up all resources and in the end, we get boring games). Toady does the same, only "eye candy" equals "simulated details" to him.
Quote
See now the humans are planned to be fully playable in the future. So yeah SURE the Dwarves could look amazing now, but that would harm future development.
Nothing prevents you from adding the human stuff then. I have trouble coming up with a reason why a more streamlined menu structure (such as alphabetically sorted menus) could ever harm future development. Worst case the time spent on it is wasted because it has to be changed from scratch. That is why one starts where very little time matters a lot, as only very little time can then be rendered pointless. if you spend three hours on menus, at worst you lose three hours of work in two years when you have to overhaul it. In the mean-time (two years!) you had a far more usable version and everyone could enjoy it much more. That's acceptable. Iterative development is very reasonable.

Quote
Couple Hundred? You need to increase your numbers quite a bit. Dwarf Fortress didn't start development this year and even then he has likely wracked up numbers in the thousands of hours for just this year so far.
I know. Things I would want to see could get done in less than 40 hours for sure. I don't root for an AI that's more intelligent than Einstein, I want sorted menus, low/high priority labour assignments, basic mouse support, streamlined hotkeys and something along the lines of Dwarf Manager.

I always get into DF and then lose interest because the thing is so damn unfriendly to use. It's just not much fun to go on a drive when you have to push your car 80% of the time instead of driving it.

8
DF Suggestions / Re: Making the game faster
« on: September 30, 2009, 08:20:37 am »
Quote
This is one of the reasons why developers don't even show their games, outside of fixed demos, until it is almost done. It simply looks incomplete and the community often will judge early development as if it were going to be in the game already.

Toady is less then 20% complete and many of the things he is doing won't add to the experience until far down the line. Heck the Carrivan Arc itself is somewhat uninteresting when you think of what it actually adds but it is nessisary to almost everything else the game requires (as in essence it allows locations to actually have inventories). There is a reason why "Carrivan Arc" is Toady's Catch phrase.

Even though your general point ("Implement content before Interface")  is sensible, that still does not make spending hundreds of hours on something nobody ever realizes is there a clever time-investment. RPGs usually abstract wounds with simple HP. Why? Because that is about as complex as it is necessary to enjoy the game and very easy to implement, leaving the developers to work on something more interesting (such as AI).
More complexity does not generally make the game better (in a sense of enjoyment gained by playing it), only more complex. But it is (or can be) very fun to implement. I write code for a living, I know the difference between code that is important for the project and code that I like to write very well.

To give an example: If you can spend 10 hours to either make pretty graphics for dwarves or humans, then you should spend it on the dwarves, because the player will look at those nonstop while only rarely (if even) see the humans. And if I could spend a couple hundred hours on DF code, I'd certainly not start with giving dwarves eyelids or toenails. The simulation probably is less realistic after you have added eyelids, because now things *can* go wrong, whereas before they were assumed to be fine (e.g. Washing the eyes with Soap, check the dev blog). Abstraction exists for a reason.

9
DF Suggestions / Re: Low Priority Labour
« on: September 30, 2009, 06:52:57 am »
Well, sorry for accidentally something twice. Great minds think alike.

To me it looks like the suggestion forum drowns the important, useful and simple ideas in a host of irrelevant, situational and incredibly complex suggestions. See the first page for reference.

10
DF Suggestions / Low Priority Labour
« on: September 30, 2009, 05:13:53 am »
I want to add another suggestion that should be comparatively easy to implement and have a big impact on gameplay: Instead of Labour being a YES/NO toggle, it should be YES/MAY/NO. What I mean with this: In case there is not work to be done for the major profession, the dwarf will get himself a single job of his secondary job and then check again if anything important is to be done. This way, Bored dwarves can be put on Hauling or Smoothing, Miners have something to do when there is nothing to be mined while nobody ever neglects their primary task in favour for hauling stones. But still, stones get hauled by those dwarves that have nothing better to do.

Also: Sort the menus by alphabet. That should be a one-liner (+sorting algorithm) and improve the gameplay A LOT.

11
DF Suggestions / Re: Making the game faster
« on: September 30, 2009, 04:46:22 am »

Yeah, boy. Toady One spent the last year- literally the entire last 12 months ending this last July- working on making the body parts MORE complex.  Down to EYELASHES.

Which is a colossal waste of time from any perspective that is not "I had fun writing the code" (which was the primary reason for starting this project anyway). The difference between two games with and without these changes will be negligible in most cases, a Dead complex Dwarf is the same as a Dead simple Dwarf. At the same time, those 12 months could have been spent on pathfinding, job priorities and user interface, which would have benefited everyone playing it. Alas, toady is not writing DF for the players, he's writing it for himself.

12
DF Modding / Re: Dwarf Therapist (LATEST 0.3.2 9/13/09 see first post)
« on: September 30, 2009, 02:22:01 am »
Without having read the thread: It would be useful to see the current job my dwarves are doing, so I can reallocate all those lazy idlers.

The sad part is that we need a memory injector in the first place :/

13
DF Dwarf Mode Discussion / Re: Integral of user interface vs time
« on: May 21, 2009, 06:36:32 pm »
Even though I think a mouse-driven UI would be nice, I am still a big fan of hotkeys. The major issue are inconstencies. I tripped over the floodgates today (linking, building, creating, everthing on another key, with unsorted menus makes for a big headache), or this one: Removing stuff from the job queue uses the R(emove) key, whereas everywhere else it's the C(lear) button. Oh, except Gems, where C(ut) is taken, therefore R(emove )is used too. Talk about messy. F9/Esc/Space is a common one and gets brought up repeatedly.

The game does not feel very alpha to me. With 20 hours spent on interface, and three man-years on graphics (because graphics are more important than anything else apparently) you could release that in a box. Bugs are few, gameplay is solid.

I do have a pretty idea for a nice interface (which would reduce micro A LOT), but it would be a lot of work, that's why I didn't bother writing a suggestion on it. I might.

14
DF Gameplay Questions / Re: They take glee in suicide
« on: May 20, 2009, 04:49:04 pm »
I have chosen the dwarfish way of solving it: Equipping my army with decent weapons and sending it over to clear the map. So far, it has worked very well.

15
DF Gameplay Questions / Re: They take glee in suicide
« on: May 20, 2009, 03:45:28 pm »
But that also means that they won't pick up stuff that enemies drop inside my trap-infested base, which is not very practical either.

And another problem: I experience brutal slowdowns (which is new), without any fluids doing much. Is this path-finding? I have recently made my fortress bigger to be able to house more dorfs. If yes: Is there a work-around to make path-finding faster? Such as building more/less ways from A to B?

Pages: [1] 2