My variant development journal

[Pete Mack]

Some of the monsters I'm having a hard time to classify and make up my mind about:
- Weres
- Griffons, Hippogriff, Harpy, Minotaurs
- Undead whose catergory isn't clear: Undead mystic, Undead beholder, nightwalker, nighstalker, nightwing, dreadlord
and several others.

This is why the whole categorization thing is a problem--these are all either hybrids (Weres & Griffon,etc), or are an "ex" thing. As in a nightwing is an ex-parrot.

[buzzkill]

I'm not knowledgeable about the inner workings of Angband so bear with me.

If I'm understanding this correctly, you want to categorize the 'races' (I don't remember what you chose to call them) so can assign them a set of base attributes that are common to all, correct?

Why not just have a beast or hybrid class that has no base attributes. You can throw all the odd balls in there and define them the old way, though that may be a bit hackish if even possible.

Wouldn't making 'undead' an attribute instead of a class make thing easier? Then things that are strictly undead like ghosts or wraiths could be categorized by themselves as 'ghost-like', and undead whatevers would simply fall into their base category.

[CJNyfalt]

I'm not knowledgeable about the inner workings of Angband so bear with me.

If I'm understanding this correctly, you want to categorize the 'races' (I don't remember what you chose to call them) so can assign them a set of base attributes that are common to all, correct?

Why not just have a beast or hybrid class that has no base attributes. You can throw all the odd balls in there and define them the old way, though that may be a bit hackish if even possible.

Wouldn't making 'undead' an attribute instead of a class make thing easier? Then things that are strictly undead like ghosts or wraiths could be categorized by themselves as 'ghost-like', and undead whatevers would simply fall into their base category.

Well, I could but I don't want to, since I don't like having one-monster odd-balls.


More changes done:
- Lightning jaws & Stone serpents are now 'E' instead of 'J'.

- I removed also Manticores and Shambling mounds.

- I decided to keep Minotaurs and icky things at least for a while.


some thoughts about future changes:

- I want to remove the oaths, since I would prefer other methods of limiting characters.

- Gaining stats. I will remove potions. So far I see the following methods of gaining stat points:
a. The player gains stat points they can allocate freely.
b. The player gains in stats related to skills they have increased.
c. The player gains stat points that are allocated randomly.
Each methods have benefits and drawbacks, so I would like to hear some feedback on them.

- Spell realms. The WoW organization of six realm types (fire, cold, nature, arcane, holy, shadow) seems attractive to me right now. The would decrease the number of books in each realm, and allow for a more Z-like magic schools.
This would give three pair of opposites fire-cold, nature-arcane and holy-shadow, allowing a character to have three strong spell realms or six weak ones.

[PaulBlay]

- Gaining stats. I will remove potions. So far I see the following methods of gaining stat points:
a. The player gains stat points they can allocate freely.
b. The player gains in stats related to skills they have increased.
c. The player gains stat points that are allocated randomly.
Each methods have benefits and drawbacks, so I would like to hear some feedback on them.

I would have no objection to any of those methods. (b is used extensively in elona, btw, a is used in Portralis). However if you go for (c) I would suggest that you be a bit more generous with the stat bonuses.

[PowerDiver]

- Gaining stats.

Each methods have benefits and drawbacks, so I would like to hear some feedback on them.

How do you feel about newbies? If they are not random, it is one more decision a newbie is likely to get wrong. The most compelling reason for allowing a choice is to boost classes that only rely on 3 stats compared to classes that rely on 4.

[CJNyfalt]

Thanks for the feedback!

I think I'll go with option c for now, I can always change the method later. It's also the easiest to implement, and would not differ all that much from the current model. You would just get your stat potions at pre-determined times according to your power level instead of having to farm them.

As for option a, as was stated there's the problems of giving new players too much to worry about and the fact that veterans will min-max a bit too much. I also don't like the idea of players putting all points in one stat until it's maxed.

Option b has the problem that it's tied to the skill set, which I'm quite sure that I will change at some point.

[CJNyfalt]

The stat-gain implementation is successful.
No more stat-potion farming. This has been a major issue to me for a long time, so I'm glad to have finally gotten rid of it.

Since the stats are gained randomly, I decided to give enough points to max all stats. (average starting stat 13, maxed stat 28. Difference 15. 15x6 = 90.) So, I award 99 stat points, one for each power increase.

[CJNyfalt]

So, I'm now considering what to do next, and what to do at all.
So ideas of differing difficulty and plausibility:

- Add fire and cold spell realms.

- Remove restriction to only one spell realm. Go for a more Z-like spell casting model.

- Remove need for spell books and add techniques for melee characters.

- Remove/rework oaths.

- Add some kind of spell realm-resist-GF table.

- Rework INT & WIS so both are useful for all casters, and preferable for non-casters also. WoW INT + SPI model?

- Holy and shadow are opposites, fire and cold are opposites. Are nature and arcane opposites?

- Rework skills. I don't really like the right-hand skills. I also think that the choice between tank-style and rogue-style melee could be handled better.

- Add a charm monster functionality.

I'm not sure what to start with here?

[PaulBlay]

- Remove need for spell books and add techniques for melee characters.

Spellbooks are somewhat annoying to carry everywhere. Maybe require them only for (re)learning spells so they can be kept in your house most of the time.

I'm not sure what to start with here?

I like my rogues, so could they get backstabs when they are hidden/invisible and the monster doesn't know where they are? I think that as long as the monster is awake, not running away, and adjacent to the rogue it is impossible to get backstab however hidden or invisible the character is. (Maybe I'm wrong?)

[CJNyfalt]

I like my rogues, so could they get backstabs when they are hidden/invisible and the monster doesn't know where they are? I think that as long as the monster is awake, not running away, and adjacent to the rogue it is impossible to get backstab however hidden or invisible the character is. (Maybe I'm wrong?)

I think you're right. So, this change would require the attack code to check player_invis for extra sneak attacks. Seems possible to implement. If it's possible for player_invis to return TRUE if the player is next to the monster and it's awake is another question. Well, if nothing else, it might help with ranged sneak attacks.

[Nick]

- Remove restriction to only one spell realm. Go for a more Z-like spell casting model.

Frazband has an interesting Z-like spell system that may be worth looking at.

[PaulBlay]

If it's possible for player_invis to return TRUE if the player is next to the monster and it's awake is another question. Well, if nothing else, it might help with ranged sneak attacks.

Leaving invisibility to one side, 'stealth' in Angband just means you're less likely to wake monsters up, right? The latest D&D version is (... goes to check ...) Stealth vs Perception. Stealthy rogues can hide behind some cover*, move silently up to monsters and sneak attack. Perceptive monsters can spot them. Invisibility gives huge bonuses to stealth, light sources and heavy armour give penalties.

* Possibly get by with just shadows after a certain level / class.

[konijn_]

So, I was intending to discuss future plans, but the playtesting I did yesterday had me deciding to consider starting gear and money instead.

The deal is that I consider the starting part of the game, where I have to gain enough money to afford the gear needed for diving, takes too long.
Now, I could give the player more starting money, but I think that it would be better to give more starting gear instead.
So, I consider giving each starting character the following, in addition to the torches and food:
- 5x !CLW
- 5x ?PD
- 3x ?WoR
- 5x ?Learn Magic
- A cloak
- A pair of Leather Sandals
- A hard leather cap
- A shovel

Opinions?

Hellband provides a robe ( seriously, just a cloak ? ) and a Lantern. No shovel though or hard cap though, this would not fit thematically with all races/classes.

T.

[buzzkill]

If it's possible for player_invis to return TRUE if the player is next to the monster and it's awake is another question. Well, if nothing else, it might help with ranged sneak attacks.

I wouldn't let a player_invis return to TRUE while in LoS of a monster, unless the player takes an action to do so. Maybe an class ability like 'hide in shadows' that

1. takes energy (a turn or portion of a turn) and
2. maybe takes some HP or mana or maybe the all new stealth points. Like mana, but for stealthy characters.

While out of line of sight, stealth or invisibility could occur naturally. Maybe not instantly at low CL's. Maybe even be sustained into lit area at high CL's. A player could accumulate stealth while walking in unlit areas. When he reaches a threshold he would become invisible. Inversely, he loses stealth when in lit areas (more quickly in LoS, lose all when hit, and maybe even go negative, making it harder for him to hide from a monster that is aware of him), and becomes visible once he drops below that threshold. Low CL's would accumulate stealth more slowly, and have a lower max_stealth so it would be unsustainable in the light.

In any case, going invis while standing next to an awake monster seems silly, because even with weak AI, wouldn't the monster be very likely to attack where you were just standing.

Most of this just came to me as I was writing this (quick reply) post. Not much thought went into it. There are a couple of different, maybe conflicting, ideas here. Feel free to call it overly complicated, hard to implement, and stupid if you like.

[konijn_]

I consider it, and haven't ruled it out. There are several problems with a 'futuristic' setting however. The most troublesome is that guns are too strong.

Onward to todays thoughts:

C++
I have a long time been an advocate for using C++ in *bands. Today I converted the program to be in C++ and added the first class. The good thing a about a C to C++ conversion is that it can be done gradually. For others seeking to make their programs use objects I would recommend to start with the small stuff, taking a bottom up approach. Starting with a large struct could easily lead to a mess that would take forever to clear up.

So,
I know nothing about C++ but as I understand it, it is trivial to convert any band to C++. Could you write a mini-tutorial on how to convert a band to C++ and maybe as a bonus how to write 1 part of a band out, put it in a class and make band use that class and then compile it ?

As I understand it, C++ compiler is much better in capturing potentially bad code and since there are some mysterious crash bugs at deeper levels, I would like to get a grip on that.

T.