A proposal... (python)

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Sirridan
    Knight
    • May 2009
    • 560

    #16
    I'm still working on it to see how far I can get, I'll post it if I get anywhere interesting.

    Comment

    • nppangband
      NPPAngband Maintainer
      • Dec 2008
      • 926

      #17
      Originally posted by Magnate
      Ironically that means that this project would have to focus on the boring stuff (the z-term type stuff in AngbandBase), if he's already doing the interesting (gameplay) stuff in Python. But yes, worth looking into.
      That is kind of my thinking. As long as people are considering a complete rewrite, why not do something like that? Try to bring Angband out from the constraints of 1980s technology and see what is possible? (With the limitation being how much time people are willing to spend on this project; of course)
      NPPAngband current home page: http://nppangband.bitshepherd.net/
      Source code repository:
      https://github.com/nppangband/NPPAngband_QT
      Downloads:
      https://app.box.com/s/1x7k65ghsmc31usmj329pb8415n1ux57

      Comment

      • Derakon
        Prophet
        • Dec 2009
        • 9022

        #18
        Assuming a rewrite happens, I would suggest doing it in such a way that it supports old-school play but also has the option of going in newer directions. Make it modular, in other words. Blengband would replace the rendering module and flip a toggle that says "make it real-time", but would otherwise use the same base as "PyVanilla" would.

        Comment

        • nullfame
          Adept
          • Dec 2007
          • 167

          #19
          Originally posted by nppangband
          Try to bring Angband out from the constraints of 1980s technology and see what is possible?
          I'm sorry because I don't mean to come off as a crotchety old man here but I've followed this thread and two things have constantly been on my mind:

          1. Isn't C still one of the most widely used languages in the world? We're not talking about FORTRAN here. I would guess the Python interpreter is written in C.

          2. Why Python? I'm not trying to be partisan here or start a "my language is better" thread. I honestly want to know. I don't program in C. I don't program in Java but why would Python be a better choice? From my vantage point it appears to be enjoying a period of popularity. Java seems to be the dominant player today and for some time now (other than C). Are there features/libraries of Python that would make it an easier project? Or is Python just what the cool kids use today?

          Comment

          • RogerN
            Swordsman
            • Jul 2008
            • 308

            #20
            2. Why Python? I'm not trying to be partisan here or start a "my language is better" thread. I honestly want to know. I don't program in C. I don't program in Java but why would Python be a better choice?
            I would assume that the purpose of a project like this is to improve the Angband codebase in order to ultimately make Angband a more extensible game. For variant writers, this would mean that more radical gameplay alterations and additions are possible with fewer lines of code. For Vanilla this would mean that gameplay and UI refinements are quicker and easier to implement. Hopefully.

            There's nothing wrong with C, but because C is a more low-level language, extensibility does not come easily. On the other hand, object-oriented languages provide several features which are intended to improve extensibility.

            Why Python? First of all, Python is a dynamic language while Java is not. This can be a good thing or a bad thing depending on how you look at it, but if rapid development is a major goal then I would think that a dynamic language would be a plus.

            Of all the dynamic languages Python is probably the most popular right now (although maybe Tcl could compete in that area). Popularity is certainly a selling point, as it means that there are plenty of developers around with Python experience. With popularity also comes maturity; Python benefits from a very comprehensive set of standard libraries and highly optimized compilation (for a dynamic language anyway).

            For a project like this I don't think Java would be a bad choice either. Java is more rigid, though, and that's some of what the project is trying to get away from.

            Comment

            • Derakon
              Prophet
              • Dec 2009
              • 9022

              #21
              Having programmed fairly extensively in C, C++, Java, and Python, here's my take on the language thing:

              C is painful to write in. It's basically two steps up from assembly language, which gives you a lot of control and means you can write very efficient code, but also means that you can shoot yourself in the foot very easily. Memory management is a major pain, for one; for another, the language doesn't have good support for non-imperative program designs. Finally, the language simply isn't very expressive; to do even simple things you must write a large amount of code.

              Angband conceptually lends itself nicely to an object-oriented design. Monsters should be objects. The player should be an object. Each equipment item should be an object. Currently what we have are global structs; it's difficult to track down what mutates those structs, what reads from them, what would be broken if you made a seemingly-innocuous change. The codebase is largely unstructured and intimidating to new developers.

              Moving Angband to an object-oriented design would result in a cleaner, more modular codebase. New developers would be able to say "I want to try messing with the player's stat gain system. That should be handled by the Player class." and dive in. But such a redesign will require a new language. As I see it, there are three choices: C++, Java, and Python. Any other languages would fail to meet some prerequisite (e.g. C# is not sufficiently cross-platform; Perl is widely regarded as ugly; Lua is not well-known). So which of these languages do we use?

              * C++: a natural extension to C. Quite fast, and we would be able to keep directly using the existing codebase while bits of it get upgraded. But we're also stuck with many of C's flaws, in particular having to manage our own memory. Cross-platform deployments will continue to require a build system.
              * Java: compiles to cross-platform bytecode, so deployment should be trivial. Has its own memory manager. Syntax strongly resembles C/C++. Tends to be wordy -- "print" is "System.out.println", for example. Performance is comparable to C++ these days; maybe a bit slower.
              * Python: interpreted, not compiled, so there's no compilation step to worry about. Cross-platform distributions would require a packaging system like py2exe or py2app (I'm not certain what Linux would do; probably use the system Python install). Has its own memory manager. Very expressive; concepts can be concisely represented without creating confusion. Will certainly be slower than either C++ or Java, to the extent that would be noticeable in a turn-based game like Angband. Does not have strong typing; whether this is a plus or a minus depends on the coder. Some people think the significance of whitespace is weird; certainly, we'd need to agree on what exactly to use for indenting.

              My personal inclination is to use Python, for the following reasons:
              * Development tends to be faster in expressive, permissive languages than in pedantic ones. And if we're going to rewrite a 100k-line codebase, we'll want fast development!
              * The game will run plenty fast on anything that was made in the last ten years. Past that I don't think it's worth worrying about.
              * The language is prettier.

              But honestly, any of these three would work just fine.

              Comment

              • Tiburon Silverflame
                Swordsman
                • Feb 2010
                • 405

                #22
                My preference is Java, in part because it has such a rich developer base. There are numerous libraries out there, such as the Colt math package and CERN collection classes, which can easily be used in Angband. I think Java's been more actively used, so it may be somewhat further along too. (I noticed, for example, that Python doesn't do enum classes, which would be incredibly useful, in a natural manner, while Java now has very nice enums. I used this when I built a little Java app that reads artifact.txt, builds a bunch of drop-down lists to select artifacts by slot, then displays your resists etc. from them in a table. Handy tool for comparing equipment sets.)

                Also, I prefer minimal impact to my system. Java's practically ubiquitous these days, so we don't force any new tools onto someone's system.

                I think Java and Python would probably both work fine, and would both readily support a better design. C++ would personally be my 3rd choice.

                Comment

                • Derakon
                  Prophet
                  • Dec 2009
                  • 9022

                  #23
                  How to do enums in Python:

                  Code:
                  (APPLE, BANANA, CRAISIN, DURIAN) = range(4)

                  Comment

                  • Magnate
                    Angband Devteam member
                    • May 2007
                    • 5110

                    #24
                    JavaAngband has already been tried, and abandoned. I'm not a programmer in any serious sense, so I won't try to argue the details - I just know that it's been tried. That doesn't mean it can't be tried again. I don't know anything about java at all, so could not help.

                    PyAngband hasn't been tried yet, and I would be happy to participate in such a project. I do know a little Python - about the same as I know C, so I could be vaguely useful.

                    Python is ubiquitous on all Linux systems - at least, I've never seen one without it. It's not yet on all Win or Mac systems, but we could use py2exe and py2app to get around that. It's less hassle than having to install mono on Linux to run C# stuff when dotBLOAT is on all Windows boxen ...

                    Java is more or less on all systems, but there are different java interpreters / JREs. I've come across apps that will run on openjdk but not gcj or vice versa. To my knowledge there is only one Python.

                    I don't think anyone is seriously considering C++ ...

                    And yes, let's by all means free angband from 1980s technology, but let's get it working first ...
                    "Been away so long I hardly knew the place, gee it's good to be back home" - The Beatles

                    Comment

                    • cinereaste
                      Scout
                      • May 2010
                      • 43

                      #25
                      My preference would be Python. RogerN and Derakon provide great summaries of its strengths. I've never worked with Java, so I'm not in a good position to evaluate it. My preference of course is to use what I know.

                      One potential issue that hasn't yet been mentioned is whether to use Python 2.6.x or 3.x. My understanding is that 2.6 is currently used more, but it looks like 3.x is where the future of the language is, so I would vote for a 3.x implementation. I don't know how easy or difficult it would be to migrate later on.
                      Last edited by cinereaste; September 3, 2010, 20:32. Reason: fixed a typo

                      Comment

                      • Derakon
                        Prophet
                        • Dec 2009
                        • 9022

                        #26
                        The conventional wisdom with Python 2.6 vs. 3 is that you should move to 3 once the libraries you depend on are available for 3. This is a lengthy process, though; 2.6 isn't going anywhere anytime soon. At a guess, PyAngband would depend on Qt for windowing / UI widgets, OpenGL for drawing, possibly PyGame for sound and font rendering, and wouldn't have much else in the way of dependencies. If those are available for 3, then by all means, PyAngband would want to be written in 3.

                        By the way, Python comes standard in OSX, but doesn't have much of anything in the way of third-party libraries installed. py2app would definitely be the way to go for native applications.

                        Comment

                        • d_m
                          Angband Devteam member
                          • Aug 2008
                          • 1517

                          #27
                          Originally posted by Derakon
                          The conventional wisdom with Python 2.6 vs. 3 is that you should move to 3 once the libraries you depend on are available for 3. This is a lengthy process, though; 2.6 isn't going anywhere anytime soon. At a guess, PyAngband would depend on Qt for windowing / UI widgets, OpenGL for drawing, possibly PyGame for sound and font rendering, and wouldn't have much else in the way of dependencies. If those are available for 3, then by all means, PyAngband would want to be written in 3.

                          By the way, Python comes standard in OSX, but doesn't have much of anything in the way of third-party libraries installed. py2app would definitely be the way to go for native applications.
                          I think it's up for debate which UI library to use. If I were going to use Python I would probably just use Pygame (or Pyglet) for everything.
                          linux->xterm->screen->pmacs

                          Comment

                          • Derakon
                            Prophet
                            • Dec 2009
                            • 9022

                            #28
                            Pygame's big weakness is that, like the SDL that it is based on, it doesn't understand multiple windows. I don't know if pyglet has support for that either.

                            You'd definitely want to get some kind of UI widget library involved for file open/save/etc. dialogs if nothing else, but they can also allow for multiple windows each composed primarily of an OpenGL canvas.

                            By the way, I've done some game development in Python with Pygame/PyOpenGL. In fact I'm currently wrestling with the transition to OpenGL after I came to the conclusion that Pygame's drawing system wouldn't scale for my needs. Most of it's working again; all I'm missing now is the direct drawing logic (e.g. drawing the bounding polygons of sprites for debugging) and a replacement system for drawing massive images.

                            Comment

                            • cinereaste
                              Scout
                              • May 2010
                              • 43

                              #29
                              I've never used it, but wouldn't curses be an option? It's standard in Python.

                              Comment

                              • zaimoni
                                Knight
                                • Apr 2007
                                • 590

                                #30
                                The curses module in the standard releases of Python is a front-end for ncurses.

                                For the standard releases, it works great everywhere ncurses does. This definitely excludes Windows.
                                Zaiband: end the "I shouldn't have survived that" experience. V3.0.6 fork on Hg.
                                Zaiband 3.0.10 ETA Mar. 7 2011 (Yes, schedule slipped. Latest testing indicates not enough assert() calls to allow release.)
                                Z.C++: pre-alpha C/C++ compiler system (usable preprocessor). Also on Hg. Z.C++ 0.0.10 ETA December 31 2011

                                Comment

                                Working...
                                😀
                                😂
                                🥰
                                😘
                                🤢
                                😎
                                😞
                                😡
                                👍
                                👎