Progress, Episode 2: Lazarus Effect

After a lengthy hiatus (not in a small way caused by my not having a desk), I've begun delving into Urban Crawl again. I've now refamiliarized myself with the code, and in the process I discovered a number of little inconsistencies and deficiencies that I am sure I would not have noticed for a long time had I not neglected this thing for 2 months. I've come across this sort of thing before, and in an attempt to be a massively cool dude I've decided to dub this phenomenon the Lazarus Effect. Because, you know. The project was dead, and now it is not, and it is almost better now for having died. Lazarus. Yup.

I finished up the whole shoreline generation and lake filling algorithm. I know now that my fortmer attempts at space filling were ridiculous and silly and filled with bugs, but I fixed them up and now you can really watch the tildes fly as your very own lake is created LIKE MAGIC. I've begun the generation of rivers, which in all likelihood will consist of boring straight lines of water instead of being all bendy and interesting. After that, my initial terrain generation will be complete and it will be on to roads.


I'm considering taking a short break from city generation to actually complete the interface and display library that I wrote. It's full-featured enough for my current uses, but I get the feeling that once I get deeper into the interesting bits of city generation I'm not going to want to take a break to go write some boring menu code. We'll see. Maybe if I complete the library I can release and become internet famous. Wouldn't that be a treat?

Progress, Episode 1: Maximum Recusion Depth and the Problem of Filling a Lake with Tildes

So I've finally begun writing the city generator. First up is terrain, which for the time being will consist of water features. This will include rivers, and a large body of water like a lake or ocean. Typically large urban centres are built around water features, so I think it's a good place to start. I got a random ocean shoreline generator working first, with a parameter controlling where the water will be located. It makes pretty neat shorelines half the time, I was sort of surprised that it worked so well.

Next up was the simple task of filling the lake with water. The little function I have is recursive, spreading water tile by tile from the appropriate edges. Recursive functions are so fun to write and think about, I've loved the concept ever since it finally clicked for me. Unfortunately though, this led to a little problem I was entirely unaware of: Python has a "recursion limit". Apparently you can't go 1000 deep in a recusion loop without fiddling with scary settings. Gah. So for larger lakes, I was getting crashes galore. Oh noes. Luckily enough a quick little reshuffling and a few extra lines of code fixed that up good. I don't like thinking about optomization as I'm doing things, but I have to admit my first lake filling function was a lapse in good judgement on a couple of counts.


The shoreline generator actually draws out what it is doing as it is doing it, so I finally have something cool to look at. As a result, here's a really unimpressive looking screenshot.

You can enlarge that image bby clicking on it. Things are pretty messy right now, but you can see the generated shoreline there. The water doesn't always hug an edge like that, sometimes almost half the total map will be covered in water. Maybe I'll make it so you can get a boat and be a pirate! Of course, should you not like what the generator gives you, you can tell it to try again. In time you'll be able to explicitly tell it how much water to strive for, shoreline straightness/complxeity, etc.

After polishing up a couple issues and fiddling with some display things, the river generator will be up next. Rivers will probably be pretty straight and unnatural for now, it all depends on how tricksy things will be. I am very much flying by the seat of my pants with this stuff, haha.

Progress, Episode 0

Here's where the technicals come in, and I'll talk about what's done so far. Later progress reports will be sort of a "here is what I did today, here is a screenshot, whatever" sort of thing. So far, we have:

• Display: Current display uses 24 bit colours for foreground/background, can handle both spritesheet and regular fonts for the tiles.
• Interface: Nice interface system set up including classes for windows, multiline text, menus, arbitrary grids (with image-to-grid conversion), etc. plus functions for handling placement and efficient updating of interface elements.
• City: Storing and retreiving generated cities implemented, but this will be reworked pretty soon.
• City Generation: Interface for city generation is partially up and running.
• Other: Main menu is functional, not pretty. Keyboard input works.

The display system was fun to make. As far as I can tell it is efficient enough for my tastes. It never renders anything that hasn't been changed, thanks to a simple isChanged array. The way it handles the colouring of glyphs could be better I think. For example, if the screen has 800 red '~' characters to throw onto the screen, it takes the standard tilde glyph and, pixel by pixel, colours each one red individually as they are blitted. So, consider this a sort of note to self: improve this thing. For now, the system works fine. Maybe once we actually have some more complex stuff to display I'll be able to fix that up.

I tested it by giving it a large 1200x840 window, containing a grid of 100x70 tiles. A big giant loop was run where a random tile's glyph, background colour, and foreground colour were changed to random values, and then I rendered. Repeat 10000 times. Running this way, the thing managed a speed of about 267 tilechanges rendered per second. Okay, so that's not actually that impressive. But if I changed it to rendering after 10 random changes, the speed went up to 2721 per second. 20 changes per render was 3827 per second. 50 changes per render yielded a speed of 7241 per second. So, it seems as if there is some overhead in the render function that isn't actually related to the number of tiles being updated at once. Nevertheless, under this test I was able to achieve render rates of more than 20000 changes per second, easily enough for a turn-based roguelike. With some improvements, you could run really low resolution video through this bad boy I'm willing to bet. That'll be for later though.

The interface system came next. I've designed it to be based around a sort of container system. Interfaces are made up of windows. Each window holds numerous elements. The elements are placed with respect to its window. Under this system, windows can be updated individually when needed, and placing objects is made a bit easier. I've also got a snazzy function for drawing interlocking borders around all the windows. Colours for windows can be controlled, and the colours will filter down and apply to all the elements (text, images, menus, etc.) inside the window. In time, the system will be expanded to allow for the resizing of and moving of windows, keeping everything nice and ordered. It sort of works like DIVs on a website. Things can be relative or absolute, yadda yadda yadda. I haven't fleshed it out entirely yet, but it serves my needs for now.

I'm trying to keep things open and extensible. I'll be the first to admit that I don't know a whole lot about how real programmers do things, but I imagine that I'm on the right track. I don't want to rewrite this thing. Not the whole thing anyways. Adding, enhancing, sure. I'm trying to plan ahead. Hopefully things stay manageable.

Now that I've got a bunch of the boring stuff done, it's on to the city generator. Terrain -> streets -> zoning -> buildings -> groups -> people -> history. That's the order I have planned, although it might change (still npot quite sure when to put history generation). Super-rudimentary versions of steps 1 through 3 will be first on the chopping block, along with a tool for viewing the result. Wish me luck.