Angband development tasks

[Nick]

There are a lot of things that could be done to improve the game. Since I took over as maintainer, the focus has been on what you might call central aspects - splitting the game core from the UI, pushing stuff out to edit files, generalising game code. But here's a list of other things that could/should be done:

1. Write a borg, or adapt (after consulting him) APW's borg to 4.0
2. Work on simplified and touch command interfaces
3. Rewrite tile handling
4. Write front ends that don't use the text UI
   • - Windows
   • - OSX
   • - Qt
   • - iOS
   • - Android
5. Adapt Pete Mack's game recorder, or write a new one
6. Consider updating variants to 4.0
7. Try to make V and the new NPP talk to each other; ditto for PosChengband
8. Move more list-*.h files to edit files
9. Write a proper API for the core, rather than just having the UI calling core functions
10. Make debug commands more like regular commands
11. Have a more comprehensive debug compile
12. Move game messages out to an edit file
13. Write a lot more tests
14. Rewrite the .prf file system

Many of these things have been waiting to happen for a long time. Some of them won't ever get done. Most of them won't be done by me.

On starting as maintainer, takkaria started a drive to get the community more involved in development, which in my opinion was a stroke of genius. So this is a call to anyone out there who thinks any of the above tasks look like fun - please participate. And please add to the list.

[Derakon]

Try to make V and the new NPP talk to each other; ditto for PosChengband

<Vanilla> "Okay, I just teleported his paladin into a pack of gravity hounds. Ready, guys?"
<NPP> "Oh man, you won't believe what I have planned for his bandit. Radagast out of nowhere, then just when he thinks he's safe? Bam, Vecna. At 1500'.
<PosChengband> "Pfft. Bunch of amateurs."

More seriously, best of luck, I may contribute something if the stars align, but I have to say that a list that starts with "write an AI to play the game" does not fill me with confidence.

[tumbleweed]

A Silo of Worms
- The Thread -

[Zireael]

<vanilla> "okay, i just teleported his paladin into a pack of gravity hounds. Ready, guys?"
<npp> "oh man, you won't believe what i have planned for his bandit. Radagast out of nowhere, then just when he thinks he's safe? Bam, vecna. At 1500'.
<poschengband> "pfft. Bunch of amateurs."

more seriously, best of luck, i may contribute something if the stars align, but i have to say that a list that starts with "write an ai to play the game" does not fill me with confidence.

lol :d:d:d:d

[Derakon]

lol :d:d:d:d

...I have to ask: why did you remove all the upper-case letters from my post? Did you actually re-type the entire thing?

[fizzix]

I wish I knew anything about writing front ends...but I don't even know where to begin.

[debo]

...I have to ask: why did you remove all the upper-case letters from my post? Did you actually re-type the entire thing?

That's the forum, it auto lcases posts that are entirely caps. I know this because I try to write in all caps constantly

[HallucinationMushroom]

There are a lot of things that could be done to improve the game. Since I took over as maintainer, the focus has been on what you might call central aspects - splitting the game core from the UI, pushing stuff out to edit files, generalising game code. But here's a list of other things that could/should be done:

1. Write a borg, or adapt (after consulting him) APW's borg to 4.0
2. Work on simplified and touch command interfaces
3. Rewrite tile handling
4. Write front ends that don't use the text UI
   • - Windows
   • - OSX
   • - Qt
   • - iOS
   • - Android
5. Adapt Pete Mack's game recorder, or write a new one
6. Consider updating variants to 4.0
7. Try to make V and the new NPP talk to each other; ditto for PosChengband
8. Move more list-*.h files to edit files
9. Write a proper API for the core, rather than just having the UI calling core functions
10. Make debug commands more like regular commands
11. Have a more comprehensive debug compile
12. Move game messages out to an edit file
13. Write a lot more tests
14. Rewrite the .prf file system

Many of these things have been waiting to happen for a long time. Some of them won't ever get done. Most of them won't be done by me.

On starting as maintainer, takkaria started a drive to get the community more involved in development, which in my opinion was a stroke of genius. So this is a call to anyone out there who thinks any of the above tasks look like fun - please participate. And please add to the list.

It's about time! And yes, I was that bored.

[Nick]

It's about time! And yes, I was that bored.

Well, until the rest of the devteam brought me to my senses, I was actually planning to rewrite FA on top of the new V code before releasing anything, to make sure I had made it sufficiently general. When that does happen, I guess V will at least get the facility for adding wilderness built into it.

[Antoine]

There are a lot of things that could be done to improve the game. Since I took over as maintainer, the focus has been on what you might call central aspects - splitting the game core from the UI, pushing stuff out to edit files, generalising game code. But here's a list of other things that could/should be done:

1. Write a borg, or adapt (after consulting him) APW's borg to 4.0
2. Work on simplified and touch command interfaces
3. Rewrite tile handling
4. Write front ends that don't use the text UI
   • - Windows
   • - OSX
   • - Qt
   • - iOS
   • - Android
5. Adapt Pete Mack's game recorder, or write a new one
6. Consider updating variants to 4.0
7. Try to make V and the new NPP talk to each other; ditto for PosChengband
8. Move more list-*.h files to edit files
9. Write a proper API for the core, rather than just having the UI calling core functions
10. Make debug commands more like regular commands
11. Have a more comprehensive debug compile
12. Move game messages out to an edit file
13. Write a lot more tests
14. Rewrite the .prf file system

Hmmm what could we be missing

A.

[tumbleweed]

Wilderness

A plugin API and/or scripting support that allows you to add custom generators without touching game internals. D:

And speaking of D:,

2.Work on simplified and touch command interfaces
<SNIP>
4. Write front ends that don't use the text UI
<SNIP>
9. Write a proper API for the core, rather than just having the UI calling core functions

D:

[debo]

Hmmm what could we be missing

A.

Yesssssssssssssss

[Nick]

And speaking of D:,

D:

I think some (probably mostly true) context may be needed here.

Originally Angband was a game for terminal screens, with stuff just written straight to the screen as needed.

Then when porting it to different platforms became a thing, underlying terminal code was written to handle all this writing, and a bunch of files called main-win.c, main-dos.c, etc were written to translate that to the host operating system.

That made it very difficult to do things like tiles, for example - having tiles that can go over multiple rows and columns in your "terminal" which refreshes line by line is a recipe for lots of visual artefacts.

So takkaria came up with the brilliant idea of separating the UI - including everything to do with writing to the screen - completely from the core (ie what was happening in the game world). This has been one of the big changes attempted in 4.0, and it's really only half done. A big chunk of the code has been carved out and deemed UI - that's the stuff I'm calling the text UI, and it includes all the main-xxx.c front ends (and their ancillary files) for various platforms. The half that is done is that the game core no longer calls anything in the UI, so one could write a completely new UI without affecting how the core game works. But it would be nice to have a situation where the UI was better separated, and asked for info from the core and got it back rather than just observing it directly by looking at core internals.

And if you're at all interested in doing any of this, the devteam would be delighted - the community has kept this game going for 20+ years, and we'd like to keep it that way.

[Cold_Heart]

RE: what could we be missing

A web frontend, of course - angband in a browser.

[click to play]

On a more serious note, updating the variants to 4.0 seems like a great idea - poschengband has many annoying ui bugs etc that are fixed in vanilla...

[AnonymousHero]

And if you're at all interested in doing any of this, the devteam would be delighted - the community has kept this game going for 20+ years, and we'd like to keep it that way.

Soooooo tempted to try to "port" my Qt frontend from T2 to Angband... My main obstactle (in T2) was macros/keymaps. (Well, that and the rather large amount of assumed-to-be-blocking calls to/from "struct term" functions.) Is the UI code independent from keymaps in 4.x? Does the engine code still do "blocking" calls to the UI and/or vice versa?