My variant development journal

[buzzkill]

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

Id' rather have the gold, I can find the crappy armour on DL1. Nobody 'needs' a shovel. 3 WoR is excessive. You only need 1 to recall from your first dive, then you should have enough GP to buy 2 more (if not, tough luck). If you start with 3 I feel that 2 will be sold off rather than used. Cut back to 3 and 3 on the PD and CLW, they are cheap enough to buy more if you want. I'd prefer 10 PD and no CLW, which is why I'm not crazy about starting equipment in the first place.

In fact, cut it back to the essentials, 1 CLW, 1PD, 1WoR, 1 cloak, and GP to shop with. Maybe a birth option to start with a basic kit and less GP. Or, a birth option that lets the player 'shop' during character creation.

In short, I guess I'd rather have 1 good item than 19 weak items.

There's no weapon included in the list, an over site? or shovel...

[PaulBlay]

So,
I know nothing about C++ but as I understand it, it is trivial to convert any band to C++.

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++

[CJNyfalt]

1. player_invis. I'm not familiar on the inner working on this skill, and I'm not going to study it closer now. I know that if it return true, an awake monster moves randomly, otherwise it chases/attacks the player. Feel free to study it yourself.

2. Starting gear. Well, I prefer having starting gear to speed up the early game by not having to shop after each character creation.

I
There's no weapon included in the list, an over site?

No. Since it's impossible to know which melee skill the player will pick, there's no starting weapon.

3. C++. Here's a short summary of the conversion process:
Converting a band to C++:
1. rename source files from *.c to *.cc
2. edit makefile to use C++ compiler
3. Fix compiler errors, of which two types dominates:
a) Missing casts. C++ is pickier about pointers, so it requires more casts.
The usual suspects are the z-virt.h macros and init source file functions.
b) Variables that have names that are reserved words in C++.
(class, try, ...)

[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.

[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.

[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....

[CJNyfalt]

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

[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.

[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).

[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.

[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]

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.

[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'.

[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.

[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.