Angband Code Interface to GUI

[meeshoo]

Hello,

I am new to roguelike games, started out with nethack and now I found out that there are many such games. I stopped on Angband because I am a fan of Tolkien universe and Angband sticks more to the fantasy line than others (you don't have photo cameras for example ).

On the other side, I am also a software developer, and I am working on game projects as a hobby at home (haven't finished any but I still like to work on various things every now and then).

What I've been trying to do with nethack is a new GUI for the game (maybe a 3D one). What I found out (although there are some custom user interfaces) is that you cannot actually impelemnt a new GUI without actually altering several parts of the game code. That is, there is no coding interface that will completely separate the gamecode from it's user interface, meaning that you have to do merging of your changes into every new game version, being impossilbe to maintain the GUI in a relatively independent fashion.

My question is: does Angband have such a thing? A separation between the game and it's world as a data in memory and it's representation on the screen? And if the answer is no, are there any chances to have such a thing in the near future, or will a patch made by myself do such a thing?

I was also thinking at some point to try to design a universal interface for roguelike games that will allow any interface to remotly start the game and query it's state, then represent it on the screen in any fashion it wants.

What do you think?

Thanks

[takkaria]

What I've been trying to do with nethack is a new GUI for the game (maybe a 3D one). What I found out (although there are some custom user interfaces) is that you cannot actually implement a new GUI without actually altering several parts of the game code. That is, there is no coding interface that will completely separate the gamecode from it's user interface, meaning that you have to do merging of your changes into every new game version, being impossilbe to maintain the GUI in a relatively independent fashion.

My question is: does Angband have such a thing? A separation between the game and it's world as a data in memory and it's representation on the screen? And if the answer is no, are there any chances to have such a thing in the near future, or will a patch made by myself do such a thing?

Angband is starting to get an abstraction layer between the game and the UI but it's not in any way complete yet. I don't think it would go as far as you'd like either; UI will still be accessing the game's memory when it's complete, it's just the game won't assume a 80x24 terminal.

I was also thinking at some point to try to design a universal interface for roguelike games that will allow any interface to remotly start the game and query it's state, then represent it on the screen in any fashion it wants.

What do you think?

I think it is highly unlikely you'll ever get something universal across all roguelikes; even across all angband variants would be a struggle. Each game has its own quirks and own UI needs; no one size would fit all.

[Zikke]

Sounds like a sort of skin development for Angband, which is something I have thought would be kinda neat. Not sure what goes into it though.

[meeshoo]

I think it is highly unlikely you'll ever get something universal across all roguelikes; even across all angband variants would be a struggle. Each game has its own quirks and own UI needs; no one size would fit all.

I think you are right, I should maybe stick with Angband for now.

Sounds like a sort of skin development for Angband, which is something I have thought would be kinda neat. Not sure what goes into it though.

Not really. Here is how I imagine it:

- Angband (called the game from now on) should be able to run into 2 separate modes: as it is doing now, or in "server" mode.
- server mode means there is a layer of code (probably a dll) that implements a certain standard interface (which remain to be specified), just like a contract. This means that another application (the GUI application) can load the game remotely through this interface and knows which functions will find there to call, basically anyone who would develop a new GUI application knows what methods to find and how to use them by reading a document and he knows how his GUI application can remotely interract with the game.

An example of this kind of communication will be like the following:

1. GUI asks the game to start - the game starts in background
2. GUI asks the game for a list of races available to chose and their properties, and it displays them in a fancy way. Player choses some options and then the GUI sends those settings back to the game and further on requests more details on the classes available.
3. Let's imagine the GUI is 3D and the player clicks on a tile where he wants he's hero to move. With fancy animations the hero moves there by walking or running. What happens under the good, the GUI application sends a message to the Angband game with the new command to move to the specified position, the Angband game executes the command and then sends back a message to GUI with the new details of the discovered area and the GUI displays them on screen, like monsters, doors, walls, etc.

Angband (and most roguelikes as they are now) have an inner state that represents the game data, like the map, the position of the player, the mobs, etc, and then they have the visual representation of it that, speaking in terms of coding, are bound together, there is no independence between the data and it's representation on the screen, therefore, if you want to change the GUI you have to mess with the core code, and if another version comes out you have to adapt your patch to the new code.

My idea is to split the game mechanics code from the UI code, put a layer containing a contract (a standardized mode of communication between GUI and game mechanics code), keep the current UI as the default one but it should use the new layer too and also allow very easly for people to implement their own UI without even touching the game mechanics code, but rather interact with it through the contract interface that is used by the default GUI too. This is more platform independent than it already is and will allow people to implement new GUIs as standalone applications, using modern graphic engines and such.

Basically it's just placing a standard communication layer between the GUI and the code that holds the internal workings of the game.

I downloaded the code only today, so I guess I'll just start and dig through it and see how I would be able to pull this off somehow, maybe the idea has a future.

[takkaria]

I think you are right, I should maybe stick with Angband for now.



Not really. Here is how I imagine it:

- Angband (called the game from now on) should be able to run into 2 separate modes: as it is doing now, or in "server" mode.
- server mode means there is a layer of code (probably a dll) that implements a certain standard interface (which remain to be specified), just like a contract. This means that another application (the GUI application) can load the game remotely through this interface and knows which functions will find there to call, basically anyone who would develop a new GUI application knows what methods to find and how to use them by reading a document and he knows how his GUI application can remotely interract with the game.

An example of this kind of communication will be like the following:

1. GUI asks the game to start - the game starts in background
2. GUI asks the game for a list of races available to chose and their properties, and it displays them in a fancy way. Player choses some options and then the GUI sends those settings back to the game and further on requests more details on the classes available.
3. Let's imagine the GUI is 3D and the player clicks on a tile where he wants he's hero to move. With fancy animations the hero moves there by walking or running. What happens under the good, the GUI application sends a message to the Angband game with the new command to move to the specified position, the Angband game executes the command and then sends back a message to GUI with the new details of the discovered area and the GUI displays them on screen, like monsters, doors, walls, etc.

Angband (and most roguelikes as they are now) have an inner state that represents the game data, like the map, the position of the player, the mobs, etc, and then they have the visual representation of it that, speaking in terms of coding, are bound together, there is no independence between the data and it's representation on the screen, therefore, if you want to change the GUI you have to mess with the core code, and if another version comes out you have to adapt your patch to the new code.

My idea is to split the game mechanics code from the UI code, put a layer containing a contract (a standardized mode of communication between GUI and game mechanics code), keep the current UI as the default one but it should use the new layer too and also allow very easly for people to implement their own UI without even touching the game mechanics code, but rather interact with it through the contract interface that is used by the default GUI too.

If your goal is to allow people to write a new GUI without touching the game code, then I'd question how possible your goal actually is.

The problem with the contract is that it will either be too specific or not specific enough to make a really good UI. If it is too specific, then when the game changes from version to version, the contract will have to be updated. If it is made more generalised to cope with this, then you won't be able to do the special-case things that really make UIs usable.

You will also always have some issues where the abstraction leaks, such as when the game says "monster x is here", how does the GUI decide how to display it? Does it read the same data files as the main game? Does it keep a mapping of monster -> tile for each monster, and likewise for other objects? If you use graphics for things like status indicators, you will have to update those every version when statuses change. etc.

Furthermore, why is factoring it out into an external library a desirable trait? If you want to implement a new UI, you can save a lot of work by just changing the code in the ways required for that UI, rather than putting in extra work for no extra gain. To get Angband to the point where it was usable as a library would take years of part-time work. In other words: if you want to write a new UI for the game, then you're better off writing the new UI on the existing code. I guarantee you will give up on the project if you try to refactor Angband to make it work as you want to before you write a UI.

If you don't want to write a UI, just want to make it easier for other people to... I appreciate your efforts, but I think that without actually implementing a new UI alongside the old one, you will not be able to work out exactly what the requirements of new interfaces would be. New interfaces by their nature are new—if they are to be novel or interesting in any way then they will require things that old interfaces didn't. Predicting the future is hard, so I advise you not to do it. As new interfaces came up, you'd have to modify the game code anyway to expose new information, or expose old information in new ways.

I'm certainly in favour of Angband gaining a bit more abstraction between the UI and the game, but not to the extent of making the game an external library, basically. I hope I haven't been dismissive here, but having worked on the game code for some years now I still despair of it in places. I'd like to think I have a fairly good idea of what's achievable, and I've watched many people try (and fail) large-scale refactorings or rewrites before, including my own.

This is more platform independent than it already is and will allow people to implement new GUIs as standalone applications, using modern graphic engines and such.

I'm not convinced it's possible to make Angband more platform-independent than it already is, given that it's written a standard dialect of C that runs across pretty much every OS currently used, and a couple that aren't.

[Donald Jonker]

I'd like to preface by saying that I don't know sh** about di**, but this all sounds kinda like ZangbandTk. So maybe that'll be helpful.

[Nick]

I'd like to preface by saying that I don't know sh** about di**

I think everyone should take that as read about everything I post - that way there's the occasional pleasant surprise.

On the actual topic - I agree with takkaria 100%.

[Daniel Fishman]

I think everyone should take that as read about everything I post - that way there's the occasional pleasant surprise.

Probably a good assumption to make about everyone everywhere - particularly on the Internet - unless experience proves otherwise.

So on that basis, I agree with takkaria, who experience shows does know what he is talking about

[meeshoo]

Ok then. Well, writing the new UI instead of the old one sounds good, however, the main problem would be I cannot use a commercial closed-source engine to write the 3D interface, as I was planning to. I own a C4 license (a nice 3d engine made by terathon software) which certainly allows ppl to distribute free games made with the engine (which I intended for this interface) but totally forbids C4 code distribution (which is understandable). If I would have been able to separate the GUI from the game I would have been able to use the C4 engine, but now that I know this is not a plausible idea to put in practice, I have to think of other possibilities. Another option would be to use the Ogre 3D engine which is free and open-source, but the C4 really looks better and moves faster, and also it is more easy to work with.

My only regret about roguelike games is that I haven't discovered them earlier, I think they are the most complex RPGs possible to make. However, the learning curve to control the character within the environment was and still is pretty steep, and I think a really modern interface which uses mostly mouse interaction will make these kind of games much more popular and appealing to the new gamer generations.

I'm not convinced it's possible to make Angband more platform-independent than it already is, given that it's written a standard dialect of C that runs across pretty much every OS currently used, and a couple that aren't.

I think I didn't expressed what I wanted here (i'm not native english speaker ). What I wanted to say is that by having the game independent of the GUI, platform dependent GUIs could have been developed that take full advantage of the platform they are developed for, all this while keeping the gamecode untouched and platform independent.

[Pete Mack]

I think your idea is in principle a good one, especially for people who like graphics. The trouble I have is that introducing graphics tends to reduce the amount of information available, by making pictures that are hard to distinguish, or cutting down the amount of map in view. (Yes, 16color text also reduces this, but some variants allow more.)

[meeshoo]

Takkaria, following your idea to go directly for the UI code and giving the fact that I am completely new to Angband source, do you recommend I should go over all the code and try to understand it or I should focus from start on specific parts, and if it's the last option which parts should those be?

Thanks

[takkaria]

Takkaria, following your idea to go directly for the UI code and giving the fact that I am completely new to Angband source, do you recommend I should go over all the code and try to understand it or I should focus from start on specific parts, and if it's the last option which parts should those be?

Well, I'd say you should probably get familiar with how the existing UIs work (main-xxx) and go from there.

[meeshoo]

Ok, thanks, I'll keep you up to date with my progress then. My first goal is to understand how the current UI works and the second goal after the first one is accomplished will be to try and design a new interface at a conceptual level.

[meeshoo]

Now since I am a noob regarding the use of free build environments and compilers (I mostly did all my work on VStudio) I will put a noob question here:

If i have built angband using cygwin's gcc compiler as C sources, and I have build ogre using MinGW + MinGW C++ Toolbox (as the ogre 3d engine is written in C++), is there any way in which I can load and use the ogre engine's dll in angband?

Or in a more general way, is there any way to use a C++ dll built with g++ compiler within mingw environment in a C exe built with gcc coimpiler within cygwin environment?

Thanks

[takkaria]

Now since I am a noob regarding the use of free build environments and compilers (I mostly did all my work on VStudio) I will put a noob question here:

If i have built angband using cygwin's gcc compiler as C sources, and I have build ogre using MinGW + MinGW C++ Toolbox (as the ogre 3d engine is written in C++), is there any way in which I can load and use the ogre engine's dll in angband?

Or in a more general way, is there any way to use a C++ dll built with g++ compiler within mingw environment in a C exe built with gcc coimpiler within cygwin environment?

I'm afraid I have no idea about the above question.