Posted by
| David Haley
USA (3,881 posts) Bio
|
Message
| For attributes, we're looking at: Strength, Constitution, Dexterity, Agility, Intelligence, Willpower, Wisdom, Personality, Luck. (We're not sure if Luck is an attribute that behaves quite like the others). These do the fairly standard things. Personally I would like an attribute for perception, but that complicates things a lot. Still, it would allow for very alert warriors who aren't necessarily smart or wise.
I like the hook system you describe. It's similar to what I had in mind. We wouldn't have an SQL database, since Lua provides a table mechanism already. And Lua oh-so-nicely allows you to create functions on the fly, and pass them around as proper data values. So, it's extremely easy to create hooks, callbacks etc. and link them together.
Prerequisites are tricky, because some might be of a very general type. Let's look at a module that adds a new spell. It would require a mana module of some kind, right? (That is, it assumes the existence of a spell framework.) We can't really list one particular magic module as a prerequisite -- well, we could, but that wouldn't be very good. We would probably have to list particular callbacks as prerequisites. That is, require the existence of a "DrainMana" callback on character objects. This assumes that your magic module provides such a callback. But then, if I make a magic module and you make a magic module, as long as we follow the same conventions for callbacks etc., our spell modules can work together very nicely.
I think that for crafting it's pretty much a given that recipes can be created on-the-fly, much like online construction. But again, the distinction between hard and soft coding is blurry in my mind, since almost everything is probably going to be Lua anyhow.
For combat, we're not in a position to talk about it until we hammer out our general goals first. We need to discuss things like: how does magic work in combat? How do groups work? How do skills work? Do players lose stamina? Basically, we haven't yet decided what the rules act upon, much less what the rules do! :-)
For link-deads, we haven't decided fully yet but the easiest to me seems to have them keep on fighting, and if they win the fight -- or die and respawn -- simply have them quit after 30 seconds, assuming nobody else comes along and fights them. Our quit action will have a cool-down and all that, so that you can't instantly quit; and auto-quits will be the same way, except with a longer cool-down. So we don't really need flags; we would just have a timer on the link-dead player that, at every round, attempts to quit. If the character is free to quit, it'll start the quit process.
For magic, we were looking at some kind of hybrid mana/memorization model. Basically you would have to choose a subset of spells you could cast, which you can cast using mana (i.e. relatively quick recovery rates). But if you want to change the subset, you have to spend much longer retranscribing spells etc. (i.e. AD&D-like spell memorization times). I like your drain idea, though; I'll throw it onto our design wiki.
We decided against having an absolutist alignment system for several reasons. The foremost is that it's incredibly difficult to quantify programmatically. Instead, we decided to implement a form of moral relativism. Your "alignment" is perceived by others simply as what factions you're aligned with. If I, as a character, consider Orcs to be evil, and you are aligned with an Orcish faction, then you must be evil. Within a faction, characters have rank and reputation, so you can also consider members of your own faction as bad, if they have, say, a negative reputation. But, this alignment is for RP and interaction purposes only. NPCs might react based on your "alignment". But objects, spells etc. won't be affected by it. Perhaps certain spells will cause you to gain/lose favor with certain factions. Casting big bad death spells won't get your brownie points with the nice healer's guild, for example.
We're not yet sure how to do area effect spells. Haven't really thought about it, actually. :)
Finally, for status conditions... Well, this is a tricky one. It would be nice to have status conditions be modular like everything else. Flying, or floating rather (since flying can be complex) for instance is a fairly good example since it doesn't (necessarily) have far-reaching consequences. Fatigue however can affect things all over the place, which makes it hard to modularize. But, it's ok to have modules that have a certain amount of cross-dependency -- again, as with my magic module example above, as long as the general framework is the same, everything's happy. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|