Pickledtezcat Game Devblog

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...

You can see the latest updates here: Click the image for the Development Diary video. Physical representation of agents has been added along with animations. Lots of bugs fixed with AI and generally improved speed and reliability of pathfinding.

Yesterday was headache day, so no development. Today was coding day. Found a big BUG! I've been using a dictionary to contain my navigation data, that's to remove the need to recalculate the graph after every run of A*. I just made a deep copy of the original dictionary. I was deep copying the dictionary, then cropping the new dictionary to a bounding box around the start and finish points, by reducing the size of the graph it makes A* run faster. Unfortunately deep copy, or even dict.copy() are very slow operations. So while a long distance calculation of A* was taking 0.012 seconds, the deep copy operation was taking 0.12 seconds! 10 times slower than the A* function. A big drain on resources indeed. (nearly half a second for just six enemies!) So I started by rewriting the cropping function. Now it crops data out of the original dictionary, copying entries and appending them to a new dictionary. Because it only copies entries inside the bounding area this...

It may seem like the monsters I've been making are pretty undetailed, even old fashioned compared to more modern games, but I'm going for a certain look with the game, and the smaller characters allow me to get more on screen at once. Even a big creature like the stone troll will be pretty small on screen, so the low poly and small texture sheet approach is just right for the game. Here's a picture of a couple of trolls at around real screen size: You can zoom in a bit in game, and when they are animated you can see more of the details, but generally it's not that important to see every single tooth, or individual eyeballs, even with a character like this. I'm trying to create a look which is reminiscent of the old 2d RPGs, kind of like  3d pixel art. (similar to this) Why? Because I'm working on my own, and I need to choose a simplified art style just to make sure I can make the required amount of assets in a reasonable amount of time. A g...

I did some work on particle systems earlier this month, and today I tried out coding some 2D GLSL filters. The effect I wanted was a kind of localized distortion. Initially I wanted it for spell effects, but the required set up is too cumbersome and would require multiple layers of filters for different spell effects. In the end I decided it would make a good effect for representing monsters with magical radiation. In the game world, magic is pretty dangerous stuff. You can get irradiated by using it, and it drains your focus, dropping you in to a coma or even death if you receive a lethal dose. There are some monsters though who are suffused with magic. These will be dangerous opponents as they are effectively radioactive. I think it's a fun game mechanic for making bosses more interesting. I can think of a number of ways it can be used to make things interesting tactically. And it could also be used as a kind of environmental hazard. It could be good for dynamic p...

Some new monster designs today, I'm really happy with the texture painting workflow I've ended up with. I'd really like to be able to make more high poly creatures, but the more detail in an animated character in game, the more processing power it requires. Static objects run OK even when quite high poly, but for creatures and other animated objects, they present a bit of a bottleneck. I've already got a whole bunch of monsters, and I've tried to reuse armatures as much as possible, because not only does it reduce time spent on re-rigging the meshes, but also requires less time to animate. However, the monsters that I do have are quite diverse, maybe a bit too much so. The different levels of the dungeon are going to look like a zoo at this rate. So I've been thinking about how to create themes for different levels of the dungeon. In effect, take one monster and build a family of monsters around it. I already have two kinds of plant men, diseased and healt...

From now on I hope to set a routine of releasing short video updates on progress. I've pushed through the pathfinding and most of the movement AI programming. I'm pretty comfortable with how the agents are working out. I made some changes to the A star algorithm to make it faster and generate better routes. It's now possible to add props to the game, they block movement and can be moused over for some feedback about what they are, but they can't contain anything yet. I think I should probably work on the inventory and item system next. Once a player can pick things up and equip them we can get started on prototyping combat. Stats will stay rigid at first, levels and skills will come later. Click the image for a link to the video blog. I also did some work on my 3d design work flow. I had been baking textures on to my characters and then touching them up in the GIMP, but I learned a bit about projection painting and after trying it I found it's a good fit fo...

I first read this article on Dijkstra Maps quite a while ago, and discounted it because it seemed that running a recursive formula like that every turn would be too heavy for my game to handle. However after testing, it worked out to be much faster than a similar process I had developed, and with better results. Only goes to show, don't discount any technique until you've tried it. Yellow is safe, black is danger. However, I couldn't get the same results that the author talked about, by multiplying the output by -1.2 if anything the agents seemed to get stuck in the corners even more. By inverting the results it gets a nice pathfinding technique, though it'll take more testing of that to see how it compares with what I'm already doing.

Click the image for a video of current navigation and AI progress.