C#, Angband and Unity

[Mars]

So, it's two (and a bit) years later. What's the current situation?

[snip]

And that made all the difference in the world. I now have a fully working and fully featured C# version of Cthangband 5.1.0 as well as a C version. There's no remaining un-ported code left.

Wow! Color me impressed !

IMO, things like this are quickly underestimated. Probably why these attempts usually die an early death most of the time.

[jupiter999]

I wonder if you still go for Unity or not?
I once worked on my roguelike using Unity, but shortly can't tolerate the fact that the game generated by Unity needs to spend quite some CPU resources even just idle Sorry...

[Gwarl]

Hmm... I'm not quite sure what you mean here.

The current architecture is that it's a Windows desktop application. The main window uses WPF to display its contents.

That's not ideal (I'm not a big fan of WPF) but - at least initially - I wanted something that would work "out of the box" rather than something that relied on third party libraries and complex install sequences.

That left me with three options:

1) Console
2) WinForms
3) WPF

I experimented with making it a pure console application, but the C# console implementation isn't all that quick, and things like wiping the screen and displaying a page full of text are noticeably slow. It's also restricted in colour usage to a pre-defined set of sixteen colours, and that set doesn't match the default Angband colours, so you have to put up with some merging and

So that left me options 2 and 3. Given that WPF takes advantage of hardware acceleration, and WinForms doesn't, I went for that. It has the advantage that you can easily change the font and window size on the fly without needing a re-start, and all the text takes advantage of ClearType font rendering so it looks nice and crisp regardless of resolution.

However, I do say that this is the current front end. I've deliberately abstracted the front end so I can switch to a different technology or library very easily.

There's a cthangband shaped hole at http://angband.live/ - I compile a lot of variants and I can't remember exactly what my guess was as to why I couldn't get cthangband working, but in most cases for Z variants it's related to a bug in Z where gcc wouldn't recognise a 64bit compiler flag and the RNG got a wrong number of bits. The fact it's in active development again motivates me to give it another try, but it needs to run in a terminal and to compile without the aid of microsoft.

Where's the download for the C version of 5.1.0?

[Pete Mack]

@Gwarl--if you're really ambitious, you can install Mono and use the C# port. But it really is ambitious: if the port is pure C#, it won't work with your Term_xxx port, so it'd need some bridge code. MS did a good job with C#. It's a better language than Java. But I don't know how much of the latest language features Mono has implemented (Tasks and LINQ are the big ones.)

[Dean Anderson]

I wonder if you still go for Unity or not?
I once worked on my roguelike using Unity, but shortly can't tolerate the fact that the game generated by Unity needs to spend quite some CPU resources even just idle Sorry...

I really don't know, to be honest.

I might give it a go, but I want to get the code cleaner and more stable first.

[Dean Anderson]

There's a cthangband shaped hole at http://angband.live/ - I compile a lot of variants and I can't remember exactly what my guess was as to why I couldn't get cthangband working, but in most cases for Z variants it's related to a bug in Z where gcc wouldn't recognise a 64bit compiler flag and the RNG got a wrong number of bits. The fact it's in active development again motivates me to give it another try, but it needs to run in a terminal and to compile without the aid of microsoft.

Where's the download for the C version of 5.1.0?

There isn't one, at the moment.

To be honest, it might be more effort than it's worth anyway. As part of the 5.1.0 changes, I stripped out much of the non-Windows code in preparation for the C# port.

So although there is a C version of 5.1.0 on my hard drive, it's explicitly coded for Windows; compiling inside VS2017 and incorporating a built-in front end.

To explain the front end: As part of my attempt to drag it kicking and screaming into the twenty first century, I've got rid of the whole thing where you load a character by starting the program with a command line argument and then when you die or save-and-quit the program dumps you back to the desktop. Instead, when you start the game you get to the main menu which includes multiple save slots like most modern games, and a character dying (or you doing a save-and-quit) brings you back to that menu rather than exiting the program.

It makes the game much more user-friendly, but probably means there's very little compatibility with what you're doing. Since it's been nearly 20 years (give it another six months or so) since Cthangband was forked from
Zangband, I figured that trying to maintain any sort of compatibility with other Angband versions was a fool's errand, and I may as well make wholesale changes.

That's in both the C and C# versions, and both of them automatically put your save games in the Windows user folders.

I should put the game online somewhere for people to download, though. I was thinking of waiting till I'd finished the refactoring (because some of it might break save files, which could be frustrating) but if I sort myself out a website for it I can stick it up as a beta.

[johnretroreload]

Unreal VR angband?

I always wanted a VR angband style SAO game with 100 floors of a tower like Druaga with portable items between the two games. Past vs future kind of thing.
I did just find this on neverwinter 1
ftp://neverwintervault.org/rolovault...754/index.html

[PowerWyrm]

I always wanted a VR angband style SAO game with 100 floors of a tower like Druaga with portable items between the two games. Past vs future kind of thing.
I did just find this on neverwinter 1
ftp://neverwintervault.org/rolovault...754/index.html

If you can plug your VR device on your PC, try PWMAngband with NotEye in FPP mode

[Dean Anderson]

So, it's been a few months but I'm back again.

And this time I have a link!

Link

Basically, I finished the intitial pass at re-factoring the code; and although it worked and was a fully functional version of the game, it wasn't very "nice" C#. It had a small number of classes and most of them were thousands and thousands of lines of code. The fifty thousand lines of C# code worked but weren't very well organised.

So since then, I've been alternately playing it and doing more re-factoring to make it nicer and cleaner.

A classic example is the spell code. In the original C, that code consisted of a global array containing the level/cost/failure/xp for each spell for each class (and Cthangband inherited Zangband's spell system, so there are far more spells than there are in Vanilla - as well as many more classes - so that array was *huge*) and another global array containing their names. Then, there are a few global uints that contain bit-flags for which spells are known, forgotten, and have been cast at least once. Finally, the code for casting spells is a huge switch statement with 256 cases for the 256 spells, and the code for displaying spell info is also a huge switch statement with 256 cases for the 256 spells.

While all this works, having the spell data separated in this way is really awkward to maintain. Everything is done by look-ups, offsets, and indices; and cross-referencing a spell to see how much mana it should cost requires going through the tables by hand counting off the spell numbers.

The first re-factoring pass that I did converting this from C to C# basically left the structure unchanged. The spell names and spell numeric info were still global data (although since C# doesn't really have the concept of global data they were technically static members of a "GlobalData" class). The bit flags were still there, albeit now represented by a "FlagSet" class that wrapped the underlying uint with some user-friendly functions (and no longer global - the FlagSet objects for them were properties of the "Player" class). The humongous switch statements were still there too, although one of them was now contained in a function within the "Player" class and the other was now contained in a function within the "CastingHandler" class.

Again, it still worked - and it was C# code rather than C code - but it was still a mess.

So the second re-factoring pass that I've been doing (and which is still ongoing, although this particular part is finished) has cleaned it up.

Now there's a "Spell" class that holds the basic information for a spell, and there is a class for each individual spell that inherits from "Spell" (for example "SorcerySpellZap" and "NatureSpellHerbalHealing"). The data for the name of each spell is held in the class, and when it's initialised it's passed a reference to the player so that it can set its own level/mana/fail/exp values based on the player's character class. The spell info code is no longer in a switch statement but in a function within the "Spell" class (that uses a property that each inherited class overrides), and similarly the code for casting each spell is held in an abstract function within the "Spell" class that each individual spell class overrides. The flag sets are now individual flags belonging to the "Spell" class, so each individual spell inherits them.

When a character is created, there's a function that simply fills their spell book (an array of "Spell" objects - which, thanks to polymorphism, can therefore hold any object derived from "Spell" too) with a copy of each of the relevant spell objects.

So all the info for any individual spell is contained in a nice logical unit. Adjusting a spell or swapping one out for something different can be done trivially, without having to search through huge tables of numbers to find the right values to tweak. Displaying the spell info just requires a simple look through the spell book asking each spell in it to display its own info, and casting a spell just requires a simple call to the spell to cast itself.

So that's the sort of thing that I'm doing now. I'm breaking up the overly large and linear classes that I got in the first pass into more logical and usable smaller classes, and actually developing a proper object model as I go.

I'm in no way finished (although I've done most of the really big ones), but I am far enough through that I'm happy to release a new version to the world, especially since the end of July was Cthangband's 20th birthday (I released the first version - Cthangband 2.1.0 - back in July 1998).

So here it is. The link above is for the installer for Cthangband 6.0. It's fully C#, and should run on any Windows machine running Vista or more recent - although if you're running on Windows Vista to Windows 8 you might not already have the .NET Framework 4.5.2 installed, in which case you can download that directly from Microsoft here).

[Pete Mack]

Wait, angband no longer has a giant case statement for spellcasting. It does call by name (m9re ore less) using generated code from a .h file. You must be running off an older codebase.

[AnonymousHero]

Wait, angband no longer has a giant case statement for spellcasting. It does call by name (m9re ore less) using generated code from a .h file. You must be running off an older codebase.

Read the OP.

(This is a really impressive amount of work, btw.)

[Dean Anderson]

Wait, angband no longer has a giant case statement for spellcasting. It does call by name (m9re ore less) using generated code from a .h file. You must be running off an older codebase.

Cthangband was originally based on the Zangband 2.1.0 codebase. Both it and Angband have drifted quite far apart over the last two decades (although the big switch statement is something that is left over from the Zangband code, not something new).