Tuesday 29 April 2008

Some aims and assumptions

Before I go into detail on the rewrite progress, I want to lay out a few important points about the rewrite.

  • Graphics will not be important. In my previous post, I mentioned the reasons why the original Kharne used tile-based. However, in the intervening years, I’ve come to appreciate the use of ASCII in roguelikes. Most of this perhaps is due to obsessively playing (and dying) in ASCII roguelikes like Crawl. But even when both are available, for example in Paprika, I tend to nowadays prefer ASCII. Perhaps Tomas Biskup (the creator of ADOM) had it right after all:

    "...most roguelike games do not use any graphics but rather rely on the ASCII character set to display their surroundings. While this might sound horrible to you, you will be surprised how quickly you start to enjoy this "primitive" type of display. Your imagination quickly will take over and you'll no longer miss those ugly hand-drawn graphical tiles that do not resemble your picture of a dragon at all. But in your imagination, that blue D will soon become the most horrible and frightening ice wyrm you can imagine. Try it out. You won't be disappointed. "

    I do recognise however that some people find tile graphics preferable (to say this is a contentious issue would be quite an understatement), so therefore the rewritten Kharne will support both ASCII and Tile Graphics, with full equivalence between them. But for now however, ASCII graphics will be the focus of development (though tiles can and will be plugged in very easily). I need to concentrate on getting things done, not drawing pretty pictures.

  • Using the mouse and using the keyboard should be equivalent. One of the most powerful features of Roguelikes is their interface – its often quicker to use the keyboard to do something than to use the mouse. On the flipside of this, the converse can be true as well. Since Kharne is designed to run natively on Win32 OSes, both methods of input will be supported.

  • Yes, Kharne will still be Win32-based. I do not have a Linux-based machine, and Delphi is currently Windows-only development. I am open to it being ported to Linux via Lazarus in the future, but for now, I think it is more important that the first version gets written, never mind any ports. Use of Delphi also allows me to use a modern windowed GUI environment where I think it will enhance the game.

  • The gameplay of Kharne will be balanced around permadeath. Yes, its bloody annoying when all your hard work ends in nowt and you make a stupid mistake, but we all restart the game almost immediately, learning something (hopefully) from the death. Even though it is now a common meme (and possibly even the truth) that the implementation of permadeath on Rogue was driven mainly by technical considerations and not for reasons of gameplay, permadeath in a roguelike does actually make sense, if the gameplay is indeed balanced for it.
  • Kharne will be easily extendible and customizable. I will not however, use the Angband model and use edit files. Rather, where feasible, Kharne’s data will be held in an SQLite database. SQLite is a rather remarkable free portable single-user database in the public domain that requires only the distribution of a 200k DLL file along with your code. SQLite databases are also absurdly easy to edit, using one of many freely available tools. Using an RDMS moves the storage of data away from the “flat” structure of info files into something resembling their true meaning (you can probably tell I’m a database programmer by trade at this point).

  • The source code of Kharne will eventually be released under the LGPL or similar license (I’m restricted from using the GPL because I use some closed-source (albeit freeware) custom components). Not for a few versions though.

I intend my next post to lay out progress so far, with quite a few screenshots. I hope to have these up in the next few days, real-life permitting.

3 comments:

Anonymous said...

If you haven't tried SQLiteSpy (freeware, delphi), I'd suggest that you give it a shot. I'm going to be using SQLite and SQLiteSpy in an application of mine, though it won't be a roguelike.


I am interested to see how you will balance permadeath. I can tell you that I find normal CRPGs boring after their first play through (like KOTOR), and that most roguelikes have too much permadeath for my tastes. As a long time gamer it isn't naivety that kills me, but misunderstandings of the system or the evil RNG.

Though, not even GearHead, which I liked, had enough permadeath for my tastes. I think the most I died before starting a new character was five times. Yeah, that was getting a bit inane.


Oh, you might want to note that if you use normal system calls and avoid a bunch of fancy things, WINE should be able to run Kharne just fine on a Linux box. Just so you know.

Dave said...

I had intended to go into more detail on how I'm using SQLite in another post, but I might as well talk about it here instead *grins*. I tried using the combined Delphi/Lazarus SQLitePass suit of components but ran into a nasty initialisation bug, so instead I'm using Tim Anderson's Delphi Wrapper (http://www.itwriting.com/sqlitesimple.php). Its not horribly over-functional - but its got enough to be amply usable - it basically provides TDatabase and TDataset/TQuery functionalty, but for reading simple information from a database it'll do splendidly. I'll check that editor out - it reminds me of the IBExpert variations we use in my job. I'm currently using the personal version SQLite Expert (http://www.sqliteexpert.com/) but it has its, shall we say, foibles.

As for permadeath, I anticipate allowing ways around it for careful and prepared characters. I have in mind things like powerful spells or artifacts that allow either a chance at ressurection, or guaranteed ressurection with a significant penality. Whatever happens, death either be final or should be a significant event in a character's, err, life.

I'll have to look into WINE though - the most complex system calls currently in the code are simple file-handing like FileExists. How does WINE handle DLLs or GDI calls?

Anonymous said...

Thanks for the information about SQLite, as headers for Delphi will come in handily.

I don't develop on Linux, currently, but I've used it in the past. From what I understand, WINE directly emulates the Windows OS and intercepts calls to DLLs. If they were to extract your game with its DLLs, then it should be more than capable of handling execution of the DLL. The same would go for GDI calls, as I know that WINE turns DX calls into their OpenGL equivalents. That's about all I know on WINE. But I know they're either close to, or have recently released version 1.0.