Pickledtezcat Game Devblog

In a video game, what is real? This is, strangely, a question that infects many discussions about making games, much more so that those about playing games. Well, some things can be modeled somewhat realistically; ray tracing, shadow casting, physics, real time reflections, on the fly destructible or deformable terrain, goal orientated action planning AI... These are all "realistic" approaches" to making games, or you might say simulation based approaches. Other times people use tricks; pre-baked lighting, animated pseudo-physics, on-rails movement, scripted AI, matcap reflections... These are all cheats, to save development time and processing power. They don't simulate real word physics or behavior but simply try to mimic the results. Players of games are rarely concerned with with such things. Everyone who plays a game knows deep down that it is not real, and they don't expect it to behave realistically. Sometimes they get annoyed with games which show b...

Things are moving along well, there's been a lot of progress on the action manager side of things. Actions have finally moved to the UI, so you can initiate actions by clicking the appropriate button. I've set up some dummy actions to show what happens visually when actions are taken, but the actual dice rolls and such are yet to be integrated. The UI objects are also being added, though some are non functional or empty at the moment. Click on the image to see this week's development video. Every time I add something big I also add about a dozen small things. Like the selection box visualization. Previously this was using render.drawline, and old fashioned Blender function which can be impossible to see at certain resolutions, or at certain frequencies. I replaced it with a function that adds planes of the right size and scale in the right location. I also made all characters a little bigger. I still need to do some work with vectors and final target locations t...

I've been doing some coding, nothing to show right now, but it's essential stuff. You know, the stuff that doesn't show up right away in game, but lays the ground work for actually being able to do stuff like attack and pick things up... As part of that I'm still working towards a working concept for the UI. There's the portrait (1) which tells you which character this is. Next (2) is the stats. Simple outline here, you can get more info by clicking on the portrait, but here you can see health, focus, fatigue and experience. Here (3) is the action buttons. These are contextual and change depending on character or target situations. The target window (4) is an important one. this could be a monster, or it could be some gear on the floor, or a door or another player. You can click here to get more info about it. The available actions will change depending on the type of target. Because you can have multiple characters selected at any one time, I need a way ...

Click the clock to watch Video devblog number 6... Next up I'm going to do a basic hand to hand combat setup to test my combat and stat system. I want a system which allows combat between groups of quite a range of abilities. A group of weak players should be able to take on a single strong enemy. And likewise a large group of weak enemies should be a danger to even a strong player party. I also want there to be an incentive for using different kinds of weapons for different situations. What's the point in getting lots of loot if half of it is worthless? Hopefully some robust testing of the system should see whether it's a good system, and more importantly if it is fun or not.

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.

I took some time away from the project for the last few months. I've been investigating some different things that I wanted to get in to the game, but they needed a lot of experimentation to find the best configuration. I also toyed with the idea of spinning off a new, less complex project but didn't quite go through with it. I've got a couple of things which are ready for further development if I ever decide to focus on them though. The first thing I did was to investigate non grid based movement. I know it's a step away from hard core roguelikes, but as well as being faster than grid based movement, it's easier to manage. The experiment was for a RTS game, but most of what I made can easily be reused in the RPG.  I also spent some time working on particle effects and time control. I briefly entertained the idea of making the game a real time RPG with the ability to slow down time or stop it altogether to aid with strategy. In the end I'll only b...

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

I added some limbs to the fur cloaks and made a wolf cloak. Now you can be Fred the Dread from the N00b comic . If you've never read the n00b I recommend checking it out. It's an awesome commentary on RPGs and MMORPGs. I sometimes think about going back and redoing the player character models and textures. it's a problem that when you work on a project for a long time that older stuff starts to look bad. Anyway, I think I'd better just keep going with the development, and slate character upgrades for a future version of the game. if I spend anymore time revisiting stuff I've already done then it'll stretch development out even more, and then something else will have to be redone.