Currently, working on merging the city/site generation into the main game, from the sub-program "CityScape" which I did much of the work on.  Right now, I've got most of the biome/maps working like I want.  For example, the swamp:

...and also sections of highway that you can see from the overland (but doesn't already have a site associated with it)

 So... most of the progress at this point has been on non-coding items, including a lot of the ASCII art.  Now all the various ruins and such have biome-appropriate art.

Well, that's not quite how the color cycling effect was supposed to go, but at least now I have more of a load screen.

Up and Down

After importing the updated maps generated, I went ahead and updated both automatic Z traversal (ramps) and queried Z traversal (stairs):

I'm going to really need to change some of the tiles, for example, when you're up on the highway, it's barely visible that you're not still on ground level.  Either that, or greatly increase the darkening of terrain below you.

Anyway, time to clean up the interface a bit so it looks more like an actual game, then move on to implementing inventory, creates, etc.

Back from a long break

Such are the hazards of single-developer projects. 

In any event, I more or less have rivers where I want them, in terms of water falls, multi-level canyons and river valleys, etc:

Now I need to plug it in the main program and work on up/down movement, and we should be largely ready to move on to more of the world building/quest part of the game.

Avoiding 3rd Party Bugs

So.. one of the recurrent issues, and one I may have mentioned in passing was the game's tendency to throw SystemAccessViolations, particularly when I was trying to do anything with changing the Direct2D brushes (which was a bit of an issue, since I was creating new brushes every time the screen changed.)  This wasn't as noticeable on high-end machines, but particularly on old, slower machines, the game crashed a lot.

As that particular violation is an unmanaged code violation (i.e. not something C# can generate) I couldn't really go deal with the problem directly (I guess it's something in the SharpDX code)  However, I got around it by just keeping a collection of brushes (Since I'm only altering the color) and only creating brushes if a combination doesn't match existing brushes.

This appears to have completely eliminated the problem, or at least made it very rare.  While there's nothing quite as infuriating as the very rare crash, at least in that case I should be able to emergency save to prevent the player from losing progress (as only the rendering is corrupt, at that point.)

No illustrative GIF on this one, the rendered result is the same as before (although faster on older computers)

Better Rivers

Well, River generation looks more natural now, but I'm still not terribly happy with it:

Even with some randomness, it's still way too clearly a sin-wave... which river systems frequently are in nature, just not that uniform.

Adjusted the rendering frame rate downward to see if that helped with flickering issues, and it did... a bit (and didn't hurt anything) but I think that issue still needs further work:

Terrain generation and Z levels

So, for the moment, the level builder is an external program, which makes some aspects of it easier to debug.  As I'd left off the main program for a bit to go build levels with a bit more Z interaction, I managed that relatively quickly:

The colored zone edges you're seeing as I pan up are the up-down ramps, where they are absent you're seeing more than 1 z level of separation, so essentially a cliff.

Technically I could go back to the main program and finish testing movement up Z levels, but there's still a bit of work to do with level generation, in terms of making more realistic terrain and some non-ruined cities, so that'll be next.

LoS the conclusion

So I enabled the tile hiding for unexplored zones, made a few more modifications (buildings and such were changed to bright red, so the out of sight areas being gray was a bit more noticeable)

At this point, I need to add Z-axis navigation (stairs, where it asks you to ascend, ramps where it automatically does so) but I'll come back to that.  For now, I'm going over to the separate test-bed program for level generation, to finish out the initial generation of all the terrain boards.  Once we have some levels that are more organically 3D, I'll finish up the last of the navigation.

Line of Sight

With the pathfinding working, it shouldn't have been too much effort to implement some player line of sight... and indeed it wasn't.  Per usual, I'd say about 70% of the time required was due to dumb mistakes.

I does have a bit of artifacting around the corners caused by allowing for diagonal circle circumference points.  I'm not sure, given the larger sight distance I plan on using, that I'll do anything further with that.

Hidden/discovered terrain also works, although it's turned off for the above demo.  It does need to allow for the first view-blocking terrain to be discovered, though.

Now I have to decide whether I want to tackle the rest of map building, or try and flesh out the user interface a bit more to look like the eventual game product.

Z Axis

So, in order to represent a ruined, post-apocalyptic city, you need properly generated vertical maps, I'd argue.  I already had the generation part done some time ago (although it has a bug with doors past the first floor, as you may glimpse in the below GIF)

However, I don't plan to have inter-level interactions.  Although it might be realistic to have someone sniping at you from the second floor, it'd be frustrating from a game play perspective, as you don't have a true 3D view.  As demonstrated below, what I've done is made air transparent, and had lower tiles darken as they are further below you in Z levels.

After a bit of moving around, I move the camera up through the Z levels, and then down underground, below:

A month without updates

Real life got... significantly in the way of doing much, but I did change how the camera, such as it is, tracks the player.  Instead of adjusting to always keep the player in the center, now it only moves when it needs to.  Given that this isn't an action game, I think this probably is how it needs to be.

Dangerous Tangents

So.. I wasted an inordinate amount of time trying to add an animation capture feature to show the path-finding success.  To briefly incapsulate:

You can use the WIC Library via it's SharpDX wrapper to capture output, but only after you had quite the hand-off of devices, from your Direct3D device, to a DXGI device, to finally a Direct2D device.  Only once I got there did I realize that WIC doesn't fully implement the GIF standard, meaning you can save a bunch of frames to the GIF, but they won't be animated.

Anyway, long story short, ScreenToGif is free and works great.  It pretty much did exactly what I wanted:

...which is show off the path-find movement.  It also shows off that I probably have some implementation problems that you can see in the GIF, with wonky colors in some frames.  That's likely because the thread timer for animation isn't in any way synced with rendering thread. 

I also got font loading to work, which took me down an interesting path regarding font licenses.  Fortunately, Consolas, which is used for all the tiles, is bundled with Windows, and Neurpol, the title font, is free to use.

Pathfinding Success

Well, that took a little longer than it should have, mostly because real life interfered with coding.  So, direct line drawing of paths:

...and then, pathfinding paths, based on the movement cost of individual terrain:

I'll still need to work a little bit on some edge cases that'll result from truly impassible terrain, since I'm taking a mini-map approach to it, rather than pathfinding on the (prohibitively large) entire map.  Also, I might offload it to another thread if it seems to be an issue, but so far, the computational cost seems pretty reasonable.

Pathfinding

So... I've already done Dijkstra's pathfinding algorithm for other things, so it wasn't (supposed) to be a huge deal to port it over to the game, but like many things, plans didn't really survive contact with the enemy.

Basically, while that kind of pathfinding works nicely for small grids, when you're dealing with 500x500 boards, you're not going to be practically able to pathfind from one side to the other.  So I wrote a version to take a subset of the board and pathfind that, with the idea of stringing them together or using a node-like approach.

However, this turned out to be somewhat impractical to test in the game itself, even in the very simple form it is now, so I had to build a stub program to debug the pathfinding object:

Anyway, I think I've tracked down the major error (which had to do with expecting the coordinates passed in manner they weren't.)  I'm probably going to do a bit more research before I decide on a larger solution to the matter, though.

Map Generation

To be honest, this whole project started off from playing/dabbling with roguelike map generation, and thinking "you could make a much more organic looking random map."  I'd say one of the more interesting recent takes on the matter is Diablo 3, which, while not really a roguelike, does do some neat level construction, in terms of stringing together good looking 3D set pieces in a random manner.

So, the whole project started out as generating ruined cities, and spiraled from there:

Our city has a number of buildings, in various stages of ruination, as well as roads and highway overpasses, and a river in this case.  Besides just building placement, the interiors of the buildings are constructed so that doors and rooms link up within them, as well as stairwells.  Although this example doesn't show it well, the highway has fallen sections which can be used to climb into the second level, and will have exit ramps linking it with ground level roads at appropriate places.

A close-up of the room generation (where cyan pixels are doors, and red is a shaft/up staircase)

Going vertically up a level, we see higher levels of selected buildings, as well as the overpass (orange squares are reserved spaces for special buildings (i.e. non-random map pieces that can be added))

Below ground, we have a drainage network linked to both building basements, and surface drains to the street.

Lastly, just an example of a different random city.  Speed is pretty acceptable on a modern computer, particularly if you offload generation to another thread, although item/person population would still have to be done at this point.

Ascii Art

So, I recently finished the ascii art editor for this project, EditAscii, which I'm going to use for certain events/locations, to do some rough ascii art for the game.

Here's a few screenshots.  First, showing what's actually in game (we're still pre-alpha here,) most of the overworld generation is done (placement of terrain, sites, etc)

...and here's what an overlay would look like, when you come upon a ruined city or something like that:

Background Work

Most games require at least a little background/support work that doesn't involve the primary application.  In particular, for this game, I wanted to a title screen and some vignettes of various encounters you have in the world, and places you go to.  However, I don't have any real talent at composing ascii art, which is something of rare talent to begin with.

So, I made two companion programs to help me with the task, AsciiConvert, which is already at 1.0, to create the ascii art from line drawings; And for further processing, AsciiEdit (Yeah, I'm not wonderful with application names) which is currently a work in progress:

Finishing those is kind of where my efforts are focused at the moment.  For my next post, I'll probably talk about some of the work already mostly done, which deals with level generation.

Let's kick this off

So... let's kick this off.  This blog is dedicated to the development of a Sci-fi Roguelike entitled "Damnatio Memoriae."  The general theme is post-apocalyptic, with an apocalypse brought on by genetic engineering gone out of control.  The core development themes, I felt, were creating a procedural world and quest line that made gameplay significantly non-unique each game, from start to finish; coupled with detailed, procedurally generated cities and ruins.

Most of the work done to date has concentrated on those two goals, and a result, the state of the game is more a shell than an actual game.  I'll post more about that in future days.

Just a few general development details:

Developed in Visual Studio C#
Uses a virtual text mode based on SlimDX