Results for the 2013 Roguelike World Survey has been posted

[miki151]

I'm glad that most developers don't agree with you on this

It's the players' loss.

Which players? Mushroom patch and a couple others? If I stuck to ASCII, admittedly that 10% of development time I spend on graphics could go into gameplay. But wait, the game would long be dead, because there'd be no chance to sell it, and I'd have to be back working at an office. Thank you, tiles!

[mushroom patch]

http://www.google.com/trends/explore#q=nethack&cmpt=q

Those players.

http://www.google.com/trends/explore#q=dwarf%20fortress%2C%20nethack&cmpt=q

And those players.

Dwarf Fortress is way bigger than any roguelike game written in the last fifteen years. It's not a real terminal interface, but if you have ideas and a simple, nongraphical interface, there are players.

[miki151]

Both of these games have both ASCII and graphical interfaces...

[mushroom patch]

Irrelevant. You really believe nethack needed tiles to get people to take it seriously?

[miki151]

Well it did for me. But irrelevant, have a nice day.

[AgingMinotaur]

A "GUI also opens up some possibilities that are not there" in Unicode or other kinds of terminal display.

It also closes off possibilities. Unicode is not a trivial point, as you would have it.

Obviously, it closes off possibilities – if not, there wouldn't be this discussion. And yes, you can do wonderful things with Unicode. The fact remains, though, that GUI vs. terminal UI have differing strengths/weaknesses, and there's nothing inherently "un-roguelike" about going for a graphical display. The genre is developing with the times, and it seems to me that trying to shape and benefit from this evolution is a better course of action than complaining about the recent deployment of 20 year old technology in a 30 year old genre.

So what if some developers (and a growing amount of players) like tiles?

Where are these players? What I see is that the roguelike games that have developed recently are still in the round off error range on google trends and the older ones have been in steady decline. Maybe you meant proportionally more, as players come to grips with the reality that the nethack dev team is gone.

Not quite sure where you're headed with this. Yes, I guess I meant "proportionally more", or maybe even that a decline in eg. nethack player recruitment has something to do with the fact that "a growing amount of players" prefer GUIs to games that can be played on a terminal. And at the end of the day, I don't give a rat's ass how google trendy RLs are. Also, you'd be surprised disgusted at how many people on this forum actually prefer tiles, if given the choice.

As long as a game is playable locally on my machine, I couldn't care less which tools the developer used, whether the application opens a separate window, plays in the terminal, or whatever. (I'd even try something that required telnet, even if the prospect seems about as abhorrent to me as playing Crawl or ADOM with tiles.)

I'm amazed how disconnected from traditional roguelikes you profess to be. And it's not about being hardcore, it's about recognizing what's unique and excellent about the genre and focusing on that.

Heh. Is your point seriously that using curses and being able to play over telnet constitute "what's unique and excellent about the genre" (rather than actual gameplay)? If so, I really just don't get where you're coming from.

Re: Dwarf Fortress. Its big because of innovative and well executed ideas, not because it uses a terminal interface, you silly billy. Do you think DF would have flopped if it could only be played with tiles?

As always,
Minotauros

[mushroom patch]

So what if some developers (and a growing amount of players) like tiles?

Where are these players? What I see is that the roguelike games that have developed recently are still in the round off error range on google trends and the older ones have been in steady decline. Maybe you meant proportionally more, as players come to grips with the reality that the nethack dev team is gone.

Not quite sure where you're headed with this. Yes, I guess I meant "proportionally more", or maybe even that a decline in eg. nethack player recruitment has something to do with the fact that "a growing amount of players" prefer GUIs to games that can be played on a terminal. And at the end of the day, I don't give a rat's ass how google trendy RLs are. Also, you'd be surprised disgusted at how many people on this forum actually prefer tiles, if given the choice.

I would say this reflects regression to the mean. As the standard bearers faded out of active development (nethack, ADOM, mainly), nothing really picked up the ball, until much later with DCSS. (Probably ToME deserves mention here as well.)

As long as a game is playable locally on my machine, I couldn't care less which tools the developer used, whether the application opens a separate window, plays in the terminal, or whatever. (I'd even try something that required telnet, even if the prospect seems about as abhorrent to me as playing Crawl or ADOM with tiles.)

I'm amazed how disconnected from traditional roguelikes you profess to be. And it's not about being hardcore, it's about recognizing what's unique and excellent about the genre and focusing on that.

Heh. Is your point seriously that using curses and being able to play over telnet constitute "what's unique and excellent about the genre" (rather than actual gameplay)? If so, I really just don't get where you're coming from.

I'm saying that using the minimal, most flexible method of interfacing with game logic is a huge part of what makes roguelikes great. And you wildly underrate the importance of university mainframe and later multiuser (both university and public) UNIX systems in popularizing and sustaining interest in roguelike games from the beginning to this very day. DCSS grew out of this environment and seems to be the only big new thing in roguelike games other than indie games trying to be even more retro. (Or so survey says.)

Terminal interfaces are straightforwardly better for the type of games that have traditionally been called roguelikes. As terminals have become more capable (or rather, more capable terminals have become more widely/easily available) and the internet has brought more people into its social aspect, this is even more true now than it has been in the past. Terminals provide quick, powerful interfaces with instant multiplayer.

Re: Dwarf Fortress. Its big because of innovative and well executed ideas, not because it uses a terminal interface, you silly billy. Do you think DF would have flopped if it could only be played with tiles?

Innovative and well executed (well enough anyway) ideas that took form in a graphic free setting. Tarn realized graphics were holding him back and looked to the roguelike approach for a solution. So to answer your question, I don't think Dwarf Fortress would have been made at all by a developer who spends his time on tiles.

[miki151]

Do you realize that using basic tiles is almost as easy as using ASCII? I believe the ASCII interface of DF are just unicode symboles rendered into sprites.

[mushroom patch]

I've seen some bad tile sets, but I don't think I've ever seen one so bad it would've been more work to render a code page in MS paint.

It still seems counterproductive to do something almost as easy, but worse than, using a terminal.

[reaver]

Bad tiles are a pain -- they look like drawings of action figures for 5yr olds. Inventory items shown using 4x4 tiles or something horrendous like in some games make my eyes bleed.
That said, graphics offer new possibilities that ASCII can only try to emulate.

Mushroom, how would you visualize a pile of items at the feet of an orc standing in a poison cloud with an arrow that is just about to hit him, whereas the tile that the orc is standing is semi-illuminated by a nearby torch?
All this is trivial with graphics. What would you do with ASCII? print 'o', and 'l'ook to read a paragraph?

[mushroom patch]

Well, reaver, I would go with the 'o' option, perhaps with a colored background to indicate that he's standing in a poison cloud.

I don't think your example is trivial with graphics, or at least if it is, I haven't seen any instances of it being successfully rendered with tiles in a roguelike game. I think it could be trivial in a first person shooter with an actual graphics engine, but that's another story. I'm curious about where you've seen a roguelike game that features the kind of time granularity where an orc could be "just about" to get hit by an arrow.

Obviously, graphics offer new possibilities. I don't see a lot of evidence of those possibilities blowing away the old standards within the genre, but I grant you that someday someone might come up with a really great way to use tiles in roguelike games (well, maybe DCSS webtiles). Even so, I would much rather see these innovations come in the context of a widely used standard for tile-enriched terminal/telnet interfaces than some local play only SDL-based download, which is locked into an isolated one player mode.

[reaver]

I don't think your example is trivial with graphics, or at least if it is, I haven't seen any instances of it being successfully rendered with tiles in a roguelike game.

Because tile devs are lazy

I'm curious about where you've seen a roguelike game that features the kind of time granularity where an orc could be "just about" to get hit by an arrow.

ADOM, when a rock hits you, the rock character overwrites the player character and then it vanishes.

Obviously, graphics offer new possibilities. I don't see a lot of evidence of those possibilities blowing away the old standards within the genre, but I grant you that someday someone might come up with a really great way to use tiles in roguelike games (well, maybe DCSS webtiles). Even so, I would much rather see these innovations come in the context of a widely used standard for tile-enriched terminal/telnet interfaces than some local play only SDL-based download, which is locked into an isolated one player mode.

You don't see evidence because nobody bothers, unfortunately. If people spent more than 1% in graphics like they do now, we could have better games. Graphics CAN enhance gameplay and the overall experience.
Widely used standard? We must be living in parallel universes, or you're being *very* optimistic that you entertain yourself that this is even remotely a possibility.

[mushroom patch]

I'm curious about where you've seen a roguelike game that features the kind of time granularity where an orc could be "just about" to get hit by an arrow.

ADOM, when a rock hits you, the rock character overwrites the player character and then it vanishes.

Well, I guess that goes to show no tiles are necessary.

You don't see evidence because nobody bothers, unfortunately. If people spent more than 1% in graphics like they do now, we could have better games. Graphics CAN enhance gameplay and the overall experience.
Widely used standard? We must be living in parallel universes, or you're being *very* optimistic that you entertain yourself that this is even remotely a possibility.

Well, I don't really want them to bother. I want them to bother less than they currently do. I think graphics enhance certain kinds of games, but not as much roguelikes.

On widely used standards, I think the general idea is to assign non-character code point to tiles defined in some bitmap -- ideally downloaded automatically from the connected server or some repository. A nice feature of unicode wide characters is that they produce glyphs set in a square shaped space on the terminal equal to two standard width characters side by side. You can therefore make a map display with nice square map tiles (this is already supported in every major terminal emulator in common use, e.g. xterm, gnome-terminal, putty, etc.) and standard ascii characters (centered in the square tile) and various Asian characters (perhaps less interesting). Moreover, you can freely mix standard width and wide characters. This allows for a lot of fun and games with block elements and box drawing characters as well.

Anyway, throw in tiles and you've got something. As I've mentioned, this tkatchev guy already has a telnet client that does this sort of thing with tiles (haven't tried it), although I believe his client uses a tile set for his own game. If tile sets were pretty standard, usable via curses, and didn't require a custom client, then I'd be totally fine with them (though I still wouldn't use them, probably).

[Bear]

... how would you visualize a pile of items at the feet of an orc standing in a poison cloud with an arrow that is just about to hit him, whereas the tile that the orc is standing is semi-illuminated by a nearby torch?
All this is trivial with graphics. What would you do with ASCII? print 'o', and 'l'ook to read a paragraph?

I think of roguelike games as being abstract games in the first place.  @, and o, in the context of a roguelike display, are symbols, not visualizations.  They're like the lowercase 'k' in a diagrammed chessboard in a newspaper chess column, or like the carved wooden horsehead on a chessboard.  They represent the *idea* of a warrior mounted on a horse, to some extent - but they are an abstract symbol, not a depiction.

So, yeah, the orc is an 'o'.  The gas cloud is a background color.  That's the top-level tactical display that the player needs to see.  All the rest of that stuff is available to the 'l'ook command. 

But let me ask a different question:  How do you make a tile that is instantly recognizable as an orc, and absolutely does not get mistaken for anything else, if you keep varying your symbol for all these nontactical or para-tactical considerations?  If the player sees a different symbol (because you decided that the lighting was different or whatever) how does the player know - for sure - that it isn't a different kind of creature? 

That's what I want in a roguelike interface; I want a stable set of symbols, where I can tell exactly what I'm looking at because all instances of the same thing do in fact look exactly alike.  I don't want to play chess with a chess set where the pawns look like different pieces; they are all pawns, they present the same kind of threat, they should be represented by the same symbol.  If one of them looks different, I as a player want there to be a reason why, and it needs to be a reason important enough to justify the cognitive load of learning what a different piece looks like. 

If I've been playing some tiled game long enough to look at a tile and say "orc" when there are fifteen little things that are a tiny bit different because of lighting, arrow about to reach, sickly, low on hitpoints, armed with different weapon, etc, etc, etc, ....  and then it turns out that thing I looked at isn't actually an orc but instead some kind of thing that presents a tactically different threat;  at that point I feel that I've been abused by the game's interface.  If it happens a few more times, and especially if little induced mistakes like that cost me games - I am likely to rage-quit and go play something else.

And that's why I prefer character displays.  Specifically because they do NOT invite that kind of infinite variation in symbols. 

[AgingMinotaur]

I'll try not to be too redundant/trollish

I'm saying that using the minimal, most flexible method of interfacing with game logic is a huge part of what makes roguelikes great. And you wildly underrate the importance of university mainframe and later multiuser (both university and public) UNIX systems in popularizing and sustaining interest in roguelike games from the beginning to this very day. DCSS grew out of this environment and seems to be the only big new thing in roguelike games other than indie games trying to be even more retro. (Or so survey says.) <snip relevant arguments>

I'm not really underestimating the importance (current, as well as historic) of this, just saying telnet play doesn't particularly interest me, personally. And I definitely agree that as a format/api/whatever, something that fits into terminal output is extremely portable. For my part, though, I just like running my applications locally, and fiddling with my little game projects from time to time. Terminal support is on my current project's wishlist (also because it's a mode I'd use myself), but for now I'm just plugging away with pygame, even having fun experimenting with tiny animations and stuff

re: "the only big new thing", consider that making a major RL takes a decade, as well as immense skill and luck, and also that these kinds of polls will always be flooded with ignoramuses voting for stuff like The Binding of Isaac.

Tarn realized graphics were holding him back and looked to the roguelike approach for a solution. So to answer your question, I don't think Dwarf Fortress would have been made at all by a developer who spends his time on tiles.

This almost becomes a tautology: If Tarn hadn't had the time to design DF, there would be no DF I see your point that opting for a terminal(like) interface leaves more time and room for game development. There's also the argument that there are no fancy graphics to lead attention away from bad gameplay. If your aesthetically awesome game sucks underneath, people might still get fooled by the graphics, but a game with very basic UI just needs to be well designed to raise any positive attention at all. All of this has been discussed to death already, perhaps.

At the end of the day, UI is mostly just look and feel, though. Earlier, you're talking about how "the internet has brought more people into its social aspect," and one effect of this is that the cost of game art also goes down. Why shouldn't a designer team up with a graphical artist or tap into game-icons.net or opengameart.org, if s/he so wishes? And for one-person teams, finishing a relatively fleshed-out RL takes years. If a few weeks or more is spent by the developer making crappy (or awesome) art, it probably just amounts to a drop in the ocean. Terminal output of RLs are almost inherently beautiful and pleasant UIs, I'll grant you that, but if someone wants a more specialized GUI for their game, I see no fundamental problem in that.

@bear: I think there's room to experiment with graphical UIs that extrapolate on the abstractness you're talking about. For instance, my current game is (going to be) using footprints for critters (atm, they're mostly bitmap fonts). Too bad it's a pseudorealistic setting, with most opponents/NPCs being represented by shoe/boot prints. It would probably work better for a setting with humanoids (represented by a pair of barefoot prints), or even furries (DuckburgRL, based on Carl Barks)! Anyway, footprints can for instance be colorcoded to distinguish types (yellow feline paws for lion, red feline paws for tiger). In comparison, take something like Gearhead, with lots of NPCs to keep track of, and it's a hassle to find the one you're looking for. In a GUI, they could have name tags with their initials, or attached icons to indicate they are questgivers, or whatever. Using a GUI also makes it easier to put more tactical info directly in the map (health bars, animated hits/misses), relieving the player of having to glance over at the message log every turn. Although CoQ is one example of a game that cramps a lot of info into a terminal, I think that in itself represents a lot of work. And I'm sure something based on cave paintings might be awesome, or lifting some ideas from Oryx (artist for Brogue and Infra Arcana, amongst others) and abstracting them even further, or someone finally making the ultimate 3D typography RL.

tl;dr: I wouldn't dismiss GUIs out of hand

As always,
Minotauros