NPPAngband/NPPMoria QT port

[nppangband]

More progress. 8x8 and 32x32 tileset now works, with hopes to eventually add Shockbolt's tiles someday.

We are getting closer to the playable game now. We still need to add all the commands, and dialog boxes for things like the store interface and item selecting from inventory.

BTW: to Buzzkill - the tile mapping is now kept in the edit files with the rest of the monster/object/flavor/terrain information, instead of the pref files, and we got rid of the hex +128 numbering system. So instead of:

T:0x81:0x81

it now reads:

T:1:1

Please let me know if any future updates to tile mapping.

We are also using only the .png files now, with no masks, and we are dumping the 16x16 tileset. And we aren't using the offset terrain tiles any more. When a tile has to be brightened or dimmed based on line-of-sight or torchlight, the game just alters the tile slightly. We also have lots of new effects like adjusting the tile for invisible creatures so they are transparent, and you can see through them to the floor or wall.

I say "we", but Diego did the graphics. I got the game processing game turns (process world, process player, process monsters, etc). The monsters now move and attack, and the player can move around and melee. Only the player doesn't die when he goes < 0 hp, because I haven't added the player death code yet.

[Derakon]

Having a proper event-driven system makes GUI programs of all kinds a lot more straightforward to write. Doing everything procedurally is a massive pain. And it's not like events are hard to implement either; they just weren't really well-known when Angband was written.

[nppangband]

This looks pretty awesome -- much more ambitious than my T2 Qt port! (Which is basically just a way to display Terminals in windows. Only lacking multi-term/window support before it can be merged to master. $DEITY knows when I'll actually have time to work on it, but...)

The part that is going to be interesting is having everything event-driven. QT does a lot of stuff automatically. For example, change the font, and QT re-draws the screen without being asked to do so. I am pretty sure that when the player takes damage, the hp counter onscreen will automatically change.

[nppangband]

Here is the options dialog box. Again, we will give the game a good middle-earth "style" for the dialog boxes.

I we are getting closer to adding commands and processing game turns. That is the next big milestone.

[AnonymousHero]

This looks pretty awesome -- much more ambitious than my T2 Qt port! (Which is basically just a way to display Terminals in windows. Only lacking multi-term/window support before it can be merged to master. $DEITY knows when I'll actually have time to work on it, but...)

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

[Malak Darkhunter]

Man you guys work fast!

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

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

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

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.

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

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]

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]

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