NPPAngband/NPPMoria QT port

[nppangband]

Thanks. I did something almost exactly like that.

Soon I am going to go through all the notes on the Pyrel project. Right now the dungeon info is spread out over about 7-8 different variables. It could definitely be improved. I think the dungeon could be done much better with OOP, and well thought out C++ class. You did something like that already for Pyrel, didn't you?

[Derakon]

Thanks. I did something almost exactly like that.

Soon I am going to go through all the notes on the Pyrel project. Right now the dungeon info is spread out over about 7-8 different variables. It could definitely be improved. I think the dungeon could be done much better with OOP, and well thought out C++ class. You did something like that already for Pyrel, didn't you?

Yes, though it is exceedingly general and thus may get us into performance problems down the road. It's already causing some degree of trouble with saving/loading, though it's hard to say how much of that is down to our dungeon info representation and how much of it is because of the exceedingly general save/load system.

The basic concept is that the map is a collection of Containers, and each Container can hold any number of Things, from which all in-game entities are derived. There's a Container for each cell on the map, as well as Containers for all creatures, all items, each creature's inventory, each wall, etc. Simple functions allow you to perform set operations on Containers, so you can e.g. get all items in the player's inventory that are usable (as a triple-container intersection operation). This makes it easy to winnow down large collections into just the things you need.

[nppangband]

I think I will start by putting all the dungeon information into a class. I am too new to OOP to try anything like you just described. But I think if I make the class correctly, QT will update everything onscreen automatically as changes happen to the dungeon information. I might even be able to have all the game commands just be signals directly from the dungeon class. QT seems to support this.

We will see how it goes. I clearly have a lot to learn, but this is an interesting new challenge.

[Nick]

I think it's fascinating that we essentially have concurrent rewrites of Angband in C, C++ and Python.

[takkaria]

I think I will start by putting all the dungeon information into a class. I am too new to OOP to try anything like you just described. But I think if I make the class correctly, QT will update everything onscreen automatically as changes happen to the dungeon information. I might even be able to have all the game commands just be signals directly from the dungeon class. QT seems to support this.

We will see how it goes. I clearly have a lot to learn, but this is an interesting new challenge.

This is pretty much what modern V does, too. Except obviously, without using C++ classes; it's just object-oriented C.

[Magnate]

I think it's fascinating that we essentially have concurrent rewrites of Angband in C, C++ and Python.

It's not the word I would use, for those of us with limited time and ability to contribute and a fondness for optimisation of effort ;-)

[Derakon]

If you're new to OOP, then here's what I'd suggest:

1) Have a Dungeon (or whatever you want to call it) class that represents the entire dungeon state. Saving the game should be equivalent to recording all of the information this class holds; thus it tracks everything.

2) Have a 2D array of dungeon tiles inside the Dungeon class. Each tile should be an instance of the Tile class (or whatever). The Tile holds information on what is in it, e.g. Tile.monster, Tile.trap, Tile.itemList, etc.

3) Whenever an attribute of Tile is changed, set Tile.isDirty to True. This indicates that the Tile needs to be redrawn. Whenever you draw the Tile, you unset isDirty.

Using event passing to handle game commands is similar to what Pyrel does, though its system doesn't use an external library. Events are super-useful and actually pretty simple to implement (at least in Python; probably a bit trickier in C++). I suggest you read the events.py module for Pyrel if you're curious. With that module, I can do things like:

# Pay attention to requests for user data
events.subscribe("resolve user prompt", self.onPrompt) 
# Completed drawing the current game state (useful for animations)
events.publish("draw complete")

result = []
def callback(*args):
    result.append(args)
events.executeAndWaitFor("resolve user prompt", callback,
        YesNoPrompt("Are you sure you want to quit?"))
# The result of the prompt being resolved
return result[0]

[nppangband]

I think it's fascinating that we essentially have concurrent rewrites of Angband in C, C++ and Python.

Yes. Although it is badly needed on all fronts. I do wish we could combine our efforts, but we would also have to combine our vision as well.

Of course, after working with QT for several weeks I think it is fantastic, and just wish you gave it a chance, and you would see how great will be (which is no doubt exactly the same way the Pyrel devs feel about their approach, and how the Angband team thinks about their approach).

It is conceivable that at some point Pyrel and NPP could naturally meet up as there is QT for Python.

[Derakon]

It is conceivable that at some point Pyrel and NPP could naturally meet up as there is QT for Python.

Indeed, one of the front-ends for Pyrel uses Qt, albeit just for creating windows, drawing, and handling input (same things the other front-ends use their respective libraries for).

The entire purpose of Pyrel is to be a ground-up redesign of the entire engine. NNPQt and the Angband rewrite have less ambitious and more readily-achievable goals. Of course my eventual hope would be that every variant would be rewritten as a Pyrel mod.

[nppangband]

If you're new to OOP, then here's what I'd suggest:

1) Have a Dungeon (or whatever you want to call it) class that represents the entire dungeon state. Saving the game should be equivalent to recording all of the information this class holds; thus it tracks everything.

I haven't gotten that far yet. I am thinking of, for now, keeping the lists for the active monsters and objects, and using pointers from the dungeon class ot reference them, similar to how it is done now. Your approach is probably better, but I am concerned about my ability to pull it off. I am trying to avoid changing too many things at once. While I am working on the UI, I want to have confidence that the game itself is functioning properly.

2) Have a 2D array of dungeon tiles inside the Dungeon class. Each tile should be an instance of the Tile class (or whatever). The Tile holds information on what is in it, e.g. Tile.monster, Tile.trap, Tile.itemList, etc.

3) Whenever an attribute of Tile is changed, set Tile.isDirty to True. This indicates that the Tile needs to be redrawn. Whenever you draw the Tile, you unset isDirty.

I think QT actually takes care of all this. If I set up the QT widget (main screen) correctly, when I change the data for any part of the dungeon that is onscreen, it will automatically redraw that square.

Thanks for the help, though. Any bit of knowledge from an experienced OOP programmer is greatly valued.

[Nick]

It's not the word I would use, for those of us with limited time and ability to contribute and a fondness for optimisation of effort ;-)

Yes. Although it is badly needed on all fronts. I do wish we could combine our efforts, but we would also have to combine our vision as well.

Of course, after working with QT for several weeks I think it is fantastic, and just wish you gave it a chance, and you would see how great will be (which is no doubt exactly the same way the Pyrel devs feel about their approach, and how the Angband team thinks about their approach).

I actually really like the 3-way split. The V and NPP work is currently quite distince - NPP is interface focused, whereas V is more about the game core and commands. And having a complete rewrite like Pyrel is great for re-examining how we do everything.

My guess is that long-term V and NPP will come to something approximating the same codebase. Pyrel could actually become a genuine fork of Angband, which would be brilliant.

Exciting times

[nppangband]

After RL kept me away for a bit, the code for loading and saving files has been added, along with a vector to store on-screen messages.

Next up: Widgets (dialog boxes) for player birth and changing game options.

Still nothing resembling a playable game, but some decent progress this week.

[nppangband]

Diego and I are making good progress on the QT port of NPP. We reached a major milestone today. The game can make it through the character startup, and the dungeon can be displayed on-screen. This means the dungeon can be generated, that objects and monsters can be generated and placed in the dungeon, the store inventory is being processed, a savefile can be saved and loaded, and a character created. We are close to adding game commands so that a game turn can actually be processed (it is going to be event-driven, rather than having the central loop inside the game in dungeon.c like it is now). I think probably 80% of the core code has been added at this point, and we will be able to turn our full attention to the front end. Here are some screenshots. We will add a "style" to all the dialog boxes so the game has a good fantasy/middle earth feel to it.



This is a birth screen for NPPMoria. The dialog box works with the edit files to create the radio buttons. So a NPPAngband birth screen would also have the dunaden and high-elf races, and brigand and druid classes as well.

[Malak Darkhunter]

Man you guys work fast!

[nppangband]

While this is just a plain ASCII town, any system font and font size can be used. The game can use any Unicode font, and 24-bit colors.