My variant development journal

[CJNyfalt]

I finally got my inspiration back, and started working on the resists (and spell realms).

What I want to do is to define a number of spell realms that each have their own resist, opposite realm and associated GFs.

I decided to use WoW spell realms as a model.

The opposing pair would be:
Fire - Cold.
Holy - Shadow.
Arcane (unnatural) - Nature.

Now, I decided to start with merging resists, since it seems like an easy point to start at.
We have 16 resists in Sang:
- Fear, Blind, Confusion: These are resists for specific effects, not damage, so they don't count.
- Fire, Cold: No change.
- Light: Holy.
- Dark, Nether: Merge to Shadow.
- Shard: Physical, should be reduced based on AC.
- Nexus, Disenchant: Merge to Arcane.
- Chaos: Remove and/or convert to Fire. (With order=cold.)
- Acid: Nature.

and the problem childs:
- Electricity: Nature? Arcane? (Going with WoW this would be Nature.)
- Poison: Nature or remove direct damage.
- Sound: Can't get to fit. Convert to Holy?

A big problem is that Nature=Elec+Acid+Pois would be way too powerful.

[CJNyfalt]

I have spent time on add colors to the monster memory (same scheme as in Oangband), and doing some internal C++ conversions.

[CJNyfalt]

For the TMJ problem, I'm considering the solution of removing junk. That is, item types that are worthless. (Cursed/Bad armors & weapons would still be generated.) To compensate for the better drops, I could instead reduce the number of items generated on a level with one.

Thinking about it some more, I decided that the situation isn't all that easy. Once you add the possibility to have monster allies, stuff like Heal Monster, Haste Monster, and so on, becomes more valuable.

Well, I could at least remove stuff like Shard of Pottery and Broken Stick.

[CJNyfalt]

I went with a dungeon size of 55x88, which is about 25% bigger than 44x77. This new size seems fine.

I also made detection spells detect the whole dungeon.

Playtesting this seems fine, but the next annoyances are TMJ and the detection game.

For the TMJ problem, I'm considering the solution of removing junk. That is, item types that are worthless. (Cursed/Bad armors & weapons would still be generated.) To compensate for the better drops, I could instead reduce the number of items generated on a level with one.

[CJNyfalt]

I made the levels a little too small, no room for greater vaults.
Some numbers for comparison:
Angband 3.0.9/Oangband: 66x198
Sangband: 88x154
Changed size: 44x77

I think that a size of 55x88 or 55x99 would be best.

[PaulBlay]

No, you wouldn't be worried about what what it was, and therefore, all things being equal, if you were to start at a point and excavate (1 square) in a random direction (and repeat), at any give time the shape is most likely to be squarish (I think). That's my theory, at least.

Do a Google image search on 'Drunkard's Walk'.

[buzzkill]

Logically? If I were mining underground I'm not sure I'd be worried about whether my dungeon was square or circular...

No, you wouldn't be worried about what what it was, and therefore, all things being equal, if you were to start at a point and excavate (1 square) in a random direction (and repeat), at any give time the shape is most likely to be squarish (I think). That's my theory, at least.

[takkaria]

Logically, they should be roughly square or circular, if any shape. The ONLY reason they are rectangular is because of screen size. Personally, I'd like to see square.

Logically? If I were mining underground I'm not sure I'd be worried about whether my dungeon was square or circular...

[buzzkill]

I don't think there's any benefit to having square levels when you consider that screens aren't squares.

Logically, they should be roughly square or circular, if any shape. The ONLY reason they are rectangular is because of screen size. Personally, I'd like to see square.

[PaulBlay]

Well, I quartered level size from 88x154 to 44x77. The smaller levels and higher monster density seems to make the game more fun, but I might have gone too far.

There are some things I have to consider now:
- Do I make levels a little bit larger again?

You could just make a few less monsters instead.

- Do I make levels a square or a rectangle?

I don't think there's any benefit to having square levels when you consider that screens aren't squares.

- Do I make detect spells work on the whole level, or not? This would simplify the code and remove the track detect area problem.

Sure, go for it. Monsters move / appear anyway so people won't get a huge advantage from it (IMO).

[CJNyfalt]

Next up on my TODO is now:
- Make levels smaller. Halving both height and width seems suitable.

Well, I quartered level size from 88x154 to 44x77. The smaller levels and higher monster density seems to make the game more fun, but I might have gone too far.

There are some things I have to consider now:
- Do I make levels a little bit larger again?

- Do I make levels a square or a rectangle?

- Do I make detect spells work on the whole level, or not? This would simplify the code and remove the track detect area problem.

[CJNyfalt]

Next up on my TODO is now:
- Make levels smaller. Halving both height and width seems suitable.
- Make use of C++ features.

[zaimoni]

C code is not trivially compilable as C++, though. And C++ compilers aren't that much better at catching things than C compilers with the appropriate warning options set.

C code almost is trivially compilable as C++, however. I don't see any errors when building V SVN as C++ that aren't trivial fixes; almost all of the errors are assigning from void* to some other pointer without a cast.

The real advantage of C++ over C, however, is that by careful choice of overloading you can make the compiler intercept a lot of proofreading for you. (Static assertions are a wash, as careful use of the concatenation operator ## in conjunction with typedefs will get you a C-implemented static assertion.)

The disadvantage, of course, is that C++ namespaces and overloading make it *much* harder to implement a C++ compiler than a C compiler....

[konijn_]

C code is not trivially compilable as C++, though. And C++ compilers aren't that much better at catching things than C compilers with the appropriate warning options set.

Well, this post got me think otherwise;
http://roguelikedeveloper.blogspot.c...all-graph.html. I am just repeating what unandrew said.

I will agree with the non-trivial part, I am probably goofing up Hellband with the whole void* and char* stuff.

T.

[takkaria]

It's trivial to compile any band in a C++ compiler. It's damn hard to rewrite the band's source code to take advantage of the object oriented features of C++

C code is not trivially compilable as C++, though. And C++ compilers aren't that much better at catching things than C compilers with the appropriate warning options set.