Pickledtezcat Game Devblog

Progress  as of this afternoon. Some areas are still not being linked. I'll have to take another look at the linking algorithm. There's also something funky going on with the tunneling algorithm. In some cases it seems to be going a few squares in the wrong direction before doubling back. I think I left out a stage in the old A* script that I used, I'll have to switch it with the more developed (but more complicated) one I was using for movement in the main game. Anyway, today I want to talk a bit about dungeons. What does a dungeon look like? I've chosen perhaps a rather strange style of dungeon, with small packed areas linked by winding corridors. You don't need me to show you a roguelike dungeon from times past but here it is anyway: Long corridors and rooms. Nothing special. other roguelikes from more recent times have used different types of dungeon generation. Often a theme is to try to pack in more rooms in to the smallest space to get the most ...

That's it for today, and maybe for a few days. I hate programming right now. Just spent nearly an hour bug hunting only to find that a variable that should have been y was x. Even though I'd checked it twice already and just didn't see it. Need to stop and get some sleep. :) Anyway, made some progress in linking level hooks, and putting in corridors. Needs a little more work, have to find out why it's placing corridors in incompatible spaces. I though I'd already dealt with that problem... Also need to leave a border on the BSP tree to allow for corridors to go around the edge of the map. I shifted the prefabs in to the middle of the BSP leaf and it already looks better. Worked a little on the random chooser for prefabs so it now chooses a larger range of better fitting prefabs. Here's tonight's progress: I used a simple draw line to check room connectivity before working on the tunneler. That allowed me to work on connectivity without having ...

Actually it's more like MK32 but as it's the second attempt at a working level builder I'll just stick with that. Right now I've got a partially working version of the new level builder using the new prefabs. I'm glad I only made a few prefabs for testing as seeing them placed in the level has made me think a lot more about prefab design. The level builder uses a simple BSP tree to designate areas of the map to contain prefabs. The it picks the best fit prefabs for that area. I choose a few and then randomly select one, I don't want to always use only the best fit as that will leave some prefabs unused and as such, wasted. Here's a couple of examples with the BSP areas highlighted with different colors. There was a bug with these where it was in some cases choosing the smallest room instead of one of the biggest, but that's been corrected. One thing that jumps out at me about the prefabs is that they need more big and medium sized rooms...

I went back and did some proper textures for the orcs. They didn't look right walking around in armor which had the player character's textures. Humans can't wear orc armor and I want that to be visually obvious. I also felt I could do more with the orcs as a potential future antagonist so I didn't want them to be too generic. I also spent a lot of time today making a short helper utility for painting walkable tiles on a tileset. It doesn't take long and they are saved to disk ready to be used by the level builder. When I want to use different layouts or styles in future tilesets I can simply use the script to paint walkable tiles directly on to the tileset pieces. Here you can see the first tileset being painted. I'd like to be able to show every walkable node as it's placed but there is some slow down associated with adding all those visual guides and it makes painting much slower and more difficult. The end result of this is I can make a basic wa...

I came across an interesting book in the school Library at work yesterday. It was a copy of the Hobbit translated in to Korean. In the introduction it showed some amazing illustrations from different versions of the book from around the world. Look at these different versions of the book to see what I mean. It made me think about how I want to depict monsters in my game. I had been avoiding adding Orcs to the game because I didn't want to go with the D&D style orcs, or the green skinned Warhammer or World of Warcraft Orks. I wanted something a bit different. My game world is set perhaps half a million years in to the future. Mankind had screwed up the climate and nearly exterminated themselves. But some humans managed to cryogenically freeze them selves in crypts buried deep underground. Others underwent experimental gene therapy to create human animal hybrids who could survive the harsh environment of this post apocalyptic Earth. These creatures multiplied and mutated...

Going back and making some tweaks to the lighting set up I found I can get a similar result from the classic graphics mode as I can from the more modern style. Per vertex lighting. Can you tell the two modes apart? I can, there is definitely a better quality to the per-pixel lighting, nicer shading, better shading of unlit portions of models, better handling of normals etc... but not enough of an improvement to justify the switch maybe. Per pixel lighting. Per pixel lighting does have some other benefits, such as better materials handling (I can dynamically mix two texture on a single object using a mask) which can give a much better appearance to tilesets. It can also do dynamic shadows, reflective surfaces, normal maps and a whole raft of other stuff. But... I don't intend to use any of those features right now. The game is supposed to run on low end computers, I've chosen to use very low detailed art assets to help with that. Putting a normal map on a very low po...

Another roguelike developer who blogs as VJOinteractive commented on my last blog about the lighting system. Actually lighting is a problem with the blender game engine, because it can have a maximum of 8 light sources. That means either having a single light source and modulating it to take in to account the number of lights in the main viewport (Simple lighting), or using up to 8 lights and moving them around as the camera view moves (dynamic lighting). Dynamic lighting is my preferred option, but it's not easy to represent a single torch with a single light in an isometric view. If I place the light at the location of the torch the top of the walls and anything above the player is not lit. If I place it too high up, the lighting on the character looks wrong. There's also the fact that I'm using an old fashioned graphics mode, per vertex lighting. It's really fast and it'll run on almost any computer, even one with a crappy integrated graphics card. But the l...