A Lazarus Question

Eventually, I'd like to make kharne multi-platform. Whilst I wouldn't consider myself a Linux fetishist to any great extent (I only have Windows XP machines at home, by choice), I do think that by-and-large multi-platform compability is overall a Good Thing (tm). I've been browsing the website of The Lazarus Project, the multi-platform alternative to Delphi, and pondering what it would take to swap over development to said toolkit.

But it appears that at the moment, Lazarus isn't in a state that will allow me to do so. According to the Lazarus for Delphi Users wiki, support for dragging-and-dropping is either non-existant or extremely cripped. I'm somewhat surprised at this, since dragging and dropping is a fundamental part of a windowing interface. But the relevant part of the wiki that states this hasn't been updated since December 2007. Does anyone know if drag-and-drop is still a problem in Lazarus?

If it is, and since the primary Inventory functionality in Kharne is drag-and-drop based (and will stay that way), until such time as drag-and-drop is fully implemented in Lazarus, there will be no Lazarus port and Kharne will remain Windows only.

Which is disappointing. Deeply disappointing.

Gameplay Idea #3: Cooperative Multiplayer

No really.

Yes, I know about MAngband. Let's pretend it or its source code doesn't exist for now.

Its not that hard to implement (and uttering those words I've undoubtedly made a rod for my own back which will come back to haunt me in no uncertain terms in the near future).

Here's why: think of the typical state changes that occur in a roguelike. Its easy enough to categorise them into three frames of references: the player, any other actors (i.e. monsters) and the environment.

Let's take the viewpoint of the player first: aside from movement and attacks, most other player-centric operations effectively only involve (to the outside observer) a juggling of statistics. Since we're a roguelike, we're operating in a strict turn-based paradigm. In a co-operative environment, actions from another player would only involve more juggling of statistics (e.g. buffing, healing and so on).

From a monster viewpoint, a player either moves, attacks or does something else. This is the same for one player or another.

From the environmental perspective, items get picked up or dropped, the dungeon may get altered slightly. Whither it is one player or another that is the catalyst for this behaviour is irrelevant.

I would suggest that it is perfectly feasible to implement an API to allow two (or more) players to play in the same game (using a strictly turn-based system). There would be limitations of course - handing going up and down stairs (if you have non-persistent levels) would be tricky, and monster AI would have to be adapted to handle more than one foe (something the faction idea could help with).

Now is all this of course desirable? Balancing the gameplay of roguelikes is a horrible job at the best of times (sometimes it can take years) And the issues surrounding the interface of connectivity and gameplay are enormous (see these threads on r.g.r.d for some examples). And of course the final point: I've not even released a playable demo yet, so why am I discussing a feature that may never be implemented?

Thoughts?

Progress Report #7

Drop Item functionality has now been implemented. I was originally going to include all the suggestions mentioned in the comments to my previous post on the subject, but due to a slight limitation with the Delphi VCL (for some reason TPanel components, despite inheriting from TWinControl, don't have the corresponding OnKeyDown events, and I'm not interested in creating my own TPanel descendant that can respond to said key events) I've only implemented drag-and-drop item functionality.

And now, onto monsters! This is a very exciting bit of development, as I have lots of ideas for their AI. As ever, the reference posts on AI in Roguelikes seem to be over at ASCII Dreams. Eventually, I'd like to adopt many of the ideas mentioned there, but for now, the priority is to get the monster data entered into the SQL-Lite backend and then from there a monster generation algorithm written.

A while back, before development was put on hiatus, I had written up a fragment of a top-level design document dealing with this. Here's an extract dealing with one particular set of levels:

The Fortress

Built from rooms and corridors
Filled with martial creatures
Level 1 to 5 Monsters

Level	Monster	Symbol	Colour	Class Template	Frequency	Faction
1	Goblin	‘g’	Light Grey	Class + 1	Common	1
1	Kobold	‘K’	Brown	Class + 1	Standard	2
1	Xvart	‘g’	Purple	None	Rare	2
2	Hobgoblin	‘g’	Brown	Class + 1	Standard	1
2	Gnoll	‘g’	Yellow	Class + 2	Common	2
2	Quokka	‘r’	Light Grey	None	Rare	2
3	Quaggoth	‘g’	Orange	Class + 1	Standard	3
3	Warg	‘w’	Light Grey	None	Standard	2
3	Trogg	‘T’	Brown	None	Rare	3
4	Ogre	‘O’	Brown	Class + 2	Stsndard	1
4	Ogre Mage	‘O’	Magenta	None	Rare	1
4	Hill Giant	‘C’	Light Grey	None	Standard	4
5	Cyclops	‘C’	Brown	None	Rare	4
5	Ettin	‘C’	Brown	None	Rare	4
5	Minotaur	‘m’	Light Red	Class + 3	Rare	5

Although this document didn't go into detail on the individual monster statistics, there are a few things here which are of interest at the moment. The 'Class Template' column refers to an idea I had, of, like Crawl, a slightly tougher version of the monster appearing with a class template bolted onto it, e.g. instead of a standard goblin, occasionally a "Goblin Fighter" might appear.

The 'Faction' column referred to an idea I had of improving AI by introducing the concept of Factions and a variable called 'Hate', which would eventually allow monsters to fight each other if necessary (the player would always be Faction 0). I don't know if I'll ever get that implemented though.

(Edit: Reformatted Post to remove the big gap. Thanks to Robotics For You!! for how to do this.

Gameplay Idea #2: Weather and Climate

I'm sure I'm wrong in this, but I don't believe that there are any roguelikes out there that incorporate weather and climate into their world model. Even indoors and underground there could be great scope for dynamic climate. And of course, not all climate could be caused by mere atmospheric phenomena. This sort of thing springs to mind:

"At the beginning of an elemental invasion, portals will open to the Elemental Plane and invaders will begin to pass through. Thus, during an invasion, you will find two to three times as many elementals in the area, usually slightly higher in level than the standard ones found there.

At some point during the invasion, the elemental leader will appear and begin yelling challenges that can be heard by all in the area. While the elemental leaders are alive, more and more invaders will spawn. Once the leader has been destroyed, no new invaders will appear, although those already present will remain until they are killed. "

Or how about a dynamic almost dungeon-wide storm of this? In a multiverse of magic, the possibilities are endless.

7DRL and Cosmology

This year's 7DRL Challenge is fast approaching and I'm seriously interested in taking part. I have a (what I consider to be a) neat idea for a 7DRL that ties into my interests outside of programming. Any more than this, I'd rather not say at this moment. Although I considered writing it in a language other than Delphi, I'm going to stay with Delphi (for this one) and reuse some of the code I've already written for Kharne (e.g. FoV).

In other news, I've aquired a dead-tree version of the Manual of the Planes (an excellent tome, incidentally) and its quite alarming to see just how much the DnD Cosmology (here in its latest format) has influenced my vision for Kharne (the answer is, in case you are wondering, "a lot"). Not that this is a bad thing of course. Some of this perhaps is a legacy of the original Kharne being AD&D based, some of it because I've played the various incarnations of D&D for decades now. But it is interesting to step back occasionally and see how environmental and cultural influnces influence not only your own psychology but your output as well.

Of course, this may mean that, should Kharne ever get released and take off and turn into a multi-person effort, other people may have to suffer my idiosyncratic design desisions. Perhaps this a bridge best crossed whenever we come to it.

Progress Report #6

Well, its been quite a while since the last one of these posts, hasn't it? (June last year in fact.) Although I've been busy doing other things for the last week, I've managed to get a few bug fixes into the code, and did some behind the scene coding on the targeting system.

But now I have a decision to make. Here is the current inventory screen:

My question is this: What is the best way of implementing "Drop Item" functionality? Currently, items can be picked from the main game window by pressing 'g'. Items are then worn/wielded etc by dragging and dropping (via the mouse) on the inventory screen (which itself is accessed via the 'i' key. But dropping items? Many Roguelikes have a separate interface for dropping items, but I'm not sure I want to go down that route. I do want however to keep the interface as simple as possible. Thoughts?