Pickledtezcat Game Devblog

Today I was reading Blender Artist's Game Engine Forum when I came across a post about very high logic overheads. Of course slow game performance is a real problem with a lot of indie games, and low frame rate can easily be enough to turn someone off your game before they even really get started. It's an important issue for indie game-devs and hobbyists alike. [LAG=game over] So I decided to write a blog post about it. First of all I should point out there are lots of areas of overhead in a game. One area that often causes lag is graphics, a game engine like Blender is still using quite old methods of rendering and lighting so you can't expect too much from it. There are easy ways to reduce rasterizer overhead which I think I've talked about before many times over at Blender Artists. The problem the BA poster was having though was specifically with Logic, i.e python scripting and the Game engine logic bricks. With games developed by hobbyists it's comm...

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

I've been working on the AI for the game the last couple of days. [Don't worry, every thing is OK...] In my smaller games AI was pretty simple. They had a simple game mechanic, try to walk in to the player and kill them. So basically they have a single type of behavior. [I'll eat your brains!] That's fine for simple enemies like zombies, but what about more complex characters? Well, I've written a couple of different behaviors, we could call them: roaming seeking fleeing fighting following waiting [while: guarding] The behaviors are encompassed in a finite state machine. Each state can transition in to others, depending on the behavior. So a waiting agent sees an enemy they become alerted and try to attack, they transition to the seeking state. After testing I'm confident I've got the bugs out of each of them. But there's a problem. How to choose which behavior to use at any one time? How to know which state to enter next? ...

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

I spent some time today optimizing and modularizing the script I've been using to prepare it for having more than one player character. I also moved the mini map to an overlay scene. Finally I started doing some tests on LOS. Originally I had thought of using raycasting LOS, as this is a 3d game, I may as well take advantage of the power of a modern PC right? But after some consideration I'll be using the Bresenham line drawing algorithm to check for line of sight in the game and I've also been thinking of how I can use it in path finding. It is rather a nice algorithm and the worst part about it I can see is that it sometimes draws rather ugly lines when they veer near to the vertical or horizontal. Here's an example of the LOS in game: It's just an illustration of course so in the final game there won't be any indicators, the slime will just not be visible to the player. the beauty of using this implementation is that I don't have to do any r...

Yes, that's the stage I'm at now. However, I do have a functioning level generator going, as well as most of the art assets I'm going to need for the game, so I think I'm in a really good position to move forward. I can't decide whether to make the movement arrows affected by light. It looks better I think when they fade out on dark levels, I don't want too many bright UI elements in the game, I'm going for that 90's dull and dark look. There are different arrow icons depending on whether the movement would require walking or running by the player. If you run you can't do any other actions such as drinking a potion, but you can do combat. I've also made some stand in icons for pick up, fight, read and other actions, until I can get someone to do some 2d design work for the game. Here's a video of today's progress: If you are interested in technical details, I can say that the mouse position is detected on the floor, and the...

Today I was working on the A* pathfinding script for the player. I hit upon an idea for speeding up the calculations. I used a simple script I'd earlier written as a rectangle border select for selecting multiple units in another game and used it to draw a rectangle around  the player and the target. The graph that's generated for the A* pathfinder is limited to this rectangle (plus a 10 square border, about the size of a single room). This greatly reduces the size of the graph needed for path finding (from 200x200 squares to around 30x30) and reduces the resources needed to calculate the path. this is good because Blender Game Engine uses Python, and even a well written A* implementation is not that fast in Python. Still, I'm getting a logic tic rate of between 3-7ms which is very good. I'll have to wait to see how other blender users report their speeds, but so far I'm hopeful about having real time pathfinding displayed for the player during their movement ...

Today I worked on the prototype navmesh for the game. Most 3d games use a navigation mesh, it's easier to store data about where you can walk in a mesh than in text arrays, the mesh can also be edited easier than rewriting an array. Unfortunately with a random dungeon the different sections have separate navigation meshes, and in Blender you can't merge the meshes. So in this project I'm using the meshes to generate the list of walkable tiles and then they will be deleted and the data will be kept as an array. I'll be using simple neighbor checking to create a graph that can then be used with A* pathfinding. It's all very old fashioned, but for me it's interesting to use these methods because it allows me to understand what's going on at a very basic level. I don't really expect to improve on modern AI but I can find what's good for my project and leave what I don't need. Here's the walkmesh: You can see the red areas are walkable,...