My variant development journal

[Donald Jonker]

It sounds like he's going to make it from scratch, not from the Angband codebase so it's not a *band. Instead it should be <drumroll />

Smokebanned.

Are you sure you're not thinking of this thread? The OP here is basing his off of Sangband and thus is making a *band... unless I'm missing some nuance.

[Atarlost]

If you have an open mind, I have a theme for you. And no, I'm not entirely joking.

Name: Smokeband

It sounds like he's going to make it from scratch, not from the Angband codebase so it's not a *band. Instead it should be <drumroll />

Smokebanned.

[Donald Jonker]

If you have an open mind, I have a theme for you. And no, I'm not entirely joking.

Name: Smokeband

Premise: You work at the top level of a skyscraper, and take frequent smoke breaks in the men's lavatory by exhaling through a vent. Today's been a bad day. Rummaging through your drawer, you realize you left your handy pack of smokes in the car, which is in the garage under the building. Panic building, you overhear a coworker complain that the elevators are all out of order.

You must now fight your way down through a building filled with high-and-mighty people hostile to smokers who seem committed to compromising your sanity. All this builds to a final fight with, you guessed it, the all-powerful Rob Reiner.

HP=Sanity Points

!CCW = Nicorette

Races = Different brands of cigarette: eg. Marlboro=Human; Camel=High-Elf; Newports=Half-Troll; Luckies=Dunedan.

Thrall mode = forgot your keys

With a little imagination you can veil the rest of the game similarly in modern-day office innuendo. Instead of swords, loudspeakers. Instead of helmets, ipods. And so on. There may be some licensing issues...

[CJNyfalt]

So, I started developing a variant again.

Since I noticed I had this thread, it's better to dust it off than start a new one.
The last effort was eaten by WoW.
Most things does after all apply, except for the C++ stuff, which I will wait with. I want to focus on the gameplay stuff, and avoid getting tied down with technicalities, since that tends to kill off my inspiration.

This new effort is also based on Sangband, just like the last one.



What I have done so far:

License and copyright related:

- Removed .mid music files whose legality was suspect.

- Updated license information for source code which now have GPL
permission.

Bugfixes:

- Set player_egid in SDL port.

- Monster memory had RF&_DARKNESS twice, second one fixed to RF6_CURSE.

Id:

- Get average feelings from also weak pseudo-id.

- Removed amnesia.

- Id spells now work like *Id*. Scrolls of *Id* removed.

Stats:

- Removed Mushrooms of Metamorphosis.

- Removed stat shuffling from Nexus.

- Removed traps of remold player.

- Use natural stat notation instead of 18/xxx.

Other gameplay changes:

- Artifacts made immune to disenchant.

- Removed teleport level attacks from monsters.

- Removed possibility that portal traps teleport player to another
level.

- Disabled trap doors.

- Nexus no longer set recall or teleport player to another level.

- Weapons and armor are no longer destroyed by elemental attacks when
in inventory.

- Improved infravision. Cave features can now be seen by it.

I will cover my plans in my next post.

For now I'm interested in comments and questions about my changes. I'm also interested in issues that people have with Sangband 1.0.0 final, which is what I'm basing this variant on.

Lastly I want to state that this will not be an improved Sangband, I plan to make this variant quite original once I'm able to.

[CJNyfalt]

A static member of the class won't be any less memory efficient with multiple PC's. That's what I've done somewhat in Zaiband.

Well, that would work if each of the different skils was different classes, but they are objects of the same class. So, the problem is that it's a two-dimensional setup and the static-ness is only allowed across one of the dimensions.
Hmm, what about something like this:

class s_static{
  skill_static st[NSKILLS];
};

class s_dynamic{
  skill_dynamic sd[NSKILLS];
};

class skills{
  static s_static sst;
  s_dynamic ssd;
};

That would allow me to declare the static part static, but one the other hand member functions that needs both parts would then need to be part of whole skill package instead of part of the individual skills.
I have to think about it.

[zaimoni]

As it's now, the skill system uses two classes, one for the static info and one for the dynamic info. Having the static info class be a member of the dynamic info one would make sense, but that might be memory-inefficient if I decide that there should be more than one PC in the future.

A static member of the class won't be any less memory efficient with multiple PC's. That's what I've done somewhat in Zaiband.

[CJNyfalt]

Also don't forget to consider O/FA specialty abilities, at least if you want to preserve the class system. They add a lot to character customizability, and you could tune their impact on gameplay to make them as powerful as oaths or D&D-style feats.

In a classless system I think they would become less important for customizability, and more suitable for balancing (as it happens with TOME abilities).

Dario

Yes, that's really something to consider.


Skills

So, I removed all restrictions on putting points in a skill, except the restriction on having both piety and blood domination at the same time. And even that is not unthinkable since I have played WoW priests.

Now, to other things to consider regarding the skill code. First we have the cost reduction from similar skills. This code is ugly and I don't like it at all, I would rather remove it. For some of the skills it makes sense to remove the cost reduction (ranged, forging), but for other it's harder finding rationale (melee, rogue). One way of reducing this trouble would be to add general combat skills, and go for a more tree-like approach to skills, like Steamband.

Second there's the case of code organization. As it's now, the skill system uses two classes, one for the static info and one for the dynamic info. Having the static info class be a member of the dynamic info one would make sense, but that might be memory-inefficient if I decide that there should be more than one PC in the future. There's also a lot of code in skills.cc that I would prefer to be member methods of the classes. Now, the trouble with doing this merger is that these functions use the power/exp tables and stuff that doesn't belong in a skill class. The worst offender in teh constant PY_MAX_POWER that's all over the place.

[kathoum]

Maybe if they were changed so they more about granting extra powers, and less about restricting skill access?

Also don't forget to consider O/FA specialty abilities, at least if you want to preserve the class system. They add a lot to character customizability, and you could tune their impact on gameplay to make them as powerful as oaths or D&D-style feats.

In a classless system I think they would become less important for customizability, and more suitable for balancing (as it happens with TOME abilities).

Dario

[CJNyfalt]

You might want to look at these poll results on Ascii Dreams for inspiration.

Andrew

Hmm, there's nothing that really stands out to me on the list.
Maybe a mix of Fantasy, Steampunk and Alien, but then I have to avoid making it too close to Steamband.


On the coding front, I have now converted both skill structs to classes.

What I'm now pondering is the oaths. Which are a kind of pseudo character-classes in Sangband. I don't like them, and will probably remove them, unless someone have a good argument for keeping them. (That they disallow a character from mastering everything isn't a good argument.)
Maybe if they were changed so they more about granting extra powers, and less about restricting skill access?

[andrewdoull]

There's always retro-futurism; add in aspects of technology that you like, whatever that may be, while leaving out troublesome things like guns.

You might want to look at these poll results on Ascii Dreams for inspiration.

Andrew

[Patashu]

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.

There's always retro-futurism; add in aspects of technology that you like, whatever that may be, while leaving out troublesome things like guns.

[CJNyfalt]

Thanks for the comments they really stimulated my thoughts on the issues.

XP-draining blinding breath...ouch. Think about the play balance of this one.

This comment shows how useful it is to get feedback. Not that I care about balance at this point, no.
What it really brought to mind was the difference on how we think about the breaths and their elements. You think about secondary effects, I think about source of the damage.

Breaths, elements and resists
- It seems like there are two ways, at least, on how a resist can be considered. Either you resist the magic that causes the effect or you resist the effect itself. This is something I have to think about some more.
- I might keep nexus in some form, now that I have removed what I hated most about it.
- Chaos has to go as a damage source, and what isn't damage about it fits under confusion.

It's about the character, not the gear
Expect that it will become more important how you build your character and less important what gear you have. Stat potions will be removed, and replaced with stat points gained by experience. Exp draining will probably be replaced by stat draining. The skill system will also get a major overhaul at some point.

Stats
The question that troubles me about stats at this point is what's the bottom?
How far down should a stat be drainable and what should the effects at the lowest point be? For example: the jump from -5 to you are disabled/dead as you go from 1 to 0 in the d20 system doesn't make sense to me. A solution would be to allow stats to go into the negative as far as data type restraints allows, but then it doesn't make sense that 10 and not 0 is the normal baseline.

[zaimoni]

Elements and resistances
Some thoughts:
- ...
- Dark and Nether should be merged.

XP-draining blinding breath...ouch. Think about the play balance of this one.

- Shards shouldn't have a resist, AC should reduce shard damage instead.

Mortal wounds are just that: mortal. They do not naturally heal. This change will make potions that heal cuts far more important.

- Nexus, Chaos and probably Disenchant will be toned down or removed. This isn't Warhammer. The stat-shuffling part of nexus is already removed.

The actual source of the exotic breaths (other than the basic five: fire, cold, electricity, acid, poison) is the defunct I.C.E. RPG set in Middle Earth, which fell afoul of contractual differences with the Tolkein estate.

[xxitheworld]

- Dark and Nether should be merged.
- Shards shouldn't have a resist, AC should reduce shard damage instead.
- Nexus, Chaos and probably Disenchant will be toned down or removed. This isn't Warhammer. The stat-shuffling part of nexus is already removed.
- Most of the very exotic, non-resisted elements will be removed (Gravity, Time, Inertia, ...), at least as direct damage.

No offence but I think this would remove some cool elements of the game and somehow make it a little boring, you'd need to compense with other new nice stuff

- Resists needs to be made numerical in some way, except for fear, blind and confusion.

I think making it too numerical (Percentages for example), could make the game a little too number-oriented and again take out the fun of it
What I would suggest is a few levels of resistance like
Weak Resistance
Medium Resistance
Good Resistance
Immunity

[CJNyfalt]

Elements and resistances
Some thoughts:
- What's an element should be defined clearly.
- Resists needs to be made numerical in some way, except for fear, blind and confusion.
- Dark and Nether should be merged.
- Shards shouldn't have a resist, AC should reduce shard damage instead.
- Nexus, Chaos and probably Disenchant will be toned down or removed. This isn't Warhammer. The stat-shuffling part of nexus is already removed.
- Most of the very exotic, non-resisted elements will be removed (Gravity, Time, Inertia, ...), at least as direct damage.
- In most other variants I would remove them directly, but it seems like S has most spells associated with an element. For example all teleportation seems to be nexus.

C++ effort
I added a stat class today. Stat-shuffling was removed in this process. For now it only covers the old stat_birth, stat_max and stat_cur variables and STAT_MAX and STAT_MIN constants. I haven't decided if adding stat_use, stat_ind and stat_add variables and the tables to the class is useful or not.