One of the most ironic things I find about writing a Roguelike game is that the ideas for additional content never seem to stop bubbling to the surface. And that, when analysed, most of these ideas come from either other RLs, CRPGs or (especially) MMORPGs.
For example, instead of coding, I've been playing (and dying mainly) a lot of Sangband recently, and I've realised that the lack of character classes is an inspired design choice. Much has been written about classes in Roguelikes, and eventually, perhaps, I will also want to take Kharne into a classless direction. Classes are, on one hand, convenient labels/stereotypes for a character and on the other, a restrictive straightjacket preventing the character from achieving his or her true worth.
Another idea which I think might prove to add another facet to gameplay in Kharne is Reputation, which in a World of Warcraft context is:
You can gain or lose favor, otherwise known as Reputation, with many of the several different factions in Azeroth by completing certain quests or killing certain creatures. Doing so will usually unlock special rewards or new quests to accomplish.
My only concern with implementing reputation is that it can turn into a mascochistic grind very easily - there are majoring game-play balancing issues to be considered (much like Pudding Farming in fact), but a synergistic reputation system that minimises repetitiveness could add much to a RL.
Another idea, currently being discussed on r.g.r.d is that of Dungeon Morphing, dynamically changing the dungeon either independent of the player or as a response to the player's actions. Where I think this could be extremely interesting is implementing timed levels that require the player to do something in a certain period of time or else face near- or certain doom. Like in Oblivion for example.
Leaving all this side, on the development front, my current task is finishing the monster implementation, which I need to do before I can progress magic further. One of the decisions I made early in the design process has come back to bit me slightly. I've made great play (here on this blog and elsewhere) of the fact that our brave little @ is just another creature. But why does a rat, for example, need to receive the same treatment as our @ in terms of having an inventory and suchlike? And do rats really need to have Charisma stats as well as Armour and Evasion?
Subscribe to:
Post Comments (Atom)
9 comments:
I took the same view for my design. I don't have monster's yet, but I do have the concept of a common Actor i.e. the monsters and player are all actors.
Won't a rat just be an actor with no inventory and a 0 value for charisma. I expect a rat to have high agility, low strength. (Yes it needs more thinking).
I am hoping to encapsulate a lot of this behaviour in the Race class. I.e. using the "Rat" race as something that defines the properties and abilities of the "Rat" actor.
The polymorphic behaviour (and benefits) of treating all the actors the same within the game design should outweigh any customization difficulties inherit in such a design.
Or do you disagree?
Or do you disagree?
I largely agree. I think my main discomfort at the moment is due to the fact that I designed the creature/actor class from the viewpoint of the player, and realistically monsters don't need as much information defined about it. So when I go to define, say our rat, I suddenly need to know all its stats in order to define its Armour and Evasion and so on, instead of just (like in the old Kharne, which was based on AD&D) arbitrarily assign these values.
I recall that D&D went through similar pains evolving from AD&D to 3.0/3.5, where suddenly monsters could be playable and had classes/levels/race templates, all the properties that PCs have.
But you are right - the benefits of such a consistent approach far-outweigh the drawbacks. The fact that monsters can have inventories, for example, makes greedy monsters, for example, simple to implement.
Well...there's always half-measures.
My Pascal is definitely rusty, but if you have enough single-inheritance polymorphism you could do something like
Item_historical -> Item
|
v
Agent_historical
|
v
Agent
Where Agent is the common base class of both the player and the monsters. [This is what I'm doing for my game family. If I didn't have to plan for lightspeed lag, I could get rid of the historical classes and just derive Agent from Item.]
I haven't designed my game as far as you have :(
So I don't have an opinion on how a rat would be different than a human.
Stuff like inventory, attacks, racial attributes and skills are a bit in the air right now.
I'll let you know what I come up with when I get there.
Kenneth,
yeah, Delphi does have that kind of functionality, but I'm considering doing something a bit similar but using Interfaces instead.
At this point however, with the current implementation, the prospect of having to sit down and generate (differentiate) and input the stats of some 70 different monsters is actively hindering me from sitting down and generating and differentiating the stats and details of said 70 different monsters.
No one said writing roguelikes was easy, heh.
Or you could go the customizable-characteristics approach. Some of my statistics and all of my skills are set up this way, because there is no way I want however many # of skills set to 0, and dodge and bite to 1 for all the stupid little rats running around. Each actor has a SKILLS container, and somewhere each SKILL # is defined or enum'd as whatever it is (1 is dodge, 2 is bite etc.), so the actors only need to possess whichever skills they actually have.
Agreed, your suggestion is more flexible.
I don't know if I'd go the enum route as I'm guessing you have a huge switch statement somewhere to deal with the different skills' logic.
But would rather encapsulate the skills in a command pattern or something similar. Maybe a list of function pointers.
or am I missing the boat
I dont have a huge list of switch, but I do have a huge list of #define Attack 1 #define Defend 2 (I don't really use enum's but that seems to be exactly their function). Then whenever i need to call on whatever skill I can use "Defend" or the # if I remember it. I think you might have been referring to something else though, and I do have to have some complicated checking for actions that could possibly use many different types of skills like combat, but mostly it is just the chopping a tree function calls on TreeChop skill or whatever.
The only bad thing I ran into was when I got a little bit carried away and start putting almost everything into structures like that -like Race or Name or something - then all the functions or values that happened to have that name broke.
This is also how I handled the different kinds of items. It was a little bit complicated to get set up at first, but it was pretty interesting and extremely flexible. My ITEMS only contain location, visual output and a map of MATERIALS. Each material has a type and 7 variables. Each different material is things like weapon, armor, magic, energy(for fuel, either how long firewood will burn or how long a torch will burn or how many charges are left in a wand etc.). Now I am not confined in any way when it comes to items, or with adding however many different magical effects for example. The only minor drawback is only two of the materials I have so far use all 7 of the variables, but that is negligible.
One possibility is to go with a component model. Instead of all actors having an inventory, you allow for something equivalent to QueryInterface( INVENTORY_OWNER_IID ). This can allow for some interesting behaviour such as a squad of critters having a shared inventory (a cheap way of modelling resource sharing, perhaps?), and equally your exemplary rat can return a null object.
I'm not a huge advocate of component systems, as I think the complexity overhead usually more than outweighs any elegance afforded, but it's a possibility.
My current solution is stupid, simple and dirty; all Pawns (controllable actors) have inventory, and at the moment all attributes and skills for a pawn are a stored in a hash table whimsically called a character sheet. Null entries are interpretted as a zero score, so a rat would have strength, dodge, nibbling skill etc. but probably no charisma score in the loosely defined D&D sense. But then I have pet rats and I'd say they're pretty charismatic IRL :)
Post a Comment