Topics

1

Incubator / Qaf - A roguelike implemented in Python

« on: November 19, 2016, 01:59:36 PM »

Hello, you might have noticed I stopped working on practicerl. Actually, you probably didn't, I imagine all of you have more important things to do than camp my github profile. At any rate, development didn't stop, it got shifted around and forked sufficiently that attempting to merge it back into the old repo would have been more trouble than I was interested in.

It has come a long way, and if anybody wanted to take a look at it and give me feedback, I'd love to have it. This is honestly the most complicated code base I've ever actively worked in, so I'm certain I've done several horrible things. In fact, I can think of a few horrible things I hope to be fixing once I finish the push to an Alpha release.

What works:
1) Level generation w/ the placement of monsters (Orcs and trolls at the moment).
2) Movement in all 8 directions using the traditional keys.
3) Monsters know how far away they are from you.

What doesn't work yet:
1) Combat. That will be my focus next week. I expect to have a playable alpha by Friday. Specifically, that means a single level filled with monsters you can try to kill who will also try to kill you. No healing, so it's more a question of how many you can kill before you succumb to your wounds, but then again that's most roguelikes so... excellent!
2) Logging. I attempted to create a log file, but it's failing to log for me and I'm not sure why.
3) Messages. They show up, but they all just overwrite each other, none of them go down to the next line. If anybody could help me figure out what I've done wrong there, I'd appreciate it.
4) FOV. I haven't even bothered yet because I'll be writing it by hand. I've read the implementations on roguebasin. I don't understand them well enough to rewrite them. And since this is a learning exercise, not a AAA game, I don't want to copy/paste code. I've worked up a mental representation of how raycasting works, but I had one of those for A* for years before I finally worked out how to do it. Fortunately, the A* stuff (particularly the recursiveness of it) should help in implementing this so I doubt it will take that long.
5) Error catching. If your terminal doesn't have enough colors, hard crash. If your screen is too big, it sometimes hard crashes. If you do something it doesn't expect, hard crash.
5) Saves

It currently has no dependencies outside of the Python Standard Library (several of the files import a library called attr, but none of those files get imported at the moment). Run python3 cursescolors.py and make sure you have all the colors (I haven't put any error checking or fallback for color-poor terminals) and then run python3 game.py to play. Press q to quit the game. This is known to work in Linux with an xterm-256colors terminal. Not tested in any other platform (well, that's not quite true. I know it doesn't handle color-poor terminals because I tried it in a plain xterm terminal). Once more, feedback would be greatly appreciated.

https://github.com/jonathanabennett/Qaf

2

Programming / Dijkstra Maps... What have I done!?

« on: October 10, 2016, 02:29:14 PM »

So, I'm attempting to use a Dijkstra map/heat map in my game (since that's obviously the easiest way to handle monster AI movement). But I've done something horribly, horribly wrong. In a 12x12 empty room, it takes 80 seconds to run. Since it's the heat centered on the player, it's going to have to update pretty much every turn. The problem is definitely that I'm visiting nodes too often (it takes 8,000 iterations to do an empty 8x8 room and I don't want to even consider how many it takes for a 12x12, but I estimate it to be about 41,500 or so). Below is the function (written in Python). I've pulled this out of a Map class, but before I try optimizing the data structure of the tiles or their storage, I want to cut the number of visits down to what it's supposed to be (a bit less than half what it is now if I'm reading the O() notation on Dijkstra's correctly. How can I fix this?

Code: [Select]

    def heatmap(self, source_x,source_y):
        l_open = []
        source = self.lookup(source_x,source_y)
        if source: l_open.append(source)
        start = True
       
        while l_open:
            cell = l_open.pop()
            cell.visited = True
            neighbors = []
            addrs = self.get_neighbor_addrs(cell.x,cell.y)
            for addr in addrs:
                c = self.lookup(addr[0],addr[1])
                if c:
                    if c is not cell and not c.blocked:
                        neighbors.append(c)
            if start:
                start = False
                cell.previous = cell
                cell.value = 0
                for neighbor in neighbors:
                    neighbor.previous = cell
                    l_open.append(neighbor)
               
            else:
                neighbors.sort(key=lambda x: x.value)
                cell.previous = neighbors[0]
                cell.value = neighbors[0].value + 1
                for neighbor in neighbors:
                    if cell.value < neighbor.value:
                        if not neighbor in l_open:
                            l_open.append(neighbor)

        return self.render(0,self.width, 0,self.height,True)
*The only changes made to this code was the removal of variables and print() commands I was using to track the output.

3

Incubator / practicerl - A Practice Roguelike for me practice with!

« on: June 05, 2016, 12:20:25 PM »

I like roguelikes, and so I want to try creating one. At first, I'll simply be following the libtcod for python tutorial to get a hang of how this works. But, due to technical errors (errors which cost me a grand total of 4.5 hours of coding time spent staring at various g++ compiler errors going "********* THIS IS WHY I USE INTERPRETED LANGUAGES!") it will be implemented in Python 3.4.3 using just the builtin curses library.

I fully expect that to lead to all kinds of... fun when I get to things like A*, FOV, and level creation, but that's the limitations imposed by my dev environment. On a related note, if anybody has experience getting libtcod, cffi, and/or tdl to install on a 64 bit Chromebook and would like to share that with me, I'd be most grateful if you could pass that wisdom on.

https://github.com/jonathanabennett/practicerl

Right now, this repo just has my curses test to ensure curses would even work using a CodeAnywhere container, and a readme describing in more detail just what I'm hoping to accomplish. Feedback is welcome, but anybody telling me to try another language will be ignored. I'm doing this as a hobby for fun in my free time. My day job already has me learning Javascript. Until I learn that, I'm not going to try picking up Ruby, Java, or (God forbid) C++ so I can do a fun hobby in my free time. And I'm not implementing anything as complex as a Roguelike in Javascript. I'd rather beat my brains out with a large hammer.

4

Programming / Libtcod can go jump in a lake

« on: June 05, 2016, 06:20:13 AM »

3 hours. 3 hours!? I realize some of this is the slow internet connection in this cafe. But I have spent 3 hours trying to get TDL for python working in Crouton on my Chromebook. Django worked in 10 minutes. Eclipse also! After 3 hours, I have hit a wall because I'm running 64 bit (like, you know, the whole rest of the world) and libtcod won't compile.

Now to use pygame instead. Libtcod can go jump in a lake, I don't care how complete it's tutorial is.