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:
Wednesday, May 16, 2018
Tuesday, April 17, 2018
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.
Friday, March 2, 2018
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.
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.
Thursday, February 1, 2018
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.
...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.
Wednesday, December 27, 2017
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.
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.
Sunday, October 1, 2017
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))
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.
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.
Saturday, September 16, 2017
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:
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:
Subscribe to:
Posts (Atom)