Pyrel dev log, part 5

[fizzix]

EDIT: checked out the dungeons, fixing a few bugs in dungeon generation in the process. Looks like some of this code didn't get very thoroughly tested; oh well. Anyway, turns out A* pathfinding isn't the best idea for monsters in actual dungeons -- I was looking at about .5s/step. Guess I'll need to switch to something like heat maps (a.k.a. the "Dijkstra Maps" mtadd linked earlier) so there's less work for each individual creature to do when deciding where to go next.

mea culpa!

We should discuss moving some of the dungeon calculations over to numpy now that it's available.

[Derakon]

The bugs I found were actually due to the massive refactor that Kinematics did -- things like a factory still checking for nameSuffix, or trying to check isArtifact instead of looking in the item's categories. I mostly just meant that line as a reminder to other devs to try generating a few levels before assuming your changes are done and working.

Re: numpy, it's about as easy to install as it gets, even on Windows. There are binary installers for basically every Python/OS combination, so once you have Python 2.7 installed, you just go to their download page, and find either the 32- or 64-bit Python2.7 Numpy installer, download it, and run it. That's it.

Pyrel itself will eventually need to be its own little standalone Python environment, just so that players don't need to manually install everything themselves. My expectation is that newbie devs will be able to do a fair amount of hacking on Pyrel without having to install a "real" Python environment, but it's really the right thing for them to do in the long run. IMO for now at least we should limit ourselves to having an installation guide that walks users through installing everything they need.

As for sight radius, I disagree with Magnate. My main problem with making diagonal movement more expensive is precisely that basically no other grid-based game both a) allows diagonal movement at all, and b) makes it more expensive timewise than orthogonal movement. Breaking with tradition means significant unintuitiveness here, which, due to its nature, is going to lead to deaths through getting double-turned. Is it weird that diagonal movement is cheaper? Sure. But that boat sailed long, long ago. It's just one of those things that you have to deal with in the roguelike genre (and indeed in basically every top-down tile-based game).

[Magnate]

Is it weird that diagonal movement is cheaper? Sure. But that boat sailed long, long ago. It's just one of those things that you have to deal with in the roguelike genre (and indeed in basically every top-down tile-based game).

Except the entire Civ series, which charged 1.5 movement points for diagonal moves before switching to hexes for Civ V.

I suspect there are a number of other top-down tile-based games that do this too, it is unlikely that Civ is the only one.

Never mind.

[Derakon]

Hey Pyrel contributors, we need to choose a license. I always assumed Pyrel was operating under GPLv2, but I admit I never specified that explicitly. Is this acceptable to everyone else? Any other preferred licenses? Once we decide this I'll add a LICENSE.txt to the root level of the repository so others will easily be able to figure out how we operate.

[mtadd]

I authorize all code contributed by me to Pyrel to be licensed via GPLv2.

Matthew Tadd

[AnonymousHero]

Depending on how you see Pyrel going in the future with respect to variants I think it may make sense to choose a LGPL* variant. Specifically, if you envision Pyrel being used as a library of the "you call me" variety rather than as a "we'll call you" framework-type thing.

I think the (test) code I added may have been replaced already, but in either case: I hereby grant permission to use any code I've contributed to Pyrel under any license of Derakon's choosing.

[debo]

Just downloaded the source -- any reason you guys aren't using a requirements.txt? Don't any of you guys use virtualenv to maintain a pyrel-specific dev environment?

edit: FWIW, on master i believe someone may have forgotten to check in 'aiProc'

edit2: Any reason old-style classes are being used instead of newstyle if python 2.7 is a base requirement?

[Derakon]

Just downloaded the source -- any reason you guys aren't using a requirements.txt? Don't any of you guys use virtualenv to maintain a pyrel-specific dev environment?

The README has a dependencies list. I can duplicate it to requirements.txt if that would be helpful; I wasn't aware such a document was a standard. Is there some additional information that should be provided or is just a straight list of programs and libraries the norm?

As for virtualenv, I think you overestimate us.

edit: FWIW, on master i believe someone may have forgotten to check in 'aiProc'

Yes, sorry. As soon as my current change passes code review this will be fixed.

edit2: Any reason old-style classes are being used instead of newstyle if python 2.7 is a base requirement?

Largely inertia on my part -- I wrote most of the initial codebase and never really saw the point in using new-style classes. About all of relevance they seemed to let you do is use super(), which is almost always only used in the __init__ function, so it's about equivalent to just call the super's __init__ directly. Eh. I won't claim this is good reasoning, though, and if someone made a change to update to new-style classes throughout it'd get accepted.

[debo]

The README has a dependencies list. I can duplicate it to requirements.txt if that would be helpful; I wasn't aware such a document was a standard. Is there some additional information that should be provided or is just a straight list of programs and libraries the norm?

As for virtualenv, I think you overestimate us.

Yes, sorry. As soon as my current change passes code review this will be fixed.



Largely inertia on my part -- I wrote most of the initial codebase and never really saw the point in using new-style classes. About all of relevance they seemed to let you do is use super(), which is almost always only used in the __init__ function, so it's about equivalent to just call the super's __init__ directly. Eh. I won't claim this is good reasoning, though, and if someone made a change to update to new-style classes throughout it'd get accepted.

Yeah I don't think the newstyle classes thing is a big deal... the biggest boon you get (if not using mixins) is that you don't have to bind the base classes to the names of their parent classes, so refactors of the base classes are a bit easier.

I think probably the best way I could help would be to write up a quick virtualenv tutorial -- it makes life WAY easier if you have to e.g. play with more than one python project at once, or if you even are testing new dependencies in a different branch etc. Lemme know if you think that would be useful!

[Derakon]

I think probably the best way I could help would be to write up a quick virtualenv tutorial -- it makes life WAY easier if you have to e.g. play with more than one python project at once, or if you even are testing new dependencies in a different branch etc. Lemme know if you think that would be useful!

Hm, I suspect most of us only have one Python project we're working on -- Pyrel. But if you think it'd be helpful, feel free! The best place to put it would be on the wiki.

[Derakon]

A friend of mine from outside the Angband community was kind enough to whip up some C code for implementing the heat maps needed for pathfinding. They're about a billion times faster than the best-optimized Python code I could manage, which is a bit frustrating but there you go. This does leave us with some questions, though:

1) Relying on this will require Pyrel to have a build step. It's pretty trivial -- just a single invocation of gcc with no external dependencies -- but it's a build step. Of course you only need to recompile if you change the compiled code, so as long as you a) already have a compiled version for your platform, and b) never need to modify it, you don't actually need a compiler. So we could e.g. check in precompiled binaries into the git repository and automatically select the one appropriate for your platform at runtime, for example.

Normally Python projects have a setup.py script that, when run, does all of the necessary installation stuff. I've never made one of these, and I'm not clear how they decide what compiler to use. I'm also not clear that that's the right thing to do for a game project which expects to be run as a standalone application (as opposed to a Python library that will be used by other developers, which is the more usual case I've seen). Certainly people who just want to play Pyrel should not be required to have a compiler installed.

2) Do we ditch the pure-Python implementation or not? It could still be used as a fallback, but it is significantly slower (at least an order of magnitude).

3) This is a purely stylistic thing, but the C implementation uses a large bitfield (as an array of bytes whose individual bits are twiddled directly) to represent which cells are obstructed. We could keep it that way, or eat a (trivial) 8x increase in memory costs and work with 1-byte booleans. Or an unknown increase in memory cost and work with platform-appropriate ints. Opinions?

[Antoine]

Derakon, would you be so kind as to tell us how (vaguely) the C-called-from-Python thing works?

A.

[fph]

Have you considered Cython?

[Derakon]

Cython was the first thing I tried when trying to optimize the Python version. It cut runtime to 1/3rd the "pure Python" version, but that was still too slow.

Antoine: basically, the C code is compiled into a shared library, and then you use the ctypes library (a builtin Python library) to load it and do the necessary datatype conversions. I'll see about pushing a branch to my repo later today so you can see what the code looks like.

[LostTemplar]

Antoine: basically, the C code is compiled into a shared library, and then you use the ctypes library (a builtin Python library) to load it and do the necessary datatype conversions.

Just do the same with display code (with several different ways to display characters) and it will be fine.