quick update

Well, not really. Career fair + etc have been minimizing the time I get to think about working on PyRL/Project Graff/whatever. Bah.

Less lazy than before

Found a book at my library when someone went to return it. It is dated, and a fair amount of it is common sense, but it was interesting for 2 reasons:

One, it was made around the days of when Neverwinter Nights was fresh and new, and so the book is littered with references to Ultimas, Betrayal at Krondor, Wizardry, and all the other famous known WRPGs. It even has a design document from Fallout 1 on an “Underground Vault”. Interesting, because it makes heavy mention to a GURPS’y system and it references skills and so on that aren’t in the final game.

Two, there is a pretty decent section on the theory of worldbuilding and basic mechanics of quests and such that could be pretty applicable to what I’m trying to do. I’ll have to keep this book laying around for a bit…

Heh, the perks of working the library front desk. As soon as someone returns something popular, like say the Blade Runner special edition DVD, I can swipe it and rent it for myself before it even goes back on the shelf. Whee.

Suh-weet. #2!

New “version” added to the files, v. 2 according to google. Only change is that monsters are now doing nothing, and equipment can be displayed over the character. Still hardcoded in though and not extendable all that much.

And in related notes, using this, I have learned an interesting fact: applying real life stats to games at times doesnt work. Using some quick rules of thumb and some pygame trickery, I found an average of 12 thousand cities spread across the game map to be way too dense. If anyone is reading this, I basically calculated a .50% chance of whether a village would be at that region or not, and excluding mountain/forest areas and water, at .50%, we had about 900 cities all spread about 4-8 pixels away from eachother. Didnt upload it as it was a really trivial script.

Though, that noise spread might be good for distributing all points of interest, and not just the smaller towns (the larger cities would be predetermined most likely). It still impresses me how stuff like Dwarf Fortress can just generate an entire world in about 5 minutes, complete with animal population breakdowns and all.

The other surprising thing is that, using that demographics site and a 1.52% chance of a village being on a given pixel, I was only 200 villages off from what one of the site’s link’s to an automatic calculator said there should be (~12,000), assuming .5km per pixel.

I also feel like I’m having too much fun doing the random/procedural generation things than I am pygame programming, heh.


Well I think what I’m going to go and do is implement the CA cave algorithm as one of the primary types of maps a player encounters. I figured cities, caves, crypts and whatnot are going to be close to the average assortment of dungeon layouts a player would run across in the wilderness, so I’m working towards basic ASCII map algorithms for those. Making a “city”–more like a village is straightforward as it’s mostly adding non-colliding rooms of varying sizes across the grid, but the annoying part is actually distributing out and constraining things so that it looks somewhat natural.

I hear a fair amount about fractal Brownian noise and how threshholds from it can generate some interesting shapes, maybe I’ll play with those eventually. But maybe I should also start looking into player equipment and such, too. =\

And speaking of player equipment, visuals relating to it have been basically hardcoded in. Here’s a picture:
[just a quick note, I changed where my screenshots are hosted (click the screenshots tab up top), so this picture doesn’t exist. Sorry about that, but if you navigate to the home page you can see all the fancy new stuff I’ve done since then!]


So..I made a cellular automata cave generation. It was surprisingly easy to do. I think it’s time I give up on generic dungeons and go for weird looking ones like that. Cause that was easy. @_@

…Even if it was essentially a tutorial I followed, it was more straightforward than BSP trees.


I feel like there’s a better way to do it. Specifically, with this BSP “tree” division method, usually this thing seems to want to divide the map into long “strips”. Currently I’ve got waht’s up on the site, but it will semi-randomly shrink the room in either dimension by width/3-1. But even with that, the randomness prevents a semi-constant shape–as a result lots of long 20 square corridors shoot down the map in parallel with eachother, and everything still ends up being rather pattern-like and not as random as I’d like.

Another way I’m thinking of now is to pre-split everything into 3×3 grid spaces, and from that it’ll loop over each space and determine whether to make a hallway, a room, or nothing at all. Perhaps it will take 0,0 and, if it chooses a 3×3 room, then it checks the adjacent squares and decides to either make an adjoining room or a connecting hallway. From there it will continually expand out until the entire map gets covered and has a dungeon. But I dont even know if that’s going to appear “too random”, and once again I’ll see a flaw in the design and will then go back into an endless cycle of trying different map generation algorithms. Sigh.


Well at the very least I am going to try and finish a suitable dungeon generation algorithm and use that somehow in a game. The RL tileset could also be interesting, although handmade ones might also work provided I really skimp on animations.

Slimming down as much as possible while still keeping the “go somewhere -> kill stuff -> get xp and loot” idea still ends up turning into something like a Roguelike. = But it’s also not very conducive to a quickly finished project to learn off of.

Working things out in a terminal and then adapting it to pygame has worked decently well for the map algorithms. Why not apply it to stat systems etc? Should also apply ranges to room sizes. The rooms are currently split into sectors, now it has to decide where and how far to shrink the regions into separate rooms. Currently everything looks like a nice grid with even divisions etc.

Monster classes should maybe be rewritten? I looked at the code a while ago but it felt like I had something screwy going on there. Also need a system for determining the order of combat–ie, if 2 monsters enter into the same tile as the player. Ditto for basic collision so they don’t end up on top of eachother. Possibly have tiles have a property of what is on the tile.

Nitpick, but making monster spawns independent of room generation would also be good. Worldmaps: have a list of locations stored away somewhere so that when the playercoords are ontop of there, it jumps into DungeonTest (or impending CityTest or whatever)

Zombies are cool. Left 4 Dead makes me want to do a zombie game. But I’d only make a bad clone of Survival Crisis Z. 😦 Maybe something that generates a large and deep city to play in instead of one big world?