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 - XLambda

Pages: 1 [2] 3 4 ... 14
Programming / Re: Brilliant Observations by My Brother
« on: June 04, 2013, 09:37:21 AM »
You guys should read on some of the procedural generation research being exposited in Michael Cook's Saturday Papers:

Some good stuff application to Zelda-esque level design, or any other procedural design really.

I disagree that a computer can never make anything as interesting as a human-designed level. The problem is finding the necessary rules and restrictions. People often forget that it's not easy for humans to make these levels at the moment - even in this thread there's only a few examples of games that do it right.

Oh, cool! I didn't know this one. Thanks a lot.

Programming / Re: Problems and Pitfalls of Deterministic Combat
« on: May 31, 2013, 08:47:51 PM »
If you remove luck from the combat equation, the gameplay becomes more dependent on your equipment, your skills as a player and...
Let me finish that for you... becomes more boring  ;D (sorry couldn't resist :))

If you fight in real life then one hit will miss, another will succeed. One may call it luck, another will say it's just physics. You may simulate real physics in a RL game, but it's much easier to rely on dice. I think that's why D&D uses them.

I used to play a lot of poker. That game has a lot of luck in it, but there are good players who can tame it and show profit. Coping with streaks of bad luck is a big part of the game. That's why I don't buy your argument. But if you think that determinism is best for your game then you should go for it, I'll be happy if you convince me to it :)

Yeah, but games are not supposed to be realistic. They are supposed to be fun.

I don't say non-deterministic games are bad. But again, I am bad at explaining this. Here's a blogpost by Darren Grey which goes into it a bit more.

Also, deterministic does not need to mean boring. The blogpost I linked above in turn links to an article by Craig Stern (which you should also read) which says:

[...] Real-time games, as a general rule, have an easy time fostering mechanical unpredictability. Spatial navigation requires accuracy and timing; a real-time attack could miss or hit depending on a player’s physical input. The chance of making a mistake in the heat of the moment adds uncertainty, and thus tension.

Without this sort of real-time interaction, turn-based games must look elsewhere for their mechanical unpredictability. Many developers working on turn-based games mistakenly believe that unpredictability is necessarily bound up in randomness. Indeed, there is an assumption prevalent in the design community that any turn-based game without randomness will feel stale, predictable, devoid of tension.

This is a misapprehension, however. Randomness creates uncertainty, it is true, but so do other elements.[...]

But enough of this. The point of this thread is to discuss problems with deterministic systems, not defending their existence. If you are not convinced by my links we can continue this discussion in another thread.

Programming / Re: Problems and Pitfalls of Deterministic Combat
« on: May 31, 2013, 07:54:27 PM »
Do you mind explaining shortly why make a game deterministic in the first place? Sorry if it's been discussed before, it's a novelty for me :)
Argh, other people can do this better than me, but here we go.

Non-deterministic combat comes from rolling dice in D&D. In that game, it's part of the fun. You know you need a 16 to hit that monster, and so it's fun to roll the dice and see what comes up.
In roguelike games you don't roll the dice on your own anymore. In fact you don't even see the rolls you make (with very few notable exceptions). There's no fun to be had there. So the real point of rolling is gone.

The other problem is that it tends to make games very random. Even if you play perfectly and get the right items, some bad combat rolls can really screw you up. Some folks dislike that, because it's unfair. You can't do anything about it. Especially in newer roguelikes people tend to dislike this kind of behavior.
In D&D, though, that's fine. The DM is the one who decides, and if he notices that you happen to have a streak of bad luck, that is really threatening you, he might do something about it. (Or not, as the case of a certain Eladrin shows. ;))

If you remove luck from the combat equation, the gameplay becomes more dependent on your equipment, your skills as a player and your ability to recognize critical situations before they happen. Which to some people is a good thing.

Programming / Problems and Pitfalls of Deterministic Combat
« on: May 31, 2013, 04:47:45 PM »
I've recently spent some time thinking about how a good deterministic combat system should be set up. (Note that my definition of 'combat' also includes interactions that aren't necessarily combat, such as picking locks etc.) I'd like to share my thoughts, and discuss some particularly problematic points that I've come across. Most of this is related to an actual WIP implementation.

1) Keeping the system understandable
For a combat system, I'd say that there is a certain degree of complexity you can go into. The goal should be to keep it simple enough so that the player can actually predict the result of one turn of combat, but complex enough to not make it trivial. 1HP games are a particular offender in this area, as they don't actually have a combat system, so anything relating to combat (like skills, talents and equipment choices) that you would expect to be interesting is going to be extremely reduced and abstract. The other extreme would probably be ToME4, where the entire game is basically one big awesome (semi-deterministic) combat system.

2) Providing a chance to react
This is directly related to the previous point. I've never been a fan of complicated time systems. Things like +10% movement speed in ToME4 are very hard to actually make intelligent use of, and even the better time systems, like the one in Sil, still require a certain amount of calculation just to find out who can move how many times next turn. One area where this is very apparent is the ghoul race in ToME4. The ghouls have a speed penalty of 20%, so every few turns the enemies get two turns. Since this is not only annoying (essentially turning a 2HKO into a 1HKO) but also hard to keep track of, the ghoul race is rarely used by normal players.
I feel that the most elegant time system is the chess-like - you always know how many squares the enemies can move and how many attacks they get, and barring OHKO situations you will always have a chance to react to your enemies' actions.

3) Approximating the intention of the non-deterministic interaction
I can't think of a big deterministic CRPG/roguelike right now. So basically every mechanic we import from a non-deterministic system needs to be converted into a deterministic mechanic. One particular example I'd like to present here is the lock-picking problem.
In most games featuring this mechanic, your chance to pick a lock is based on your stats (say, dexterity and the lock-picking skill). So if you have a lower chance to pick a lock, it will take longer for you to open that door. Anyway, if you have the skill and thus the possibility to pick locks, even if your chance is only 1%, you will be able to do it with a finite number of attempts. However, in some situations (say, the player is poisoned or about to be attacked by enemies) this is not feasible and the player is forced to find another solution (or hope that fate smiles upon him, heh).
A naive port of this mechanic to a deterministic system would result in you being able to always pick locks below a certain difficulty level, and being completely unable to pick locks above that level. This results in completely different behavior than in a non-deterministic system.
One method for solving the lock-picking problem in a deterministic system would be to assign the lock a pseudo-HP bar. Every attempt reduces the pseudo-HP by a certain amount, allowing the player to predict when the door will be open but still consuming the time that the task would take in a non-deterministic system. Of course one can discuss whether this is an elegant solution or not. But it approximates the actual behavior of the lock-picking mechanic in non-deterministic systems much closer than the naive port outlined above.
This is just one problem, but it shows that one sometimes has to change a mechanic quite a bit to achieve a close approximation of behavior.

4) Granularity and the problem of the killer rat
This is something I've run into personally just a few days ago. In almost every roguelike you have your basic beginner monster that is only a threat on level 1 or 2. Later on, they will have a hard time hitting you through your +5 chain mail, but there's still a realistic - albeit low - chance for them to hit and do some damage.
Imagine a deterministic combat system in which armor can reduce damage down to zero. Since the system is deterministic, and the damage enemies do more or less fixed, this completely trivializes all enemy types where damage <= armor reduction. In other words, those rats I throw at you on DLvl5 will be completely uninteresting because they don't even have a chance to pierce your armor.
Now imagine a deterministic combat system in which damage cannot be completely reduced to zero, but to some lowest possible amount which is x. In this case, even completely trivial enemies, like the rats above, can become incredibly dangerous if encountered in large numbers. A situation in which the player is surrounded by, say, 8 rats leads to a loss of 8*x HP every turn (not considering the effect of killing some of them), which may or may not be a lot of damage. The only way to make a couple of rats not hit harder than your average troll is to scale up damage considerably. But this in turn leads to situations like in ToME4. where the player can end up having several thousand HP, with enemies possibly having tens of thousands of HP. Which of course makes the system harder to understand and handle for a human player.
I haven't really found a good solution for this problem yet, and would appreciate ideas.

5) The missing distribution
One of my favorite decisions in non-deterministic combat systems is choosing whether to equip the longsword(3d4) or the glaive(1d12). (I just made those up, they are not from any game). The longsword, in this example, does more damage in average, but the glaive has a much higher chance of doing its maximum damage, possibly finishing off a low-HP enemy in one attack.
This differentiation is completely lost if you switch to a deterministic system. Barring damage types, there can be only one best weapon, and that is the one that does the most damage. So unless you assume a bash/slash/pierce damage system (which of course leads to the golf bag problem), it's hard to differentiate, say, an axe from a sword. For a game that aims to have a high variety of items, that's bad news. And I still haven't really found a way around this.

6) Not making it too puzzly
I kind of like Rogue. It's just the right mix of normal enemies (that require just physical strength and good equipment to beat) and puzzle enemies (that require some specific setup of items and/or tactics to defeat). What I can't stand are games that are too puzzly. We are still roguelike players, not puzzle-game players. Of course there is some interest in puzzles to present a tactical challenge to the player, but this should not be the entire point of the game.
In deterministic roguelikes there is often this tendency to go overboard with the tactical challenges, turning the whole level into 'something that needs to be solved'. This moves focus away from things a dev can spend a very long time working on and putting a lot of love into - clever and beautiful procedural content generation, interesting theme and immersive setting, emergent narrative...
I guess I just don't want deterministic roguelikes to end up being variants of Aaron Steed's Ending where the block things are orcs and trolls. (Not that Ending is a bad game, btw.)

Other Announcements / Re: Reviving the Roguelike Magazine
« on: May 28, 2013, 01:25:03 PM »
Hello everyone,

due to organizational problems and me completely messing up the start of this, we're extending the Call for Submissions to July 1st. Originally, we scheduled the publication of issue one for the beginning of June, which made the deadline ridiculously short. (wtf was I even thinking.) This way, we're getting a bit more flexibility, while still being able to deliver the Fall 2013 issue on time.

If you would like to submit an article to the magazine, please read the Submissions page and contact me at your earliest convenience.

Classic Roguelikes / Re: Dwarf fortress
« on: May 26, 2013, 12:50:48 PM »
Dude I wonder if you can download legacy versions of the game? Surely you can.

Yeah, you can. All of them, to be precise. Here.
I sometimes go back and play the really old versions. They don't have quite as much content as the newer ones, but they make up for it with even more insanity.

Other Announcements / Re: Reviving the Roguelike Magazine
« on: May 21, 2013, 03:30:45 PM »
XLambda. If I were you, I would definitely contact specific people and actively ask for contributions. It's great that you want to do the heavy lifting, but I also love the vision of a magazine situated where the community is at. I've worked a lot with magazines and other publications, both as an editor and a writer, and while I think it's good with an open call for submissions, the chances for getting a contribution is drastically higher if you contact people individually. (Consider that asking someone to write a piece is a bit like asking to interview them.) I think there are a lot of vocal commentators, bloggers and critics who might respond positively. Anyone from Snargleplax to Josepth Hewitt (it would be cool to lure him into writing a really good essay on procedural desgin). You can style a personal letter, saying that you would love a piece about X (related to their special field of interest); but if they have another idea for a contribution, you are open to suggestions.
Hmm, that's a good idea. I'll do that. I'm really a bit shy wrt/ approaching people, but I'll see what I can do.

I'm also sure some proofreading capable people would be willing to read through a single article now and then, or do other "first aid". Some people have been known to perform herculean tasks of community work before ::) I'd offer to chip in with proofreading myself, but am not a native speaker of English, either.

Yes, several people on #rgrd have already volunteered for proof reading. :)

Don't hesitate to contact me if there might be other ways I can help out, though. I hope I'm not coming off as brash in any way. I just got a bit carried away pondering a new RL zine and figured you're interested in all and any comments.
No worries, I can use all the comments I get!

I posted a link to your site on reddit and it got some comments you might find useful:
Ah, thanks! I've already replied to some of them in the meantime. I wasn't aware that the roguelikes reddit was so large.

Other Announcements / Re: Reviving the Roguelike Magazine
« on: May 18, 2013, 01:02:07 PM »
Sounds like a nice idea.  I might try and contribute something (no idea what, yet) - do you have any more guidance for contributors?  i.e. article length, style guide, review format, examples of the kind of articles that you'd like etc?

If the answer to that is 'no' then I strongly recommend you put something like that together.  I understand if the instinct is to not be too controlling but in my experience a lack of editorial vision is usually the kiss of death to these things.  You also shouldn't be afraid to turn down contributions or demand re-writes.  The lower the quality of submissions you accept the lower the quality of submissions you'll get.  For that reason alone I'm inclined to agree with the suggestion to make it quarterly rather than bi-monthly - you can be a bit more selective that way.

That's a good suggestion, I'll be sure do that. As I said on #rgrd last night, this is the 'community' zine, not the 'one guy with a large opinion talking to himself' zine. This is what I have so far. Feel free to make suggestions.

Regarding the article length, the general layout still hasn't received the finishing touches, so I'm not quite sure what exactly we can accommodate. Anything between a half and three A4 pages (including images) in 1 pica size (12 pt), is practical. A half A4 page is a little bit on the short side, but if it's not mostly images then that would be okay as well. I'll be able to give more precise guidelines later.

The main topics of the magazine are gaming, design and development. The first two are probably most interesting for players, the last two are more interesting for devs. This separation will also be present in the finished magazine.  Any article being submitted must fit into one of these categories.
'Gaming' is to cover actual game reviews, discussion of events and topics in the RL gaming scene.
'Design' is to cover, well, game design from a non-technical standpoint. A lot of this is already being done in the blogosphere right now.
'Development' is to cover the technical aspects of RL making. This includes not just articles on algorithms and data structures, but also the review of libraries and technologies.

EDIT: I should probably add that good spelling is a requirement. I am fairly proficient in English, but I'm not a native speaker, so if I was forced to correct a badly written article I would most likely screw up.

Other Announcements / Re: Reviving the Roguelike Magazine
« on: May 17, 2013, 02:37:24 PM »
And right off the bat, I'd advise you to opt for four issues per year. Six seems an awful lot, but you know your own limits best, of course.

Yeah, right now I just want to see how it works out. If six doesn't work out, I will fall back to four. What I want to avoid is this "Release when it's done" mentality, which leaves readers in the dark about when a new issue will appear.

Other Announcements / Re: Reviving the Roguelike Magazine
« on: May 17, 2013, 10:38:07 AM »
So, it has been decided. This June will see the resurgence of the ancient and hallowed roguelike magazine under a new name. Of course I had to go with the cheeziest name imaginable, but people will get used to it.

I'll soon contact one or two people for interviews. In the meantime, please read the @ Gazette's first Call for Submissions. You are invited to submit articles and suggest topics. I'll do the typography and layout, so no need to worry about that. Contributions of all kinds are very welcome.

What definition of roguelike would it apply?  :'(

There was a thread in the roguelikes reddit recently where someone said "check out my roguelike".  Someone replied "that's not a roguelike".  The response to that was along the lines of "well, they both have tiles."

Well I have a somewhat conservative definition of the term, but of course the 'zine is open to related games as well. What's commonly called a roguelike-like nowadays would be welcome.

Could be cool, though out of sheer bias for the format as a late discovery I should think it extra awesome if it could revive in diskmag format, Hugi-style, or perhaps somehow even more interactive under something like a XDRL shell:

NSFW, but artsy and a fascinating part of history you could easily lose weeks browsing through as a window to the past:

I'll think about it. It would be an incredibly nerdy thing to do (which in my eyes is a good thing), but I still like the idea of the 'zine being printable. So we'll see where we end up.

There have been a few attempts at things like this and they've all been great whilst they last. I'd be interested whatever you decide to go with, but please do try to make it regular and reliable!

I definitely will try to publish on a regular schedule, though it remains to be seen what that schedule will be. I think two months isn't too unrealistic.

Other Announcements / Reviving the Roguelike Magazine
« on: May 16, 2013, 04:37:19 PM »
This was once a thing, and it's a shame it isn't anymore. So, I've been thinking about reviving the mag of old.

In this golden age of RL development, many folks want to stay up-to-date wrt the state of the dev scene, and I think the form of the magazine offers something our current media don't. It is more compact than the Roguelike Radio podcast (which is excellent, and you should not miss) both in size and organizational overhead. Especially developers of smaller projects probably feel more comfortable with answering some questions over email or irc than jumping on the radio for a one-hour discussion. And it is probably more pleasant than looking through roguebase, for people who don't like reading devblogs. All in all I think it would be neat both as a way to keep informed and discuss specific games and topics that devs and players (should) care about.

Of course this wouldn't be weekly or monthly - I think a period of two or even three months would be optimal. There isn't just enough going on in the scene to allow for more frequent 'releases', and I (as well as possible interviewees) happen to have a life as well. It would also be enough time to allow for content contributions from the crowd.

I guess my question to the roguetemplars is, would you read a Roguelike Magazine?

Classic Roguelikes / Re: Dwarf fortress
« on: April 28, 2013, 04:08:32 PM »
I agree with what you say here about Civ 3 and the so-called "Berlin interpretation." But this just shows that the Berlin interpretation is absurd. For example, "ASCII based display" is not a low value factor, unless you're writing a tile based game for a handheld and trying to call it roguelike. Likewise, the Berlin definition makes no mention of a fantasy setting, despite that being a clear common denominator among the canonical examples of rogue, larn, hack, moria, nethack, crawl, ADOM etc. Why might that be? Because one of the handful of people in attendance at some summit was promoting a sci-fi or trademarked commercial video game themed "roguelike", I'd wager.
ASCII-based display has, in the meantime, become a rather low value factor. There are quite a few very popular games out there which prefer graphics over ASCII. ToME and DCSS both have tiles which are used by the majority of players, POWDER is very graphical, Nethack and Angband both feature tiles nowadays, and there are several smaller games that don't even have ASCII modes anymore. Sure, ASCII has its merits, but people are getting used to tile-based games more and more - and if you want anyone outside the RL scene to try your game, tiles are pretty much necessary.
I think you're being a bit unfair on the fantasy aspect as well. The ancestors of the genre, Rogue and Moria, are both fantasy inspired, so it's just logical that their descendants would be as well. Linley's Dungeon Crawl is directly inspired by them and ADOM is fantasy because Biskup, like many, is an old FRPG veteran. Our genre is rooted in this tradition, and since most devs have been players first, they continue this tradition. But there are numerous games outside the fantasy genre. ZapM is outright space nethack (and the PRIME fork is epic). One of the older roguelikes, Alphaman (about as old as LDC), is post-apocalyptic, just like Cataclysm and its recent fork DDA. BOSS is even older and so weirdly scifi I don't even know what's going on. Infra Arcana is by no means fantasy. And I didn't even mention the gearhead games and all the steampunk/cyberpunk stuff that has been done over the years. All I'm saying is, if you think fantasy is a defining feature of roguelikes, it hasn't been at least since the early 90s.

The definition held up as the gold standard fails to clearly separate roguelikes from other genres while at the same time failing to take into account basic commonalities between the classics, old and new. Yet, as you say, the according to Hoyle roguelikes really are clearly different from any civilization game and no one would call Civ 3 roguelike. It's ridiculously easy to poke holes in the Berlin "definition", so why even bother with it?
Because it's pretty much the closest we have to a definition? I don't say it's a good one, but it's the best we have right now. I'm just saying that many characteristics of roguelikes are also inherent to grid-based 4x games, which I personally consider Fortress mode to be. I don't deny its roguelikeness, but I don't think it's a roguelike. Heck, it's close enough for us to have this discussion.

On what you say about exploration and hack and slash, this is true to some extent. Dwarf fortress can definitely be played in a way that has not a lot of monster killing and not a lot of looking for things or going places. Of course, mining and excavating, finding caverns and eventually hell are forms of exploration. I think the more damning issue is that the items you collect in the process are primarily raw materials (minerals, plants, etc.) rather than the traditional prefabricated loot of roguelikes and you're exploring/striking the earth, not a fully formed dungeon (although the caverns are dungeon-like).
Yeah, this is why I consider Fortress mode to be more of a 4x game with roguelike elements. I wish more standard roguelike games would take this approach to creating items, like Sil f.ex. does. Heck, someone has to make all these items/artifacts, why not let the player make some himself?

On the other hand, it's obvious that Dwarf Fortress is heavily influenced by the roguelike tradition. The objection to calling it roguelike can only be that Tarn ran too far with the concept, abandoning conventions like dungeon diving to recover an artifact or kill a monster, a single character directly controlled, etc. The problem with these kinds of objections, to my mind, is that Dwarf Fortress shows clearly that single character control and dungeon diving isn't what makes (some) roguelikes good (and it's obvious it isn't what makes them distinctive). So I'll agree that it may not be a roguelike by some reckoning, but it's a view of what a roguelike could be.
The problem is that about 90% of roguelike players and devs will disagree with you on this point. Roguelikes are a subgenre of the RPG, and direct control is very important to RPGs. Even in multi-character roguelikes, you have direct control of at least one character.

You know, I'm no big fan of ESR, but he said something to the effect that the strength of roguelikes is that the lack of graphics allows one to pour more into the underlying game logic and create more depth than is possible when you need an animation for every possible action, etc. I think he's onto something there (something completely lost in the 7DRL concept) and Dwarf Fortress shows that in the way nethack always has, but in a new, radical way. So I would tend to look at Dwarf Fortress as a direction for roguelikes to head in, even if some would deny it a place in the genre.
You know what that also applies to? Books. Text games. Pen&Paper RPGs. Just because something is non-graphical, or only features simple graphics, doesn't mean it's a roguelike. I don't deny that this is one of the core qualities of roguelikes, but not everything that fits this description is a roguelike.

Classic Roguelikes / Re: Dwarf fortress
« on: April 24, 2013, 09:15:49 PM »
So I hear. I'll wait until it reaches version 1.0 before I give it another try. Maybe two decades?

Yeah, around that time. In the NY Times interview last year he said it would take at least 20 years to get to v1. We're about 34% there.

Classic Roguelikes / Re: Dwarf fortress
« on: April 24, 2013, 07:49:33 PM »
About whether DF Fortress mode is roguelike, for those who like to split hairs, we should clear up some confusion about what "real time" is. If you can stop the clock and queue arbitrary actions, your game is not real time. Dwarf Fortress is not real time. Starcraft is real time. Mario Brothers is real time. Dwarf Fortress allows you to advance gametime one time quantum at a time and allows you to stop time altogether and issue arbitrary commands during the use.
I'm going to counter this saying that cat adoption cannot be stopped with the pause key, and thus it is real-time, but that is just me being facetious. ;)

Look, I don't debate that Fortress Mode isn't real time, but I don' really feel comfortable calling it turn-based either. I'd argue that most of the time is spent running the game instead of having it paused, but what that makes it is really up for discussion.

There are two things about Fortress mode that mark substantial deviations from the usual roguelike approach: Controlling multiple entities and doing so via issuing work orders that are carried out by various dwarves according to who's available and so forth. You guys make it easy on me by saying roguelikes no one's ever played or heard of ("7DRLs", etc.) count as expanding the genre, so I should say I know of at least one roguelike that allowed you to control a party of characters -- it was an angband variant and the author did not come up with a convincing system of control (unsurprising for an angband variant maintainer). I'm sure there's a ridiculous thread to be had about whether this angband variant is roguelike, please spare me. The point is, once you allow multiple entities, which is not unprecedented in the genre, it's natural to have a command set with emphasis on performing tasks that would take a number of turns and therefore hundreds of keystrokes in a traditional roguelike.
Again, this challenges the typical definition of a roguelike. For many people, roguelike also means you control one char, and you control it directly. Both of those have been subverted over the years - there are multi-character roguelikes, yes, and there is at least one game with indirect control. I don't deny that.

But if you look at the existing roguelikes, both established ones, small ones and 7DRLs, 99% of them are about exploration and hack&slash, either in the stereotypical dungeon or some other hostile environment. DF, in contrast, is a game about building a base and caring for dwarves. The gameplay is vastly different from almost every roguelike I know. It's much more like a 4x game.

As an example, let's take a look at my favorite TBS game of the old days, Civ 3. It has a world that can be and often is randomly generated, it is turn-based with direct control, it is grid-based (good old pseudo-eight-directions like roguelikes have it), it's non-modal, has several solutions for problems (as you would expect in a roguelike), you have to manage resources, no rule difference between player units and other units, it shows you the numbers and is tactically complex. So right out of the box it fits at least more than half of the points of the Berlin Interpretation (which of course isn't perfect, but a good compromise between different people's idea of a roguelike). The problem is that Civ 3 is a turn-based strategy game and no one ever will call it a roguelike.

Of course, that's nothing new either. Roguelikes have had shift-move since the eighties at least (I don't know if rogue had it in the 70s) to avoid spamming your calculator pad through every tunnel you encounter. Now the standard bearer of the traditional roguelikes, crawl, has o-move, which * gasp * automatically moves the player to explore levels, the greatest blasphemy since direction pad replaced the o'pen door command -- a fitting irony that this formerly absurd command key is repurposed in such an expressive and interesting way. Why not a-move then? I don't usually stop hitting direction and space until a new monster hits the scene or I go below a certain threshold of HP.
I don't think anyone views autoexplore as a 'blasphemy'. It's a useful tool to skip uninteresting parts of the game, and thus has been incorporated into several recently developed games. The debate on autoexplore is more about the fact that it means skipping content, which leads to the question why this content is there at all if everyone skips it, and what can be done to make it interesting. But this is more of a design issue than outright dislike for a feature.

So who's excited for df2013!?

New complex stealth system, the world becomes alive, armies pathing about on the overworld, the ability to start insurrections, non-lethal combat, movement and attack speed decoupled, creature tracking, tree climbing, fortress retiring...

Here's a fan maintained list of expected updates:

I am. So. Much. I think every Bay12er is.
Though I really hope that in the aftermath of the DF2013 release, we will see fixes for a few long standing bugs that have forced me to run binary patched for a few fortresses now.

A ton of new features and no UI improvement?
What are you, some sort of elf? ;D
Toady has made it pretty clear that feature completion is more important than UI, so we'll probably see most of the UI improvements once the game hits version one or at least RC.

Classic Roguelikes / Re: Dwarf fortress
« on: April 22, 2013, 07:15:15 PM »
I wish people weren't so quick to call any game a ripoff for using another game's ideas.  That needs to happen.  That's how the medium advances.  There's a difference between adopting lessons and concepts derived from and outright cloning it.

Yeah, I agree. I just dislike projects pretending to be innovative when they just outright imitate another game. The DF-likes actually aren't bad in that regard. I hear this happens a lot with Minecraft clones, though.

Pages: 1 [2] 3 4 ... 14