Pickledtezcat Game Devblog

It's been a while since I posted here because I'm moving most publicity for this game over to a facebook page. You can see it here . Right now I'm working on buildings, I've done a mock up of some to show the damage progression from pristine to bullet marked to fully destroyed. There are some buildings at the back which are going to be used for a different map type, the "destroyed city" map. I hope to have several different map types, including winter and fall, desert and this one. It will represent later parts of the game where the defenders have fallen back to positions in their cities and are fighting desperate urban warfare. 

I've been working some more on the map window. Right now you can only see the base, it doesn't show items, enemies or even doors on the map yet. These would be decals. In the top window you can see the modified result of last night's tile based map. It looks good but there are some visual artifacts related to the problems I encountered yesterday, and as well it takes much more code and time to calculate. The second window uses a cheap trick to fake an beveled look from a smoothed version of the 32x32 map. It uses black to mask unexplored areas. Finally the third version is meant to look like a had drawn map. I'm using a cross hatching texture to distort it and unexplored areas are shown as blank map paper. There's going to be a mechanic in game where you need to use some paper every level in order to activate the map for that level. From there it will fill it in automatically. Paper will be pretty rare so it might be worth keeping it safe for the more com...

I ran in to some serious problems with Vinland 1936, so I'm shelving it for now and revisiting an earlier project. Kind of. Treasure of the deep dwellers was a 3d team based roguelike. Some ways it diverged from standard roguelikes is that it had multiple player characters (a team of 4), real time game play (not turn based) and it had 3d graphics. Unfortunately it was a bit more than I could handle. The new approach is an attempt to simplify the project so that it can function more like a traditional roguelike. A big problem I had before was keeping track of the 4 agents. They tended to run off or get lost. I had to calculate line of sight and map reveal from all 4 agents. Now I've switched to an "Eye of the Beholder" type setup, where the whole team is contained in a single tile. Likewise monsters are represented in mobs of up to 4 agents in a single tile. Other benefits of this type of gameplay is that you never need to see the player's characters (...

I'm going to leave trees and move on with some other stuff for a while. I think the trees look pretty good and performance is much better than when i was using individual tree sprites. I'm still conflicted about how to handle alpha in the game. Here's a shot of the trees with clip alpha: Clip alpha is basically either/or alpha. Either it's 100% transparent or it's not. It's very fast to render, but it gives pretty horrible edges. Another option is to use alpha sort. This is similar to the alpha blend I use for the infantry sprites (grayscale alpha) but it works to sort the individual polys of the mesh to make sure they get rendered in the right order. Performance is slightly slower than with clip alpha. But the end result looks much, much nicer. Again this may be something I make a part of the graphics settings, as it would be possible to load different trees from file, some with alpha sort and others with alpha clip and lower resolution.

After reading this post on a famous game art tricks blog I decided to have a go at making 2.5d trees. Here's my test trees so far. I think they look pretty good since they are only about 100 triangles each and a single 512x512 texture. I've also used a simple fake volumetric trick with the leaves, using a spherical normal map for each clump to make them shade as if they were 3d. I'm sure I can cut down the number of triangles and do some more tricks with the textures to get them to pop a bit more. The real problem is the clip alpha, that's what makes them look more low rez than they are. EDIT: I added some random noise to the edges of the leaf cluster's alpha and it gives a much more detailed effect:

The current phase of development is taking longer than I'd like because of the difficulty of designing procedural terrain for Real Time Strategy games. In many RTS games water is impassable, this makes bridges very important strategic locations. But the flip side of this is that units that can go through or over water become valuable too. Unfortunately it's not so easy to just let any unit become amphibious. If a unit can go through water it needs different pathfinding, it also needs to know the difference between moving in to water from the shore, and moving in to water from a bridge. Most RTS games are not true 3D. So bridges, though they look like they are raised up above the surface of the water are usually not. Driving your tank over the side of the bridge and in to the water would give some funky results. So I need to mark tiles as water, but also mark bridge tiles. An option would be to add impassible tiles along the edges of the bridge, so you just can't...

This week I did a whole bunch of work on commands, so the AI players can be better guided by the player. I've also added speech above the NPCs so they can respond to your commands and you can get additional info about what you're asking them to do. For example if you ask them to walk, it says "Look out for secret doors and traps!" Which is what walking is for. [You can also see the new doors] Some other improvements: If you push against an NPC (because of being stuck and wanting them to move out of the way) you will send a message to all the other NPCs to increase their distance from the player for a short time. This stops the situation where one NPC further down the line is blocking but is not too close to the player so doesn't know they need to move. You can urge them to attack or follow you. This will set their follow distance and their engagement distance. You can also set this independently for each NPC. You can ask them to wait behind. Again you...

An in depth video this week focusing on tilesets and doors. I'm happy with how they are working right now so I'm going to move on to items and inventory. You can see the video here if it doesn't display.

You can get a look at how the tileset looks in this short video Blog: TILESETS  I'm working on lighting and tile visibility. I'm also about to start work on doors.

It's difficult to show the way tiles look in game with static images, so if you want to see a gif there's one here . It's important that the different textures work well together, the Normal map, the diffuse texture and others have to bring out the 3d effect without overwhelming the viewer with too much detail. Here's an example of a diffuse texture: There's quite a bit of small scale detail, the little plants and things, but the large scale contrast is quite subdued. There's no very dark areas and no very light areas. This is the most difficult thing to get right. As I talked about last year, it's no good having an amazing tile set if you can't see any of the characters or other details. Here's the floor so far: This is just one variation of floor tile. The final version would have several different tiles to choose from when generating the level so it doesn't repeat so much. The look I'm aiming for is a kind of tabletop rolep...

30 minutes later +/- some thinking time and the time it took to write the blog I've got some basic tiles in game for testing. The first thing I noticed about the tiles in game was that the initial texture was too high contrast. The characters and monster disappeared in to the background. So I lightened them up. I also added a quick bit of code to randomly rotate them by multiples of 90 degrees. The final version would include more variants of the tiles, as well as some that can be placed around the edge of a pit. Adding the gravel was pretty painless, and later I can add bloodstains, moss and other stuff to add a bit more interest to the levels. Here's what the tiles look like up close as a group: This was before reducing the diffuse contrast. It looks great, but it is too busy. It becomes difficult to play the game. Not every tile would be cracked in the finished version though and not every one would have gravel or other details. So I have to strike a balance...

It's been a while since I did anything graphical, but I feel the need to see how the game will look once there's more than just cubes as dungeon. I also need to test some of the dungeon building ideas I've had lately. Lastly, I feel that it's important to come up with a fast, and good way of decorating a dungeon. For the last 30 minutes I've been working on a single paving slab. That might not seem like good time management, but I didn't spend the whole 30 minutes making it. I experimented with some quick and dirty ways of modelling stone. First I created a cube, scaled it to a tile (2.0,2.0,0.2), beveled the edges and cut it with the loop cut tool. (Previously I tried the boolean modifier, but that took too long and didn't give good results).  After that I added some subdivision with fractal noise and smoothing. Next I unwrapped a stone texture and used that as a basic displacement map to provide the micro texture. Last I created a low poly tile a...

After some feedback about the game in it's current state, it's obvious that the camera was zoomed out too much and the level textures are too high contrast. That's actually something I've talked about before, when talking about how I was going to rework the tile set textures to be lower contrast. The final tilesets will be quite low contrast and perhaps a little flat and boring, but that was always part of the plan. The background is not supposed to be the star of the show. Take a look at this, it's one of my favorite Korean traditional paintings. The background is just background, the figures stand out, except of course for the two guys hiding behind the rocks. :) The artist has used the plain texture of the paper as an element of the painting, not to be covered up, but to be masked and veiled, being here a tree and there a rock and elsewhere the skin of a bathing woman. I've tried to show a little of how the game would look like with low contrast bac...

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've already talked a bit about how I'm handling the layout of the new tileset, with offset tiles and overlays and different objects for walls and floors etc... In this post I want to talk a bit about how I make the textures, and what I've learned from the first (partially successful) generation of tilesets. Experiments with using different lighting for tiles and characters. If I wanted I could continue to make the game using the old style of tilesets, they're not that bad, but they just don't satisfy me. I know they could be much better and I've learned a lot in the last 2 years that I'd like to include in a revision of the tilesets. Some of the things I want to consider when making the new tilesets are: Don't make doorways "covered", the doorway area should be open to the sky, otherwise it's difficult to arrange your characters in a doorway, somewhere where combat is very likely to take place. In the MKI tilesets I made the door...

I've been working on adding some new tile types, and redesigning some old ones. I've moved stairs up and down from door type tiles to overlay tiles. As I explained in an earlier post, overlay tiles types can be placed on exiting tile types, inheriting some of the qualities of that tile. A more detailed prefab. With descriptions. Some of the tile types have been successful, while others I'm not happy with.  I wanted to add rounded corners to some rooms, but the result, because of the way the code works, just doesn't satisfy. I'll be dropping them for now, perhaps including them as the base wall type in another tileset. On the other hand, details and decorations are just what I was hoping for. Details can be added to either the floor or a pit. They don't affect movement, and can be used to represent non blocking visual details, such as small pieces of trash, rugs, blood splashes, slime trails, spider's webs etc... on floors. On pits they can be ...

If you're making a game in 3d there are a number of ways to handle tilesets and tiles. The easiest but least flexible is to handle each single tile as a tile and just place them with no regard for the adjacent tiles. Walls in this case are made of 1x1 pillars of wall material. This is great, but it doesn't allow for very varied tile sets. It also leads to very repetitive, bland looking dungeons. You could make things a little more random by using multiple kinds of wall and floor tiles, randomly placed, or use an algorithm when placing them. Here's a look at Eye of the beholder on the gameboy advance which uses that method, though it's actually 2d isometric, not 3d: Very blocky tiles. Another method is to use tiles which are bigger than 1x1. In the case of my first attempts, I used a 10x10 tileset. This allows some very interesting shaped rooms such as circles and some kinds of irregular tiles such as caves. We could call these prefabs or kits. My first ...

I recently found a bottleneck that was causing some slowdown in the game. I've been using a single flexible rig for humanoids which incorporates 2 arms, 2 legs (with extra back cantered versions), a tail, two possible head locations, hair, antennas, a cape, weapons hooks including animated bow, a helmet hook so helmets can be removed during a cut scene or special animation if needed as well as wings. This is a very flexible rig, but it has a problem. Multiple inverse kinematics solvers, multiple copy rotation and location constraints and lots of redundant bones when used for most types of agent. For example bird men have wings and back cantered legs and use the lower head bones, but they don't use hair or capes. One the other hand humans use hair and capes, but not wings or tails. The humanoid armature. With all those extra bones and constraints to calculate, animation time was double what it should be. Once you start adding a lot of enemies to the scene (more than 4) ...

I need some advice on which is the best way to handle building the dungeon. Right now I'm using prefabs for my dungeon, they have a north south east and west section for each "room": The basic tileset. This has several advantages, and also several disadvantages. Firstly I can have curved rooms, I can have tunnels and other interesting shapes. The tilesets can look quite nice with a little work. On the other hand I can't easily get the navigation data before building the map and once the map has been built I can't make changes to the layout, like having active pit traps or believable secret doors. Although the rooms are interesting, they are quite repetitive, and it takes a lot of effort to make even a few different variations. Also rooms are constrained to one size. A newer version of the tileset with a lot of variant parts for making more interesting rooms. To create a tile set is a real headache too. Planning how to lay out the UVs, trying to cra...