DoomRL 2 tile only?

12 January 2010

The tile announcement has made a big fuss! That made me even more anxious about the tiles release, and made me think about the additional features that it can bring. Unfortunately, I had to scrap some of them due to compatibility with the ASCII version. DoomRL 1.0.0 will have an ASCII mode… but DoomRL 2?

· · ·

Let’s face it, the tile-version of DoomRL (2) will be it’s main version. Recent Dungeon Crawl poll has proven that people prefer tiles instead of ASCII. DoomRL 2 will be built with tiles support from the beginning, no question about it.

However, it came to my attention that there’d be several advantages if I made DoomRL 2 tile-*only*. Help me with the decision!

Advantages

  • Development speed — having only one version to support development speed would be way faster. No need to maintain a abstract interface over display and write two displays simultaneously would be a big time-saver.
  • Cleaner code — the code would be a lot cleaner and readable without the additional indirection level. No need to do hacks for things that might be hard to “support” in ASCII, no need for wierd common interfaces.
  • Better tile support — the tiled version would look a lot more professional, and not seem it is framed from a non-tile game. The interface would be a lot more streamlined and friendly, with support for many features that just can’t be shown with ASCII.
  • Enhanced design — dropping ASCII support would allow me to implement game features that would be unwieldy or not possible with ASCII. Example? X-Com mode for multiple soldiers as a side-game-mode — sure it can be done with ASCII but it would be unwieldy, and require a lot additional ASCII coding.
  • Better protability — yes, surprisingly it will be easier to port the Tile-only version, because the lack of the ASCII-descendant features. The game would be more suited to porting to gaming handhelds (NDS, PSP, iPhone).

Disadvantages

  • Annoying hard-core ASCII fans — this is a serious disadvantage. I know there are some of you who have the “tiles? nevah!” attitude… I just wonder how many of you there are. One has to take note however, that I’m doing the transition to graphics programming anyway…
  • Wouldn’t run on vinitage hardware — um… yes.
  • Wouldn’t be able to be run on server — now this is a serious downside. However, I always wanted to try network programming, and somehow I feel that having boost::asio, it’d be easier for me to write a server for DoomRL than to maintian an ASCII version…

Your opinion counts!

Soo… what’s your call?

Comments

MaiZure · 12 January 2010, 06:33

I have to go with tiles only, if for any other reason, that this is the direction that the ChaosForge needs to be headed. If DoomRL 2 is a great game, ASCII folks will play it anyway – I’m an ASCII guy and I will play a tiles only CF title.

The pros and cons above speak for themselves

Let’s go tiles!

Tavana · 12 January 2010, 06:33

My personal opinion: DoomRL 2 should be tile based graphics only. I see that as the breaking point between number one and two. With modability added to one of the final versions of DoomRL 1.0.0, people can expand on that to their hearts content.

I cry on the inside thinking about the possible loss of network play, but I see it happening in the future…with tiles. If it can happen with ASCII, it can happen with tiles.

In short: Tiles should be focused on for the time being. And if enough people complain, ASCII can always be added later. ;)

beeef623 · 12 January 2010, 09:10

Just include an ascii tileset :)

Risto Saarelma · 12 January 2010, 09:19

Go for tiles only. Having to support both modes hurts interface design and drains developer productivity. And today’s low-performance hardware is much more likely to be a graphical mobile device than a text terminal, so the old hardware point isn’t very relevant.

Telnet tournament play with no chance of cheating short of hacking the server is the one thing you’d no longer get for free, but like you say, the same thing can be accomplished with a suitable client-server architecture.

ecto · 12 January 2010, 09:49

/signs for tiles only!

Aerton · 12 January 2010, 14:37

Allright, I’ll troll here a bit :-D

Well, in such case we expect more graphics. Various floors and walls, lighting (only visual, no gameplay impact) and, blinking terminals, etc – to better match style and mood of the original. Also displaying armour and weapon of the character, blood on damaged monsters :) In other words, take full advantage, rather than just eliminating ASCII support.

As for network, having to download a client kills the whole point of using telnet. Replacing telnet with a web frontend would be more appropriate. Networking is better reserved for a multiplayer mode.

Erich T. Wade · 12 January 2010, 23:11

As much as I love ascii — and I used to be a hardcore ascii-only fan — it looks to me like tiles is the way to go for DRL2. The advantages outweigh the drawbacks, and in the case of network games you could always build a basic server-client architecture.

Cyber Killer · 12 January 2010, 23:27

Blah. Textile doesn’t support emoticons. That sentence isn’t supposed to be crossed out.

Cyber Killer · 12 January 2010, 23:28

I guess You can count me on the hardcore ASCII fans list ;P. However I can bear with some kind of workaround like the mentioned ASCII-tileset (this could be fun in it’s own way like the @ character carrying a shotgun :) ). There is also libaa and libcaca, both portable and able to make ASCII out of a graphics output on the fly.

Herschel · 13 January 2010, 09:25

Definitely do tiles only if it will improve development. I think most people who are averse to tile graphics have bad vibes from roguelikes that added tiles as an afterthought, e.g. Nethack tiles. These tiles are usually minuscule, impossible to decipher, and aren’t very well integrated into the game.

If the game is designed in mind with tiles from the beginning, the experience can be very good. Nice, large, easy to decipher tiles are only the beginning. The really cool features are things like UI improvements — now you can do things like provide nice tooltips and info on mouse hover, draw nicer lines for aiming, provide more intuitive menus. And there’s no doubt that it opens up your game to a much, much larger audience.

IVAN is a roguelike that sticks to a tile display, although it’s still stuck a little in “tile terminal” land. I think it’s possible to be much more feature rich than IVAN tries to be, as far as UI and display goes.

The suggestion for having an additional ANSI tileset is pretty good, too. Much easier to go from graphical tiles to ANSI tileset than vice versa. :) Hell, even Dwarf Fortress has an OpenGL wrapper to display its fake textmode.

Aardappel · 13 January 2010, 17:38

I think UI improvements are the biggest argument for graphics-only.

Things like being able to have the inventory on screen permanently would be one of the biggest usability improvements, and hard to pull off in ascii. No more endless switching between game and inventory.

And like someone said, I don’t see a problem with having a second “graphical ascii tiles” set, for those that prefer a more classical aesthetic.

MDM · 15 January 2010, 00:36

“Tile only” would be THE one reason for me to stop playing DoomRL.

getter77 · 18 January 2010, 08:57

I’d have to agree that Tile is the way to go in the long run, especially if DoomRL will ultimately arrive at a very evolved and friendly state in regards to modding and such.

pan.tenteges · 19 January 2010, 04:42

Go tiles only. As someone previously said, You can just prepare the ASCII tileset, or even have someone design non-ASCII, ASCII-looking glyphs to compensate and have it all more “readable”

(pardon my englishlike language)

the_laptop · 24 January 2010, 17:45

No, no, no. Tiles-only is annoying: pixel estate is hard to ration. How big you want your tiles to be? 16×16? 8×16? 32×32? Multiply that by the number of actual tiles across and what do you get? 2560 across? 1280 across? That’s a hell lot of screen to be staring at to fathom what is going on in what is really a small screen. This will also help in forum discussions, since your screenshot can make use of the Official ASCII form which is again much higher in data density than trying to take a picture of the screen, uploading it somewhere and then linking it.

I’m not going to debate the tiles vs ASCII issue, but I will throw this in: keep the ASCII version for the higher information density. I don’t care how the ASCII version is done in — pure console or graphical — but keep that as the Official version to be referred to unambiguously, while leaving the options of truly graphical tiles available.

Eric · 27 January 2010, 17:21

tiles only. I’m a big fan of ASCII like every other roguelike-geek but the tiles I’ve seen in the preview screenshots are beautiful!

Slashie · 29 January 2010, 07:49

Keep it open for people to add new tilesets, but stick with Derek tileset for the main development. This will add a bit of burden (because you will need to make a lot of things “parameterizable” :P).

Ultimately, it’s your choice… if your time is limited and developing a generic UI will prevent you from working on the real important things, just do it with tiles ;)

DoomGuy · 1 February 2010, 17:10

Tiles only is fine. Perhaps some fellow with a flowing mane of neckbeard might take offense to the purging of an archaic and cumbersome system. Tiles also go a long way to making a game more accessible as well as (when done as well as these tiles!) more professional looking.

JBridge · 2 February 2010, 16:04

Here’s an idea. Include an alternate tileset that’s made to look like ASCII. That way you get to keep everything tile-based, and the pruists will still be pleased. Probably.

mackeary · 17 February 2010, 00:49

I think a tile only game would be fine as long as there could be multiple sizes of tile sets. I’m legally blind annd like to play with large tile sets to reduce eye strain. It’s one of the reasons I’ve stuck to ASCII RLs because I can increase the font size in most of them. That’s what I do with Doom RL which is by far my favorite coffee break RL.