Pickledtezcat Game Devblog

Vehicles are working nicely now, and I think the vehicular game-play is coming to a point where I'm pretty happy with it. You can see some of the more recent progress here . Now with tanks churning their way through the mud, I think it's time to start bringing in the PBIs. Poor Bloody Infantry. I need to see how infantry reacts to vehicles, how well (or badly) my pathfinding routine works with large numbers of agents and vehicles. And overall how infantry works out in the game. I think the plan I have is going to work quite well. Infantry move very slowly, so the pathfinding calculations shouldn't happen very often. The pathfinding itself is very rudimentary, just like that I'm using for the vehicles at the moment so the overhead should be small. I've actually got a whole load of infantry building scripts and models left over from an earlier version of the game, but I'd like to start from scratch on that one really. I'm experimenting with qui

In my post yesterday I forgot to mention a few things which would be even more helpful when trying to make your game run smoother on low end machines. Firstly I forgot to mention states. Probably the biggest improvement you can make to your code if you're not already using them is to add behavior states. When your agents are doing an action, that action should be a separate state. They should concentrate only on that state, all other calculation should be avoided.

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

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