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.