Manifesto

[Spacebux]

So, there is a manifest.

I read through a lot of the material, Nick. Thank you for sharing that (again).

I'm not a coder, but I know enough to be dangerous. As my high-school math teacher put it, I'm likely to take the expression (x + y)^2 and come up with x^2 + y^2.

I concur the vanilla code needs a serious overhaul. I think the maintainers up to now have done a stellar job keeping the code as well documented and classified as it really can be. As your(?) manifesto points out though (and as one can generally glean from perusing the code in search of answers), there's too much inter-twined complexity. Certainly, a lot of potential amendments are curtailed by the complexity of the code.

Re-writing the V-code, starting anew like Pyrel, is probably the best long-term solution. Having dabbled only in C for the past two decades, I can say that C is easiest for me to follow, though I'm hardly adept at coding in it. While I understand that python is a decent language, I know very little about it (at the moment). Perhaps countless hours have been spent discussing this in this forum and on IRC, but, allow me to interject a few thoughts.

C is not a dinosaur language. Aside from the fact many college kids are no longer learning C, I don't see this as a reason to discontinue using C in future modifications of the core. The user interface, however, I think is a different topic.

One of the main gripes I have with java interfaces, there does not seem to be a buffer holder for one's typed prose. Classic HTML pages, such as these forums offer some type of buffer protection if one happens to hit the wrong key and go-back to the previous page, there's a good chance these typed characters are still in the buffer in one returns forward. Saved state. Java-based web-interfaces, from my experience, does not permit this. Everything is encapsulated and when an object dies/disappears, so does all that encapsulated data. How many times have I had to re-type my all important opinions because of Java? But, would that be an issue with a java based user interface or a python based user interface to Angband?

If the user interface were all written in Java (or python, which I'm not familiar with) and the code base maintained in C, then we could potentially see greater & better things for the game with more clarity. Ideas, game amendments, et. al., would not ... ok, should/ought not have to modify either one or both of those distinct code bases. Introduction of a new mob type with a new attack type should not require modification of 6 or 7 files in monster/*.c/h, plus possibly an addition/modification to z-msg.c/h, plus an addition/modification to spellsx.c, and any rework of the ui code to display it properly, and then a modification to edit/monster*.txt.

If I wanted to try to modify the effect of say GF_PLASMA, I would go to edit monster/list-spell-effects.h and try to permit RFire, double-RFire, or ImmFire to reduce the likelihood of GF_PLASMA causing a player to be stunned. I would most likely end up breaking the code and causing a seg-fault. Eventually, I might get there, but it will take me a while just to accomplish that one thing.

The edit/ files are great in this regard - easily readable, easily editable. Somehow, though, we have too many inter-dependencies in the code, that a new mob attack is not definable in those files. A re-write of the c-code is necessary, and, hence a recompile which tends to break and previous savefile data a player may hope to retain through upgrades.


I'll stop drivelling on here - I'm sure I'm sounding like the amateur I am here.

[ekolis]

C is not a dinosaur language. Aside from the fact many college kids are no longer learning C, I don't see this as a reason to discontinue using C in future modifications of the core.

That in and of itself makes it well on its way to becoming a dinosaur language. If 10 years from now nobody uses it but middle aged "senior solutions architects" or whatever they call programmers who refuse to transition to management in those days, what happens when all those folks retire? Who maintains the C codebases? The same thing is already happening to COBOL; it's only a matter of time for C.

Not that it's urgent to transition away from C, but if we want Angband to continue to be developed long-term, it would definitely be good to do so at some time. (Yay Pyrel!)

If the user interface were all written in Java (or python, which I'm not familiar with) and the code base maintained in C, then we could potentially see greater & better things for the game with more clarity. Ideas, game amendments, et. al., would not ... ok, should/ought not have to modify either one or both of those distinct code bases. Introduction of a new mob type with a new attack type should not require modification of 6 or 7 files in monster/*.c/h, plus possibly an addition/modification to z-msg.c/h, plus an addition/modification to spellsx.c, and any rework of the ui code to display it properly, and then a modification to edit/monster*.txt.

Didn't we already have something like this with the old Lua interface? Why was that removed, anyway? Was it done poorly, making the whole thing pointless somehow?

[Spacebux]

UI / Core split concerns.

One of the allures of angband, for me, is the rustic antiquity of the ASCII interface.

Other than the statelessness of java-objects, one of the other things that worries me would be we could get into a situation where we have 1~2 guys (I mean this in the male/female form) who are adept at coding the core, and 5~9 guys that are just code monkeys with the UI. It may be they core team cannot keep up with the torrent of changes to the UI.... e.g.

I also worry with the multi-player version, Nick -- I saw this happen with another client/server game: the requested code changes were so closely tied to what happened in the UI that a majority of the code went into the client, rather than the server. The server sat and basically kept time & passed messages between clients. All the development was client-side, close to the UI.

If V were to split into a true UI / Core code schematic, I'd be worried about some UI coder saying, "well, heck, its easier for me to just do it here, myself". And, down the path you go... . A lot of rather difficult decisions need to be made about what is core, what is UI, and how far the UI can go. Right now, it seems quite obvious & straight-forward.

Let's say someone wants to introduce a new bolt spell that performs a tight, curly-queue loop to a target. A lot of work will go into determining the path of the bolt, which ought to reside in the core. But, how easy it would be for a UI-coder to say, "hey, I have to draw this out anyway, I might as well report back to the core where the bolt is. I already know whether mobs are in the path of the bolt spell in my UI code, so I can just report hits/misses back to the engine."

[Spacebux]

That in and of itself makes it well on its way to becoming a dinosaur language. If 10 years from now nobody uses it but middle aged "senior solutions architects" or whatever they call programmers who refuse to transition to management in those days, what happens when all those folks retire? Who maintains the C codebases? The same thing is already happening to COBOL; it's only a matter of time for C.

Not that it's urgent to transition away from C, but if we want Angband to continue to be developed long-term, it would definitely be good to do so at some time. (Yay Pyrel!)

That, then would be an exercise for that new generation of coders. Personally, I don't see C disappearing anytime soon. COBOL, Fortran, PASCAL have gone to the wayside, yes, but that does not mean C must also. Java, python, object-orientated languages are sexier at the moment. But, that does not mean C has "lost" something. Minor coders, such as I, are not adept at building make-files, understanding compiler concepts, or knowing how to create & re-use our own libraries. Java, e.g., takes a lot of that out of the learning curve... which, I think, is a bad thing. Last I checked, LISP was still being taught in many places for its usefulness to teach coding algorithms more than anything else.

[DaviddesJ]

One of the allures of angband, for me, is the rustic antiquity of the ASCII interface.

I prefer ASCII to tiles. But I much prefer playing with colors, even though the original interface had no colors; I play with multiple windows, even though the original interface had no windows; and I'm surprised by how much I prefer playing with sounds, even though the original interface had no sounds. I don't want to speak for everyone, but I do think that the interface can improve even while retaining much of the original appeal. And probably needs to, as interfaces and display technologies change.

[ekolis]

I also worry with the multi-player version, Nick -- I saw this happen with another client/server game: the requested code changes were so closely tied to what happened in the UI that a majority of the code went into the client, rather than the server. The server sat and basically kept time & passed messages between clients. All the development was client-side, close to the UI.

If V were to split into a true UI / Core code schematic, I'd be worried about some UI coder saying, "well, heck, its easier for me to just do it here, myself". And, down the path you go... . A lot of rather difficult decisions need to be made about what is core, what is UI, and how far the UI can go. Right now, it seems quite obvious & straight-forward.

Let's say someone wants to introduce a new bolt spell that performs a tight, curly-queue loop to a target. A lot of work will go into determining the path of the bolt, which ought to reside in the core. But, how easy it would be for a UI-coder to say, "hey, I have to draw this out anyway, I might as well report back to the core where the bolt is. I already know whether mobs are in the path of the bolt spell in my UI code, so I can just report hits/misses back to the engine."

This is when the core coders smack the UI coders upside the head.

Or have an integrated team, not siloed teams of developers stuck in their own separate worlds... though that would require both core and UI to use the same programming language, or be at least somewhat fluent in both languages used...

Also, this entire problem can be avoided by designing the core carefully so that it does not blindly trust all inputs thrown at it by the UI. This is essential for multiplayer games - don't want player 1 moving player 2's units about, or deleting them entirely! If this design is helpful here, even though Angband is a single player game, might as well use it!

[Spacebux]

Or have an integrated team, not siloed teams of developers stuck in their own separate worlds... though that would require both core and UI to use the same programming language, or be at least somewhat fluent in both languages used...

Also, this entire problem can be avoided by designing the core carefully so that it does not blindly trust all inputs thrown at it by the UI.

Integration depends on the skill levels and time resources of the developers be roughly equal. In an open-source development scheme, that is not guaranteed. Further, if we go with a split-code-base scenario - you will probably have the UI coded in one language and the core in another. I don't know about python, but java, I know really is not well suited for a lot of the procedural tasks and work-flow currently done in C. Likewise, C's not the end-all for the UI. Its rather tedious, where java could just render up a UI in half the code.

My point here is - you will end up with some coders who know the UI so well, code-wise, they will out-code the core. Or, visa-versa. Its not easy to find cross-platform coders who can grasp what is going on in both languages equally well (even though this is a relatively small code-base). CoderA will say, "Hey, I've got 15-hours a day and I know python! I can write up a spiffy knew UI-app in 20-seconds!" CoderB might be your typical 50-something coder with decades of experience, "ahhh.. I'll get to the core changes when I can. Otherwise someone else can give it a whirl." In this case, you will see the UI code changes happening much more rapidly.. even if you told CoderA to do both... she/he/it will be more likely to make changes in the UI because she/he/it is more adept and comfortable programming in such environment.

[takkaria]

Didn't we already have something like this with the old Lua interface? Why was that removed, anyway? Was it done poorly, making the whole thing pointless somehow?

Lua was introduced as an attempt to make it easier to modify the game, yeah. It was taken out (by me) because it was done in such a way that there was no real advantage over using C. I wish I'd just rewritten it so that it was better instead of removing it now, though.

Other than the statelessness of java-objects

Hi Spacebux. I don't think anyone apart from you has suggested writing the UI in a different language to the rest of the game, and I don't know where you got Java from! Also, the object-orientated nature of Java has nothing to do with Java applets in browsers being rubbish; I think you're making a false link there.

[AnonymousHero]

Lua was introduced as an attempt to make it easier to modify the game, yeah. It was taken out (by me) because it was done in such a way that there was no real advantage over using C. I wish I'd just rewritten it so that it was better instead of removing it now, though.

This was my motivation for removing Lua from ToME 2.x too. For all practical purposes it was just as low-level (and with hardcoded constants, etc.) as the equivalent C code, so it only made debugging/change more difficult.

Hi Spacebux. I don't think anyone apart from you has suggested writing the UI in a different language to the rest of the game [...]

I've actually found this to be a good test of whether you've really separated the UI from the engine/core -- it can be tediuos though. However, you can get a lot of mileage out of the fact that different language ecosystems tend to be better suited to different things.

I've often wondered if it would be feasible to port ToME (or Vanilla, I guess) to use a JSON interface for the engine bits and a browser (Canvas + JS) for the front-end.

[Derakon]

I've often wondered if it would be feasible to port ToME (or Vanilla, I guess) to use a JSON interface for the engine bits and a browser (Canvas + JS) for the front-end.

My big concern with trying to do a server-side roguelike is that the player tends to want to be able to take a lot of turns very quickly, and every turn will involve a round-trip to the server to get the results of taking that turn. You need to get very low pings (on the order of 10ms) for play with a remote server to be acceptably quick. That's not impossible, so it's not an inherently bad idea, but there are definitely caveats to trying to run things that way.

What I eventually want to do with Pyrel is have the ability to stream games between players, so that you could log onto a central server, find another player, and then watch them play. The server wouldn't be responsible for actually running the game logic; just for coordinating between players, maintaining highscores lists, recording gameplay event logs, etc.

[Nick]

Hi Spacebux. I don't think anyone apart from you has suggested writing the UI in a different language to the rest of the game, and I don't know where you got Java from!

Probably this:

User Interface
This is the guts of the standard terminal interface that Angband has always used to display stuff to the screen and get commands from the player. Note that all ports use this, but there's no reason why someone should not write a completely native interface for a given platform.

So, no, I wasn't thinking different language, but rather that someone could write an interface for iOS (say) which used native drawing rather than pretending the screen is a terminal (which would probably not change the map so much as things like menus and character display). I guess the issue then is that the current situation that different platforms would get different levels of attention (no-one wants to work on the Windows port ) might become more accentuated.

[fph]

My big concern with trying to do a server-side roguelike is that the player tends to want to be able to take a lot of turns very quickly, and every turn will involve a round-trip to the server to get the results of taking that turn. You need to get very low pings (on the order of 10ms) for play with a remote server to be acceptably quick. That's not impossible, so it's not an inherently bad idea, but there are definitely caveats to trying to run things that way.

A server-client interface like that could be useful on a lone pc as well. Another popular Python project, the mathematical framework Sage, is usually run in the browser through a Mathematica-like "notebook" interface and a backend that does the grunt work. Typically both server and client run on the same machine.

The main advantage would be that the port would work instantly on anything that has a browser; no messing with native graphics is needed. Also, the browser is a relatively mature framework that allows for adding extra UI components easily (e.g., monster recall on mouse-over).

As for the network latency, it depends --- http://nethack.devnull.net/ runs an annual nethack tournament on their own servers; people login through telnet and play all over the world. I played in it, and I don't recall lag being an issue.

(by the way, is writing a new port easy or is there a steep learning curve? I might even give it a shot...)

[Spacebux]

@Takkaria I just threw java in there for namesake, really. I do, though, see Java being used more & more as tablets ratchet up app-power.

Already, though, I can see some needed discussion happening here, which is good. I think separation of UI w/ core is a worthy goal.


For discussion:

• What are the goals of UI/Core separation
• What components go in the server
• What components go in the client
• Is a client really a client?
• Does UI/Core separation necessitate client/server?

[Derakon]

UI/Core and client/server are separate issues. Client/server does really want to have good UI/Core separation though.

The main thrust of Nick's manifesto is a reorganization of the codebase without making any functional changes (i.e. changes in the behavior of the program). It's completely orthogonal to questions of introducing new languages, having a game server, or anything like that, and I'd personally caution against project overreach. If you want to take things further once the code has been reorganized, that's fine, and if you have specific goals in mind then you should make certain that the reorganization will be able to encompass said goals, but just keep the reorg to a reorg for now.

[ekolis]

Is a client really a client?

What does that question mean?

Does UI/Core separation necessitate client/server?

IMO, no. Client/server to me implies that client and server can be separated by a network, while UI/core simply means that the UI and core are different modules, but there need not be network support.

This also brings up another question: Should there be a third "library" or "utility" module, referenced by both UI and core, that contains a lot of common code that both would otherwise have to implement redundantly? E.g. line of sight algorithms, breath cone shapes, etc. (Technically both of these could be done solely server-side, but that would require a lot more messages to be transmitted to the client in real time.) This would only be useful, of course, if both UI and core were written in the same language, or at least if core were written in a language that UI could call (e.g. core in C, UI in Lua, C#, Python, etc.)