Experimental webserver

[Pete Mack]

1920x1280, but that's deceptive: physically, it's pretty small, and vertical real estate is actually pretty limited. (it's like most tablets.)

[Gwarl]

So get this: the terminal emulator I was using is maintained by people from Microsoft because they use it in visual studio code. But I've been experimenting with the no longer maintained project it was forked from, and that one doesn't have any weird scrolling issues and recognises the proper escape codes for numpad keys. Even when they're working on stuff under MIT license they can't avoid adding weird bugs.

So I'm pulling out a lot of wires but when things are back up they should be much improved.

[Gwarl]

Okay, it's back up. No chatroom yet but the weird scrolling issues should be fixed or at least reduced. Shiftrunning is now possible, but you need to 'load pref file' runlock.prf from the options menu. Numlock toggles autorun and with autorun off you can still shiftrun.

I'd appreciate bug reports because as far as I know everything should be working just fine.

[Gwarl]

Haven't had much time to work on this last few days, but I just updated the Angband nightly build - I've taken 4.0.5 off the menu, the dev version will simply be 'Angband' until 4.1 hits the streets.

t4nk - I will try and get essential features (chat, accessible file dumps, .prf uploads, and recording while I'm at it) done over this weekend so I can be ready to start collaborating on a new UI come the 4th, but I can't make any promises. Anything you might want to know in the meantime, please ask.

Edit: hold on, latest build isn't working..

I think the addition of the 'cursed' object broke the limits on the number of objects (557 whereas 556 is max). I've removed hard biscuits from the game so it runs, but I think a better solution would be removing Grond/Massive Iron Crown since they're generated from artifact.txt now rather than object.txt (I think?)

Double edit: that didn't work, oh dear. Service will be interrupted.

Triple edit: I solved the problem and it had nothing to do with the lastest build, but hard biscuits are still temporarily absent

[t4nk]

t4nk - I will try and get essential features (chat, accessible file dumps, .prf uploads, and recording while I'm at it) done over this weekend so I can be ready to start collaborating on a new UI come the 4th, but I can't make any promises. Anything you might want to know in the meantime, please ask.

It's all for fun, so just do it whenever it seems fun to you
We should probably discuss the protocol. JSON seems to be the natural choice. One thing to note is that in graphics mode each grid has foreground (e.g., a monster tile) and background (floor tile) and I think there was some desire for even more tiles per grid (well, that depends on whether you want to support graphics...). Any ideas? On the C side, any kind of output is fine, so it's basically should be what is more convenient to you.

[Gwarl]

It's all for fun, so just do it whenever it seems fun to you
We should probably discuss the protocol. JSON seems to be the natural choice. One thing to note is that in graphics mode each grid has foreground (e.g., a monster tile) and background (floor tile) and I think there was some desire for even more tiles per grid (well, that depends on whether you want to support graphics...). Any ideas? On the C side, any kind of output is fine, so it's basically should be what is more convenient to you.

Well, I'd like to use as much as possible of what I already wrote, which was designed explicitly to support graphics - including wall decals and monster equipment, which angband doesn't have. The whole thing is built inside an HTML canvas, I'd be using pictures of text characters at first to bridge the gap, and then include angband's tilesets.

It parses out mouse clicks and keypresses into a "verb/qualifier" form, i.e. move north, get 2 (pickup 2nd item on the floor), use 4, drop 3 etc, but in this case it might make more sense to turn mouseclicks into keypress equivalents and leave keypresses as keypresses. It would also accept things like "moveto (x,y)" which angband does allow for mouse clicks but there's no keypress equivalent to transmit the instruction as. (Edit: on second thoughts, things like 'show me my inventory' 'show me my equipment' 'display monster recall' should probably all be done clientside without disturbing the backend process, so maybe a 1-1 correspondence of keystrokes to commands wouldn't be the best idea)

In return, it asks the backend for a JSON string including player stats/inventory/equipment a list of all visible monsters, a string of digits respresenting wall/floor/unknown/staircase (I didn't even get round to having doors), and more JSON listing the animations to perform once the data had been received before updating the screen - but again, angband wouldn't support this. I had to go through all the relevant functions and add lines of code to record the directions of movement and such for everything I wanted to animate. Projectile animations (bolts/arrows etc) should be doable though I'd think?

The biggest thing it lacks that angband would require is popup menus.

I'm rather excited. I'm sure I can put together something better than DCSS webtiles. We can package it into a standalone executable for offline play too. (Or a standalone executable for online play! Or, best of all, a standalone executable for offline play which opens a socket and streams outputs for public consumption)

[Nick]

I'm rather excited. I'm sure I can put together something better than DCSS webtiles. We can package it into a standalone executable for offline play too. (Or a standalone executable for online play! Or, best of all, a standalone executable for offline play which opens a socket and streams outputs for public consumption)

I'm glad you're thinking along these lines. One of the issues with the webserver as is is that, as screens have got bigger, most *band players have adjusted to using their whole screen with a big area of dungeon and lots of subwindows. Being able to combine that with server play would be amazing. I know regrettably little about how Mangband and PWMangband severs work, but having a look at those might be helpful.

[t4nk]

So, this is how ui works in angbands (mostly using vanilla as an example):

At the beginning, there was one "term". It's still there, that's where the main map is drawn. It's a terminal emulator kind of thing; its purpose is to prepare text (and only text; graphics are a hack added later) that a frontend (stuff like main-gcu.c, main-x11.c, etc) can display. Internally, it is two arrays of wchar_t and two arrays of ints.
One array of wchar_t is the characters to display, and one corresponding ("parallel") array of ints is their colors.
Later, people added graphics; when graphics are enabled, the array of wchar_t is the y (row) coordinates of the tile (on the tileset) + 128 (that is, if the y coordinate is, say, 2 - the term will recieve wchar_t 130). The array of ints is the x coordinates, encoded similarly (also with 128 added). That is for foreground tile.
The other two arrays of wchar_t and int are used for background tiles (floor), in the similar manner, and only with graphics (in text mode background is always black).
Note that displaying graphics is problematic, because the main, original term still has to display text; for example, sidebar, or messages line, or various popup menus (inventory, spells, etc). So Angband uses a hack; graphics are stretched or shrinked to fit some multiple of font size.

Later, people added several more terms that can display inventory, equipment, monster list and other things. Some frontends create additional windows when those terms are used, others (gcu and sdl) display those in main window.

What all that means (among other things) is that a frontend has no idea what it is actually displaying; it just draws some text or graphics somewhere on the screen. In particular, the frontend can't tell whether it's displaying a monster list or whatever.

Well, I'd like to use as much as possible of what I already wrote, which was designed explicitly to support graphics - including wall decals and monster equipment, which angband doesn't have. The whole thing is built inside an HTML canvas, I'd be using pictures of text characters at first to bridge the gap, and then include angband's tilesets.

In principle, it's probably possible to "decompose" the main term in the frontend (so as not to try to fit tiles into text grids). The problem is with popup menus... That is also doable, in principle... meh, let's just do text first.

(Edit: on second thoughts, things like 'show me my inventory' 'show me my equipment' 'display monster recall' should probably all be done clientside without disturbing the backend process, so maybe a 1-1 correspondence of keystrokes to commands wouldn't be the best idea)

Hm, maintaining information about inventory, monster list and other stuff on the client side would be difficult, and unportable between variants - they all do it differently, and the term package only knows text, it doesn't understand what the text is actually saying.

Projectile animations (bolts/arrows etc) should be doable though I'd think?

Probably only in Vanilla.

The biggest thing it lacks that angband would require is popup menus.

Well, you could do it like Angband itself does - draw it over the main term When the popup goes away, the entire term is redrawn, to restore previous contents. "True" popups are also doable, I think (that would require some changes to ui-term.c).

I'm rather excited. I'm sure I can put together something better than DCSS webtiles. We can package it into a standalone executable for offline play too. (Or a standalone executable for online play! Or, best of all, a standalone executable for offline play which opens a socket and streams outputs for public consumption)

Let's do it Let's start small - only text, simple things first.

I'm envisioning something like that - the frontend takes strings that represent commands (perhaps utf8-encoded? or maybe as hex strings, like "010264"?) - and outputs JSON, like so, maybe: "{ "term": 1, "portion": "sidebar", "position": [1, 1], "length": 12, "content": [ (some stuff) ] }".

[Pete Mack]

@t4nk--efficiency matters here. You really want to keep updates in as few packets as possible.
Term with a set of tuples {x,y,l,c,t} (x,y, length, color, text)
If you use words for the tuples, most of the message will be metadata, as most color deltas are only 1 letter long.

[Gwarl]

Yeah I think I might be talking past you

What I would want would work something like a mud/text adventure as far as the C side of it goes, except utterly unintelligible to a human. Have a prompt, enter a command, recieve JSON.

But the player wouldn't be exposed to that interface at all, instead I'd have a series of scripts converting mouseclicks and keypresses into the commands to enter into the prompt, then parse out the JSON data into a JS object sent as a parameter to the functions which actually render the output to the screen.

So you could get a minimap where each tile can be 3 pixels wide instead of a whole character. Visible monsters would be an array of monster id's and a handful of ints representing fractional health and status effects - nothing to stop me loading information from angband datafiles to eschew the need for color information and text descriptions. In fact I've already written functions to parse angband .txt files into JSON.

So you're no longer looking at a term structure at all - just encoded strings to provide an essentially seperate program with the necessary information to constitute an interface. So our tasks would be entirely seperate, we would just need to agree on the formats for inputs and outputs.

Hold on a minute while I figure out how to configure my server to provide two sites with different backend frameworks for their respective domain names and I'll show you what I mean.

[t4nk]

So you're saying that you'd rather work with more structured information than term stuff (with the latter being colored text, supposed to be displayed as is)?

[Gwarl]

Right. I guess, having read all of this, all of the current frontends work with the term structure, so I guess you would be replacing that. Would that be significantly more difficult?

[t4nk]

Right. I guess, having read all of this, all of the current frontends work with the term structure, so I guess you would be replacing that. Would that be significantly more difficult?

Hm. I'd say it's doable for Vanilla. Its ui is big and has a surprizing number of features, but a lot of that is something that could be or should be done on the client side lets see

ui-birth.c - birth process
ui-command.c - various small commands, like html chardump
ui-context.c - mouse commands, the "enter" menu
ui-curse.c - curses menus (in game curses, not ncurses :))
ui-death.c - displayed when char dies
ui-display.c - all kinds of stuff; sidebar, animations, subwindows control
ui-event.c - mostly converting keypresses to and from human readable text
ui-game.c - main loop and associated stuff
ui-help.c - help reader
ui-history.c - player history
ui-init.c - just a couple functions
ui-input.c - input stuff
ui-keymap.c - keymaps
ui-knowledge.c - the '~' command. also messages reader
ui-map.c - map control, convering game data to text. also the 'M' command
ui-menu.c - menu stuff. all of ui uses it to display various menus
ui-mon-list.c - monster list
ui-mon-lore.c - monster recall
ui-object.c - inventory, equpment, quiver stuff; item ignore
ui-obj-list.c - object list
ui-options.c - game options (the '=' command)
ui-output.c - various helper functions, related to printing things
ui-player.c - the 'C' command
ui-prefs.c - parsing pref files
ui-score.c - game score
ui-signals.c - useless
ui-spell.c - casting magics
ui-store.c - buying and selling
ui-target.c - targeting (when firing, throwing, casting etc). horrible spaghetti :)

As you see, a lot of that really belongs to the client, and if you want...

But, the problem is, everything above term interface is very different among Angband's variants, and it is Vanilla that is actually the easiest to deal with (because of the effort undertaken some years ago to separate its ui and game logic). In other variants, the ui is very deeply entangled with the rest of the game; they also all do things differently; basically, each additional variant would require writing a lot of variant-specific C code. And writing that will be more difficult than for Angband.

[Gwarl]

I'm content to do this just for Vanilla. There's a lot to cover in that list, but it's doable.

I should mention I'm intending to make something based around graphical tiles and a mouse-driven interface first of all. I know, this is not the best way to play, but it's friendlier to newbies. And we already have very good ways to play with a keyboard and a text display.

[Derakon]

Right. I guess, having read all of this, all of the current frontends work with the term structure, so I guess you would be replacing that. Would that be significantly more difficult?

You'll need a standard way to convey to the frontend the semantics of what you want to show it, so that instead of doing "display an o here" you say "there's an orc at (24, 33)". And you need to do that for every single thing that gets shown to the user. So yes, it's significantly more difficult. But it's also the right way to do things.

It may be worth looking at NPPAngband's Qt port, as well as at Pyrel's modular frontends.