Its finally time for a progress update. Inspired by the categorisation given in How to Write a Roguelike in 15 Steps, I've broken down the coding of Kharne into a number of discrete areas. The current areas of the rewrite either completed or in a reasonable playable state are:
Game Mechanics
I have a complete document that specifices the game mechanics I'm using. The original Kharne used AD&D, but the rewrite is using a system influenced by both Angband and Crawl. These may need tweaking during playtesting since according to the old saying, "no plan ever survives contact with the enem^H^H^H^Hplayers."
Data Storage
Read-only config and item information is currently stored in an SQLite database. For any modifiable data, e.g. savedata, compressed text files will be used.
Character Creation
This has been hived off into a seperate DLL to avoid bloating the main code too much. This is, bar any tweaking to the game mechanics, finished and complete.
Level Generation/Navigation
The dungeon algorithm I'm using is a heavily modified version of the one used in the original Tyrant by Mike Anderson. I've extensively modified it and parameterised it to enable the production of a much wider variety of levels than it was originally capable of. I will add in additional algorithms for different level times eventually.
Display
I'm using plain old GDI with Double Buffering. The basic viewport is running, in tiled mode, at well over 100 fps on an old P4 2.8 Ghz PC. The framerate for ASCII mode is off the scale. Incidentally, Kharne doesn't use any sort of text handling for ASCII mode - the characters are blitted graphically to the screen. I hope to eventually use this to enable smooth real-time rotation and zooming of the play area, which, to use a technical term, "cool".
Item Generation
I can generate a wide variety of magical and non-magical items, either random, or of a specified quality and type. I have also written an external program that uses the same item code to produce vast numbers of items for future analysis and statistical purposes.
Inventory and Item Handling
The '@' can pick up, wield and remove a wide variety of items. The effects these items have on player statistics isn't completely implemented, however.
Things yet to do, in approximate order, are (deep breath, this is still quite a big list):
Morgue/Death Handling
Time Handling
Saving/Loading
Magic
Monsters
Monster AI
Victory/End Game Handling
The current roadmap from here is to try and finish what is remaining on inventory handling and then make a start on the remaining items mentioned above. Unfortunately, a playable release will be a few weeks off yet.
Subscribe to:
Post Comments (Atom)
4 comments:
Out of curiosity, why are you choosing GDI?
In my experience, GDI is passable for blitting, but it binds you to Windows and is slower than molasses in January.
You might want to consider SDL, which would buy you sound and image routines as well as being platform independent. You don't have to go as far as OpenGL through SDL, but if you're going to ever consider real-time rotation and zooming, you'll need to go down some similar route.
I'm using GDI because that's the default interface from the Delphi VCL to Windows (i.e. I'm not actually using the GDI directly, but rather through the built-in Delphi encapsulation - sorry if this wasn't clear in my original post). If I do eventually port it to another OS via say, Lazarus/Free Pascal, I won't have to actually do anything other than a recompile since the VCL and the LCL (the Lazarus/Free Pascal version) are pretty much compatible.
Thanks for clearing that up -- GDI makes a little more sense when it's portable.
Please forgive my lack of knowledge about Delphi and Free Pascal. =)
No worries. Actually, today, I was talking to a fellow programmer who dabbles in 3d game design and he mentioned using OpenGL if performance requires it, so I may check that out in the future.
Post a Comment