Angband Code Interface to GUI

[meeshoo]

Just a thought:
Screw models. 3D letters are:
1. Possible to do*
2. Look nicer anyways =D

* Imagine a hobbit @. Imagine a AMHD. Imagine both of them being the same size. Feels odd. With letters, there won't be that problem.

That is also my idea for the first version, however, there won't be 3d letters, there will be cubes with the letters on the textures on all sides. Then slowly I will add 3d models, but the idea is that there will be the option to play as the first version, like some kind of model packs, that is not a problem. So yes, for first it will be a 3d version with letters, but that will benefit from mouse interraction, so you don't have to hit about 3 or 4 keys to cast a spell, you will be able to play it only with your mouse basically.

I also applaud your enthusiasm and efforts here.

However, although the interface you show above looks nice, it has a few obvious drawbacks compared to top-down view:

1. Would need a cut-away walls option.
2. On-screen area is too small to make telepathy (and to a lesser extent detection) meaningful.
3. The current top-down view abstacts some things that might be difficult to deal with in a 3D view. Like: floorstacking of objects/gold and the fact that a square can contain gold, objects (or a trap) and a monster. What would a 'busy' square like this look like in a 3D view?
4. A diagonal 3D view like this could change the aspect when considering movement. Which way is UP?
5. Hight of objects / view blocking. If there is a Hill Giant standing in front of this character, will I be able to see the character, or the small mushroom on the floor behind him?
6. Distance scaling. If the viewable play area is made bigger, do distant square become smaller? Top-down view shows everything as the same size, which makes detection and telepathy workable. Also, some players (like me) have the player always centre-in-the-screen. Others prefer the area view. I'm not sure how a 3D view would work with both of these options.

I'm not trying to throw a spanner in the works, I'm just trying to imagine what a view like this might look like in certain real-game circumstances.

Neil.

Well, I do not know which 3d RPGs you played so I can give you examples from there, but I will explain the best I can at your questions:

1. That is not a problem at all, there are a lot of games which make the walls transparent so you can see what's around your character. Even Darkstone here did it in some view angles, even diablo in it's 2d environment did it. Also you can rotate the camera in an orbiting fashion around your character to see everything. The image i posted there is just a screenshot from another game to give you an idea.

2. If you read the list I wrote in my previous comments, you would see that there will be a "full zoom out" option that will allow you to see everything from above just like you see it in the text view. If you want to play it all from that view there is no problem, but people don't use map all the time from my experience. So the map will be there and you can use it as your play view (still 3d top-down) but the actual default view will be the close 3rd person one. I think the immersion you get when viewing the scene from your character's point of view will add value to the already great atmosphere of the game.

3. Well, a stack of objects could be a general 3d model, you have to investigate to see what it contains. The monster can sit right on top of that and well, traps can just look with a different texture or so. There is no problem representing all that, and again, you can play from top down view as I said on point 2.

4. We could use a kind of compass for that in the top-left corner that will tell us which way is north, south and so on. Actually this is a very good idea, I will note it down.

5. You can play from top view or as I said, you can move the camera to see every little corner around you, so yes, you can see all details like the mushroom and so on. It is not a diagonal, that's just an example (again read my first detailed list on the principles.

6. Well, lots of games responded to this already. Of course the perspective view will work as in real world, things further away will get smaller, but again, you can get into the orthographic top-down view for things that require an overview on the map (again ready my first list). About the camera movement, you can have it follow your character (diablo or world of warcraft style) or you can just have it independent of your character (again, ready my first list of principles).

More to say here is that this is just an addon that I will make and maintain, it's up for you to use it.

Best way to see how this will look is to get into games like for example Heroes of Might & Magic V. Even if it is not a dungeon crawler, you can see how 3d views works there. You can zoom in to see the details on the face of the character or zoom out to see a top down view of the map. Or you can play 3d RPGs like world of warcraft (although the map there is not a 3d top-down view). Or take a peek at the movies about the upcoming diablo 3, which follows a now classic dungeon crawler but in a 3d environment. Another good idea to look is Civilization 4, which was basically a map game at origins, but now from the top down view you can zoom in to see the buildings in your cities. There are hundreds of examples.

I think all it will be more clear when I will actually do something that I can show, so I will get to work. This won't be easy at first so don't expect something very fast, I still need to figure out a lot of things about the Angband existing code, however all my updates will be shown here.

Again, if you have any suggestions just go ahead and post them, I promise I'll read them all.

Thanks for the feedback so far.

[tigpup]

Sure, I understand that many of these things *can* be implemented. My point was more that such an implementation could have an impact on gameplay. Changing the UI should not (IMHO) affect the balance of the game in any way. If a new UI means I am more (or less) likely to see (or detect) a {special} longsword lying on the ground (perhaps in a pile of other objects or under a monster), then that UI is changing the balance of the game.

For me; detection, ESP and enlightenment would mean I probably always want a top-down, unscaled, flat view.

Looking forward to seeing what you come up with.

Neil.

[meeshoo]

Well, the UI cannot change the balance on the game, as it will show only what your character would "see" in the normal top-down view, because it will be based on the same thing, it is the same data. If you haven't yet discovered something that is near you, the UI will show nothing.

Anyway from your messages I see that you won't benefit that much from the UI and still prefer the existing UI on the game, it is your choice. For my generation (the ones who started playing games with fancy graphics from start) and for the next generation of gamers who mostly don't know anything about such great games as text based dungeon crawlers I assure you it will help a lot. For me the most annoying thing is not the actual look of the game, but the input methods. Having to remember that many key shortcuts and even more, having to press multiple of them just to do a simple action like cast a spell is a pain, and will slow down the game a lot, making most of the new ppl to just abandon it, and that is not what the game deserves.

[Turambar]

Well, seeing Angband in fancy 3D graphics is something that came to me as well. The problem is the nature of the game. There is already enough stupidity in even the most experienced player that can end up as YASD. It would be nice to see your powerful Dunadan warrior in 3D hewing through a group of cave orcs or some end game unique. But as it was already mentioned several times before, there are too many aspects of the game that require *large* part of the map to be displayed. Some require smaller parts or just immediate surroundings of @ but more importantly, you need plain, as *non* confusing image as you can get.

I think that players would at first eagerly use zooming and watch their hero's best moments but as the excitement decreases, they would more and more remain in the "zoomed out" state. Every single turn can kill you and it would be too much of a nuisance to zoom in, zoom out, rotate etc. every turn. Therefore I think that most players would end up with static, all the time all the same screen, which is definitely most effective and safe. Overlooking something maybe too painful, as we all know too well. Not to mention confusing one monster with another due to distance, angle...

I don't say it wouldn't be nice to actually see that working but it seems to me that for most it would be just short-lived candy with not much use sooner or later. On the other hand, it might work quite well for attracting newbs.

Devising new input methods seems much more interesting to me.

[Big Al]

A couple years ago, I decided to make a 3D version of Angband, mostly as a project to teach myself real-time 3D rendering (and like most of my projects, never amounted to anything). So, I've been thinking about this for a while.

I decided that easily zooming in and out is critical - the player needs to be able to see all dangerous monsters easily. I was going to add some kind of "offscreen-foe" indicator: like in Baldur's gate (IIRC), if an enemy is offscreen, a red arrow shows up on the edge of the screen pointing at him offscreen. Maybe make a little arrow with the letter of the monster on it at the edge of the screen, to warn the player that it's there.

Good luck!

[meeshoo]

Thanks for the inputs.

[meeshoo]

Just a quick update: I took some time to learn how to work with Ogre and the CEGUI interface and hopefully next week I will present a rough interface launched from within Angband that will display some in-game information (or it will just be launched :P, no idea what I should expect there ).

Regarding the "Maintain or Develop" article, I would be happy to help laying out some design ideas about the point regarding separating more the game from it's interface, because it will allow me to learn more about how it works and will have a direct impact on what I am currently doing here.

Stay tuned

[tigen]

I've considered the feasibility of Angband graphics too. Most of the 2D tile-based graphics aren't too appealing to me, because the tiles are low resolution and "noisy". The hybrid approach of colored ascii with some basic clean wall/floor graphics works pretty well though, and probably would help with conveying different terrains.

Ascii characters are inherently easy to recognize; they are pure glyphs. Even in many top commercial games, the 3D models can be tough to distinguish (e.g. RTS games). In an FPS it's ok because there's less information to process and you are looking at stuff up close. In Angband, you really won't zoom in except just for fun; the gameplay requires seeing a decent portion of the map.

The games with "realistic" graphics aren't based on a coarse uniform grid like Angband. And they don't randomize the maps the way Angband does... at best they string together various premade rooms like Diablo. So I wonder if a more abstract approach to the graphics would be better, and easier to implement and maintain.

Apart from the graphics, it would be nice to design an intuitive mouse-based GUI for interacting with the game. I think this is the biggest obstacle to new players. Even if you just rendered ascii graphics in a window but added real GUI stuff for the inventory, spellbooks, information popups, browsing the monster recall etc., that would be a big improvement.


I think a ground-up 3D roguelike could be pretty cool... I mean, it's going to be hard to compete with Diablo III, but at least features like variable-sized monsters would be cool. In theory you can do variable sized ascii monsters but that would be kind of crazy.

[Orillian]

Once you go 3D item labeling becomes paramount. I've played a number of games that fit the 3d RPG/Roguelike genre and when your in a game with a LOT of item drops that the player NEEDS to be able to see they generally fall back to showing text labels that float above the item as it sits on the ground. Not so realistic but it allows the player to keep an eye on all the cool loot thats falling from their dead enemies. Examples of games that do this Diablo Series, Titans Quest, Dungeon Siege Series, Fate.

Now regarding the zoomed in view and the fact that some are concerned about the constant need to SEE the game map. Well that was taken care of in Diablo by having the game map show above the gameplay at all times, they would allow you to adjust the transparency of the minimap, some also the location of the minimap etc. Important things that the player needs to be aware of also show on the minimap. If a feature like this was implemented, a simple basic re-rendering of the existing map without all the fancy graphics was overlayed at a player specific transparency above the main view it would allow.

A) the player to see all the eye candy.
B) the player to still track the results of Detect Evil, or DT etc.
c) the player control with a simple toggle, to turn that feature on or off.

Regarding a starting placeholder model set. Having color mapped 3D lettering would be VERY cool. there was an old Raytraced render made many years ago that had that look to it and when I think 3D Angband that image comes to mind, the last time I saw it was 10-15 years ago, but I remember it showing up way back in the ol BBS days. Sigh! Those were the days. I think for the sake of all the oldtimers around the ang community a set like that would get a few hardcore asci people to at least give a 3D GUI a try. If you want to stick to your cubes thats ok though. If you get this project to a point were implementation of a full 3d model set is required, I'm sure someone will do the 3d lettering. :P

Quick Edit: I found a link to the pick here on the site actually! :P



O.

[meeshoo]

Well, sticking to the cubes is necessary to obtain a first version of the game that meets all objectives with minimum artist involvement: 3d and playable using only the mouse device. If that gets done (and it's not an easy task) then getting models instead of cubes is not that hard really. Anyway, first thing first, I haven't even rigged properly ogre and angband together, they just compile together but do not call each others functions yet

EDIT: that image looks nice, however, having different scales for monsters is pretty hard giving the fact that they still occupy one tile of terrain. If you would have the player character and the monster sitting next to each other it would be pretty nasty. However it might be obtainable by intelligent design of the 3d models, so the base is still one tile but the rest can spread over the tiles nearby.

[meeshoo]

Ok, somone who is more familiar with the angband code please let me know if what I understood until now about it's inner workings (UI related):

0. the main game loop is called from the platform specific "main" file which puts the "logical" terminal data on the screen in a platform specific way.

1. there is dungeon.c in which the main game loop happens, where the dungeons are called for generation and so on.

2. in the main game loop, giving some player flags, specific events are triggered.

3. These events are handled by certain event handlers that are added at the start of the application

4. These event handlers update parts of the visual data which then gets redrawn on the screen.

Is this correct?

Because if this is right, then there are two options for building the 3d interface:

1. each time a change happens, the change gets propagated into the 3d application where a ghost of all game related information exists and that ghost is updated accordingly (giving the fact that it will be rendered real time). That means that the 3d interface has a state that is altered by angband events, which are triggered by player actions sent from the interface.

2. we keep in the 3d interface is stateless, displaying only what the player can see (what the player would be able to see in the current top down view), and on each action taken by the player the 3d interface will query the angband application for new data to display.

Which one do you think would be the best?

[takkaria]

Ok, somone who is more familiar with the angband code please let me know if what I understood until now about it's inner workings (UI related):

0. the main game loop is called from the platform specific "main" file which puts the "logical" terminal data on the screen in a platform specific way.

1. there is dungeon.c in which the main game loop happens, where the dungeons are called for generation and so on.

2. in the main game loop, giving some player flags, specific events are triggered.

3. These events are handled by certain event handlers that are added at the start of the application

4. These event handlers update parts of the visual data which then gets redrawn on the screen.

Is this correct?

Pretty much, yeah, though the event handler system is pretty new and isn't used e.g. inside stores, or at death, yet.

Because if this is right, then there are two options for building the 3d interface:

1. each time a change happens, the change gets propagated into the 3d application where a ghost of all game related information exists and that ghost is updated accordingly (giving the fact that it will be rendered real time). That means that the 3d interface has a state that is altered by angband events, which are triggered by player actions sent from the interface.

2. we keep in the 3d interface is stateless, displaying only what the player can see (what the player would be able to see in the current top down view), and on each action taken by the player the 3d interface will query the angband application for new data to display.

If you keep it stateless, I can't help but think you'll end up with redraw problems, so I'd go for (1).

[meeshoo]

If you keep it stateless, I can't help but think you'll end up with redraw problems, so I'd go for (1).

Yeah, I guess that's what I was thinking too. I better keep all the game data flow unidirectional, from the game to the interface, and all the control flow going from interface to game, this way everything it's pretty clear how it should work. The 3d interface should have knowledge of everything but will show to the user only what the user would be able to see in the standard top-down view.

Btw, I managed to open the ogre 3d window from within angband WinMain function. The only small problem is that I should put in on a separate thread so it does not interfere with the rest of the application (it is blocking it for now). After this I will focus more on which data should be passed from game to UI and which will be the best way to do it (any suggestions here are welcome ofc).

[Pete Mack]

The current model is pretty good for the communication to the GFX--it's just a short queue. Making it non-blocking, unless it is full, shouldn't be too hard. And a queue is certainly the right model for such things anyway... The only issue is whether you want to encode more complex tokens in the queue. Currently there's only a channel for glyphs, and for color.

[meeshoo]

Well, looks like I just found myself in front of an impenetrable wall . Making the application a multithreading one and synchronizing threads is a huge pain, and it's quite impossible to make because multithreading is quite platform specific. The problem here is that the main loop of the game is not done in the main function of each platform but rather in the play_game() within dungeon.c. That cuts access to anything after the "while(TRUE)" section is entered, basically reducing all communication to input and some events to update the output screen buffer.

Here is the solution I thought of (as a first step):

The play_game() function is formed of 3 main parts: the initialization part, where the user starts the game and so on, the main loop part for playing the game and the last part (smaller) containing the cleanup code.

The solution would be to split the play_game into 3 different methods:

init() - do the initialization stuff
play_game_round() - one iteration, basically the code from the while(TRUE) loop
destroy() - do the cleanup stuff.

Then, from all platform-specific main functions we replace

play_game();

with

init()
while(some_flag == TRUE)
{
    some_flag = play_game_round();
    //other stuff
}
destroy()

Now into the "//other stuff" section we could do whatever we need. In my case, here would be what i would have:

init()
while(some_flag == TRUE)
{
    //pseudo-code
    input = get_input_from_3rd_party_interface();
    send_input_to_game(input);
    some_flag = play_game_round();
    send_output_to_3rd_party_interface();
    render_3rd_party_interface_frame();
}
destroy()

The need for such kind of code arises from the real time nature of 3d rendering versus the turn-based nature of the game. However, such modifications would help separate the game layer from the interface layer even more.

What do you think about such a change, would it be difficult to implement (in terms of dungeon.c)?

If you want, I can make the change and send the changed files to you for review and commit, if you don't have time for it. It should be like a patch and it shouldn't change the current functionality at all, but break the "shell" of the game for adding more.