A proposal... (python)

[Sirridan]

I'm just using a generic interface for the UI library, so you could write one with any library you want in theory, and just plug it in and it works. The core PyAngband does't care about what's outside it.

[Derakon]

Generally speaking, I'd recommend OpenGL just because it will make it far easier to play with different display modes. The default mode, of course, would just be 2D textured quads of letters, but e.g. ISOAngband could start by rotating everything 90° and moving the camera, and you could do a first-person Angband by taking that and putting the camera on the player. You could also play with transparency for floor stacks, terrain (variant territory, presumably), and so on. You could also do a higher-resolution 'M' map with OpenGL than you could with curses, since the effective smallest pixel size in curses is one character. And of course you can start getting fancier with graphics if you really want to. Particle-based spell effects would look nicely incongruous next to the ASCII...

Curses is designed for faking graphics in a terminal. As soon as you want to do anything else, you can't use curses any more.

[Netbrian]

If a Python port of Angband (with gameplay more or less the same as vanilla) was completed, would there be a chance of this version becoming the mainline vanilla version instead of the C version? It seems like it'd be rather unrewarding to have both versions developed and updated in parallel.

[Sirridan]

If a Python port of Angband (with gameplay more or less the same as vanilla) was completed, would there be a chance of this version becoming the mainline vanilla version instead of the C version? It seems like it'd be rather unrewarding to have both versions developed and updated in parallel.

That would honestly be nice, especially if it was my attempt that was worked on and then became new V, however even if not, I still want to do it for the heck of it. Also it would be really easy to do the variant I've been thinking of with.

In any case, I don't think C vanilla will ever die, it's easier to keep going on some kinds of devices like phones and such, although as power increases (and the fact most of them run linux...) running python on them isn't a big stretch.

Sorry if my post is badly written, I'm quite tired.

[Magnate]

It's way too early to tell. If the PyAngband port diverges in some critical gameplay areas, because its devteam think those are improvements, then it's unlikely to end up superceding V. If it's absolutely identical to V in gameplay, then IMO it could end up being the new V if Takk (and all the variant maintainers!) are happy with that. But first we have to get there.

If we really wanted the ultimate platform-independent port, we should really look again at java. *Everything* runs java - even dishwashers and fridges nowadays. (Ok that might be a bit of a stretch, but let's not pretend that porting to Python is to increase usability across platforms ...)

[AnonymousHero]

If we really wanted the ultimate platform-independent port, we should really look again at java. *Everything* runs java - even dishwashers and fridges nowadays. (Ok that might be a bit of a stretch, but let's not pretend that porting to Python is to increase usability across platforms ...)

There's also the whole static type checking vs. dynamic type checking thing... when you have a code base as large as Angband with no easy way to write complete unit tests, my hunch is that it'd be way too easy to introduce serious bugs caused by making trivial mistakes (like incorrect spelling of a variable, etc.).

(Not that static type checking doesn't come with its own overhead, but....)

[Magnate]

There's also the whole static type checking vs. dynamic type checking thing... when you have a code base as large as Angband with no easy way to write complete unit tests, my hunch is that it'd be way too easy to introduce serious bugs caused by making trivial mistakes (like incorrect spelling of a variable, etc.).

(Not that static type checking doesn't come with its own overhead, but....)

Ah ... someone on #angband-dev has written some unit tests .... I'm overdue checking them out ... http://github.com/elly/angband

[Therem Harth]

Hmm...

I was thinking of porting OAngband to procedural Python and Tkinter, but as you guys point out it would still be a procedural mess with tons of global variables; so no real advantage gained, plus the disadvantage of more runtime bugs.

I guess I could try an object oriented rewrite... I'm very much a design newbie though, so I have trouble figuring out exactly what I should make an object. Player and monsters and items obviously, but what about spells? Should each terrain feature be an object? Or would that be unnecessary and grossly inefficient?

(Can you tell I'm looking for coding projects? )

Edit: I do kind of feel at any rate that non-crucial applications - especially games such as Angband - shouldn't be written in low-level languages. Too much room for buffer overflows and other stupid bugs. Could be a reflection of my inexperience with C/C++ though.

[AnonymousHero]

"Object Oriented" isn't actually a solution to any real problem. (And I say this as a professional Java developer. We're force to use objects for everything.)

The thing to realise is that you want the right abstractions rather than shoehorning yourself into any particular paradigm, be it imperative or logic programming or pure functional.

The one thing I would argue is that immutability is the king of debuggable and testable programs. (See Haskell and QuickCheck.)

(Slightly drunk as I write this, so... appropriate dosage of salt.)

[Therem Harth]

Hmm... I had been under the impression that the chief benefit of OOP was making things easier on developers, by forcing the code to be organized in an at least somewhat sensible fashion. I guess that's not necessarily the case?

(I don't see why a Java codebase couldn't be messy and disorganized, but it seems to me it would take a lot more laziness to do that than to write a messy and disorganized codebase in C. Or does that have more to do with C being lower level?)

[Derakon]

You can make crappy code in any language. The mere fact that a language is biased towards OO designs doesn't mean anything as far as the code written with that language being nicer than code written in a non-OO-oriented language. Objects are mostly just a convenient abstraction to associate certain data with certain functions.

[zaimoni]

Hmm...

I was thinking of porting OAngband to procedural Python and Tkinter, but as you guys point out it would still be a procedural mess with tons of global variables; so no real advantage gained, plus the disadvantage of more runtime bugs.

I guess I could try an object oriented rewrite...

Which would be easier in C++. [E.g., Zaiband.]

I'm very much a design newbie though, so I have trouble figuring out exactly what I should make an object.

Anything that is a C struct should be strongly considered for elevation to object status.

Player and monsters and items obviously, but what about spells? Should each terrain feature be an object? Or would that be unnecessary and grossly inefficient?

What deserves to be an object, that doesn't have an associated struct, is "cave". That rewrite is moderately difficult, though.

Edit: I do kind of feel at any rate that non-crucial applications - especially games such as Angband - shouldn't be written in low-level languages. Too much room for buffer overflows and other stupid bugs. Could be a reflection of my inexperience with C/C++ though.

Too bad practically all of those languages started existing ~15 years after Moria.

As an outsider (my dominant language is C++, fluent ones are C, Perl, and PHP, and I can limp in Python), Lua strikes me as the best candidate for a "safer C". I can't think of a good high-level object oriented language for roguelikes [Python would be a "nice try" if it had curses everywhere it was ported to], but at the moment the hype I've read would suggest Ruby.

[zaimoni]

Hmm... I had been under the impression that the chief benefit of OOP was making things easier on developers, by forcing the code to be organized in an at least somewhat sensible fashion. I guess that's not necessarily the case?

It's not remotely the case at all.

Object orientation is a shorthand that does the following:
* gives you a hidden parameter for the object
* allows declaring object members as "don't access these from any old function", which can be used to convert many bugs into syntax errors.

For small-scale projects, it is particularly true that if the (lead) programmer doesn't have adequate procedural programming skills, then spotting where object orientation makes things easier is next to impossible.

E.g, the problem with converting terrain features to a struct/class in V, is simply that:
* there's nothing that naturally would want to take a terrain feature as a parameter.
* there's no internal structure to wrap (I suppose you could use bitfields but why bother).

(I don't see why a Java codebase couldn't be messy and disorganized, but it seems to me it would take a lot more laziness to do that than to write a messy and disorganized codebase in C. Or does that have more to do with C being lower level?)

The mess/disorganization manifests differently.

In Java, the general problem is Lines of Code. One time I was reviewing XML generation frameworks; the Java one was disqualified for taking 12 pages of printout to do what three other frameworks could set up in one page.

In C and C++, it's more that the language has a Programmer is God mentality and won't stop you from shooting yourself in the foot.

[Pete Mack]

-I'd say the choices are python and C#. With all its relational tables (monster.txt, spells.txt, etc, not to mention the knowledge menus), angband is just begging for fragments of functional programming.

Python (lambda) and C# (LINQ) are the languages that deliver FP fragments more or less seamlessly.

[Therem Harth]

Ah...Thanks guys, that cleared things up.

Re Python. Why curses? Couldn't Tkinter be used on any platform Python was ported to? Or is too much of a break from tradition for it not to have a pure CLI mode?