Map generation #4.5 – tidying up some ends

In my last post about this map-making process, I seemed to have left off at the part where the image itself is generated in its own separate program. Converting this image into a matrix for use in Graff was relatively straightforward. Pygame’s surfarray module allows one to access a surface (the screen) and treat it as a matrix of color values. From there I pulled out the color, used a dict datatype to convert that color into a tile type, and then write that into a matrix for use with the Graff; that wasn’t much of a problem.

However, one glitch I’ve noticed is that often the map would have some holes in it–it seemed like the algorithm would skip over a tile, perhaps because it couldn’t find a properly-fitting tile, so sometimes you get things that looked like this:

glitchy tiles

As it turns out, that was the case. I simply did not make enough tiles to cover each possible combination. After thinking that I’d have to make a mind-boggling number of additions to the 6×6 tile pieces I already have, I edited the code so that if the tile it needed could not be found, it should spit out that key combination and then I’d see where that would take me. Altogether, only about 30 “impossible” combinations of tiles ever seemed to come up, so I just added those extra ones onto the tileset.

After doing that, the results are much cleaner. Some glitches still remain (mainly I missed a few combinations, it seems), and I’ll probably adapt this to work with a smaller scale (say 3×3 instead of 6×6) or make changes to it to develop other areas, but I think I’ve just about exhausted the usefulness of posting about this process.

Still a little glitchy, but better!

Oh, there is also the problem of the map not always being one complete piece. I still haven’t decided in what way I’ll solve that one yet, but there are some more interesting questions about Graff that I think I need to find an answer to first.


Brief update.

Got some feedback on how the player movement worked and so I decided to switch it to the original idea I had–when the player gets too close to the bounds of the screen, then the screen recenters itself on the player, as opposed to re-centering every single time the player moves. Likewise the grass is now drawn so that it looks “attached” to the tile, instead of before where the grass appeared to just float under the screen like an odd parallax effect (see image; night sky is what the grass looked like if anyone hasnt tried out this thing).

Also, I’ve worked in the map generator into the game itself. It looks a bit weird, to be sure:
ingame map generator
But I feel like currently that’s due to tileset issues and not necessarily the code. Don’t mind the odd looking minimap, still have a few kinks to work out.

Also, now I’ve got a way to output screenshots (properly labelled to boot) into a ‘screenshots’ directory when you press the printscreen key. Saves time when I’m on Windows, thats for sure.

Buildings, part three: ingame.

Now actually in the game!

Now actually in the game!

I’ve significantly trimmed up my file after storing entity data into a separate text file and reading it from there, by removing a lot of now-redundant “if entity is a monster: set stats, else if stairs: set foo, else if..” code, and in the process removed a few useless parameters and cleaned up entity creation code to a simple “creature = Entity(dict[“name/type”])” call. Next up is adding some more item types.

But staring longingly at the picture in the previous post made me want to put it in the game, so I did that too, partly to see how hard putting hand-made structures in a map is. Doing it by hand (defining a hard-coded numpy array, and merging it in and defining building boundaries etc so it plays nice with my algorithms) is simple enough, but if I plan on adding more handmade pieces, making it do that automatically will probably save time. Shouldn’t be an problem.

Towns and Buildings, Part Two.

Hypothetical building

Hypothetical building

The above is just a mockup created in GIMP of a hypothetical building. Did some looking, and hand-digital-painting buildings wouldn’t be worth the effort. However, I think tiles might just work fine for making unique buildings. In making the above I sort of went about it as if I were trying to make it algorithmically–mapping out hallway/room intersections, then floodfilling in some tiles to see what the result would look like, and well, it may not be “City built out of ancient husks of crab people,” the final result definitely doesn’t look like a bland old rectangle, that’s for sure.

Back to Morrowind/Oblivion, from my time playing with its built-in Construction Set I do know that their levels and such are all designed in terms of building blocks: t-junctions, 4-way junctions, corners, short hallways, long hallways, etc. Perhaps that idea could be utilized, in that not only are tiles the building blocks of a structure, so are “prefabs” defined in some external file as arrays. Then building styles could be applied at map generation that have weighted choices, so that style A has a higher chance of generating winding roads with clustered buildings intermittently, while style B has one or two monstrous interconnected structures that sprawls across the entire 70×70 grid, for example.

What is in a town + what’s planned.

First, I’m planning on getting a more coherent item system going, adding in a healing potion thing, and fleshing out the GUI a little before throwing up what I’ve got onto the other site for download.  Once that’s complete, it’s time to try my hand at NPCs/shops of some form, and possibly get a spell system working with targeting, and try to redo the town generation system.

Maps have been on my mind lately for some reason.  Sure it’s easy enough to come up with another dungeon algorithm, or even a wilderness one, and add it into the game in a way that makes sense–hit the border of the town, load a wilderness map; hit stairs down, load the next dungeon algorithm, or what have you.

What I’ve been thinking about though, is how exactly to make towns seem different from eachother.  The ultimate function of the “town level” in a Roguelike is for shops (loot), quests, and possible random scenarios (IE: coming across a tavern brawl, then segue that into a quest), all of which are simple enough in theory. It’s at this point where I’ll admit that I don’t really play Roguelikes all that often so I dont have experience with how others have done it, but what I can find off the net seems to show that there isn’t that much interest in how to algorithmically create a unique ‘town level’ in RL’s. There don’t seem to be many articles on the subject in RogueBasin (beyond a simple “take an area and fill it with rectangles + a door” advice on one dev FAQ), and some RLs like Nethack don’t even feature an overworld. Some others use hardcoded maps of 3-5 buildings and use those for settlements.

What it feels like to me is that for algorithmically making a unique town, it’s just a matter of combining differences to make uniqueness–have city A use brown wooden walls, a simple fence for a border, “peasant” sprites, small to medium sized rooms, while city B has stone gates, a wider mix of npc sprites, and larger buildings, and maybe a river running through it.

Still, something like that doesn’t feel significant enough, and I almost want to say it’s the nature of a Roguelike that does that, as things run on a grid. If you look at the towns in say, Morrowind (as I’ve been playing that recently, heh), those are all different. You’ve got the mud-brick adobe city that has the river cutting down the middle of it, the capital city broken into rectangular boxes (cantons, I think they were called?), you’ve got a nomadic settlement filled with yurts, as well as the traditional imperial forts, that one place whose buildings are made out of ancient giant crab shells… It’s like every city has a completely different architecture with uneven/winding paths, which isn’t something that can be easily shown on a system that works in terms of squares on a grid.

I’m probably going to be thinking about this some more. One solution would be to include more building shapes–circles, pentagons, and so on, as well as intersections between them. Another option could be to just rebuild how I’ve made the maps–replace each building with a handmade sprite, even though that could take a while, for example.

Don’t forget to check out the front page for the latest!

When bored, make tiles.

New tilesets

Or try, anyway. Nothing really noteworthy about this as it’s just a few tiles, but I can comment that making a 32×32 square with enough details to clearly show what it is you’re looking at AND making it fit within a visual style is difficult, and I’m not fully certain I even accomplished this with these tiles.

Now one easy way to cheat that is to make more tiles. Case in point, the grass. There’s really a 3×3 grid of 32×32 sized tiles being blitted repeatedly, and it essentially works by giving each tile a value of 0-8 and translating that number into an XY offset of where to pick up the rest of the pattern, and then when it blits said tile, before it does that it checks to see if it’s supposed to do that–ie, don’t offset when it’s a wall or floor or what have you.

Other thing is that I’m no longer using that 1.2MB png to load up all 8-9 pictures and instead am using a sheet that has only the ones I’m using on it. Yay.