Pickledtezcat Game Devblog

The second play test of the Alpha build went well, lasting about 30 minutes of real play before an unexpected crash. There were a number of small issues and things that need to be re-balanced, but overall, the game was great fun. When comparing to the real-time version of the game from 6 months ago, there is a marked improvement is fun, and real moments of excitement, at least for this play tester. The mission chosen was one with multiple small groups of enemies scattered around the map. The player had limited artillery and air support, one unit of each. Both sides had a combat support unit for de-buffing opposing troops, and the enemy also had a general support unit for buffing friendly troops. A short time limit meant that the player had to split their troops to tackle several objectives at once. This made the mission quite interesting as several small combat arenas were active simultaneously. The small map size (32x32) wasn't a problem, it never felt that cramped, and at t...

It's been a while since I posted here. I worked hard on Vinland; 1936 and got a playable demo up and running. But there were quite a few problems with it. I could have continued with the project as it was and finished adding all the art resources, but the game seemed so flawed that it just wasn't worth the effort. So once again I'm starting out from scratch. This time I'm going to be taking on board some gameplay elements that I've picked up from some other games I've played recently. I'm also going to avoid adding any art until the gameplay is all finished. For now I'm using some stand in assets that I created this afternoon; With luck I should be able to get the game to a playable state quite quickly. This time I'm going to get testers to try it out before spending any time on art assets.

I greatly reduced the rate of fire of the rockets and made them smaller. A single 60mm rocket now takes up the same space as a machine gun. A single vehicle should mount a large number of rockets to take advantage of their power. I also added a delay after a weapon is successfully fired. This means the rockets will fire in a staggered volley instead of all at once. I tried both styles and this looks better and creates less logic spikes. I think it needs more smoke and I'll be adding some rocket trails too. I'm still unsure of where to put the rockets in the tech ladder. In real life the Russians developed their rockets before the German invasion. They were first deployed in 1941. These early rockets were quite small though larger ones were developed later. The Germans designed and tested their first rockets as early as 1940 but they were not deployed until 1941. Larger rockets were introduced later. The rockets weren't mounted on vehicles until 1943, by whi...

"What is that ugly mess?" Well, it's a test for a dynamically colored set of items. The original icons were taken from here , a great source of black and white game icons. Very useful if you're planning your project and need some stand it art. The red channel is the grayscale image, the green channel holds a mask for non metallic, non-colored sections, like rope or bare leather. The blue channel holds a mask for dynamic colors. The masked areas can have their input adjusted by a three channel input (RGB) from a material, to control hue, saturation and value. This gives a wide array of different colors meaning that no two items generated by the item generation script should look identical. Here's what they look like when passed through the shader: Ok, still a bit of an ugly mess... I think I need to start with better material than a faked hightmap from a 2 bit image. :) Honestly, I think 2d art is my worst area. I'm probably just going to move ...

I added the possibility of pits or water to the dungeon yesterday: I also added some debugging tools to reveal the map on command. I noticed a room sometimes isn't connected. I think it has to do with adding rooms manually. I'll sort that out as soon as possible. I also have been working on item generation. Sample output from the equipment generator: Perlmurite armor Iron man-trap Broken, cooked eggs Brass handbow Feathered clothes Hollow, corroded, copper hatchet Occult, rare, gyium-leather sandals Rudde-leather cape Oil stained, white-copper ring Enchanted, brewed meat Brewed medicine Perfect, gyium-leather armor Awesome, composite, brass handbow Ivory mace Magical, akkadi-iron greaves Fur choker Old, haldiris greaves Extended, gyium-leather leggings Magical, iron hatchet Magical, perlmurite treasure Light, bronze, narrow hammer Animal-hide shield Occult, gyium-leather belt Blood stained, grubby, iron throwing-axe Magical, gold coins Ruine...

I've now narrowed my level generation methods down to two. Previously I was also using randomly placed rooms and BSP trees, but with one the corridors were too long, and the other suffered from terrible predictability. The two I'm using are (1) cellular automata and (2) collision based room insertion. In the maps above the D and E maps are type 1, a kind of cavern like level. There are several inputs like coverage and smoothness. They basically generate these two extremes, very open, joined caves, or sparse tunnels. I may add double thickness corridors to the (E) map as otherwise they are annoying to play (no room for maneuver).    Type 2 maps start by piling up a bunch of random rooms in the center of the map. Then they run collision detection to push them apart. (A) is a map with quite high padding value, which places the rooms far apart. (C) is the same method by a padding value of 1. The rooms are quite close together. Corridors are short, which is a good thin...

For anyone who's interested in the newest version of the game you can see the current video diary here : I'm very happy with the atmosphere of the game so far. I feel like it's something I can work with. I've got a lot of ideas for the game, but for now I'm just going to keep slogging away trying to get a working gameplay demo. The schedule so far is: 1. Item generation. 2. Basic player stats. 3. Inventory management. 4. Moving items between the screen and the inventory. 5. Using items to attack and trigger events. I'm going to be working a lot with messages this time around. That should clear up many of the hurdles I was facing in past versions of t he game. One problem I had before is that I had to complete both player mechanics, and enemy mechanics simultaneously. A player attacked a monster causing damage directly, the monster had to process that damage and so on. With messages, I can just send a message and forget about it. It doesn...

As usual after finishing a game jam there's loads of stuff that I learned that can help me to make better games. Going back to a work in progress now feels really difficult because so much of the existing code looks ugly and inefficient. I think I'm going to strip back a lot of the work I've done on V1936 so far and rework it. Here's the new structure I want to implement: Before, fog of war, level generation and agent management were all direct elements of the main loop. What this meant was that if I wanted to restart the game or load a new level it was best to reboot the main loop (restart the game), but this has quite high overheads all of its own. During the making of "The Hole" I implemented a level manager, a container for the level and all agents etc... contained within it. I could pause the level, or reload it or do anything with it, without affecting the main loop. This made it great for adding cutscenes, or menus such as the inventory. It al...

Telling a story; Creating a Compelling Narrative. In this blog I will talk about my own recent brush with story telling and go on to talk about how tools from creative wring can help you to better author the narrative in your games, whether they have a traditional linear narrative or a procedurally generated interactive narrative. Narrative and structure in traditional fiction    last week I started writing a story set in the world I'm developing for my game Vinland: 1936. I hope the story will help me to flesh out my game world and develop my own expanded universe which will be a good place to set my games in the future. After about a week of work, on and off I've progressed the story to outline stage. For each character thread I have half a dozen chapters which plot a course through the events of the story. Each thread is told from the perspective of a different character. Actually I started writing as soon as I had my outline, but I've since gone back an...

Today I implemented health bars, which seems like an easy thing to do, but in a game like this health bars need to display quite a lot of information without becoming overwhelming. I'm not quite happy with them yet, but I'm getting there: There are 5 elements to look at here: The first is the health bar, a simple green bar with a black background. I'm not sure I like the shad of green though. Also there may be multiple health bars for vehicles to show engine damage, crew casualties etc... or I may leave that up to the info-icons. The second bar is the red one, this is the shock bar. As a unit comes under fire they will suffer shock. If the shock bar is too high the unit will become pinned. Enemy units might run away too. The bar will drop down naturally depending on the experience of the troops. Some other actions can clear the bar too. The third element is the group number. Using control and number keys you can set selection groups, and then select units by pre...

Today I did some work on the mini-map. It's working great. Later I'll be using some textures to make it look better, but for now it's just in the testing phase. You can already see that it shows the location of friendly units and their viewing range. Line of sight is currently dealt with as a radius only. I've thought of using obstacles to block sight but I think it's one of the things that was really unpopular with the original blitzkrieg. When an enemy was shooting at you but you couldn't see it to shoot back or even guess where it was. Very realistic, but also highly annoying. I think there's going to have to be a compromise. If something is far beyond your line of sight, you can't see it (though it might see you). If something is blocked by a building, you might see it, but can't shoot it. You need to get a direct line of sight. I'm also thinking of making out of range or blocked units invisible but represented by a question ma...

Starting work now on the UI for the game. I need to get on with this as it's going to handle controls for things like changing infantry formations, giving orders to your units, targeting and combat etc... Here's an early version of the UI command buttons: The commands will also be accessible by hotkey. For example the first 4 are A, S, D, F: 1. Attack, 2. Sentry, 3. Defend and 4. Flank. These will set the overall state of the selected units. Attack will make the unit move to the selected destination or enemy, trying to shoot whenever possible. Sentry will go in to observation mode and for infantry they will go prone. Tanks will open their hatches to get a better look around. They won't attack unless first attacked, and will get a better visual range in this mode. You can use the ambush mode as well (second row, number 6), in which case they won't get the visual bonus, but will be harder to spot. Defenders will try to turn automatically to face the nearest...

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:

I started to worry yesterday that the size of the textures involved with adding a lot of infantry types would start to put a drain on lower end graphics cards, so I had a think about how to deal with that. One thing I did right away was to rationalize the number of animations. A lot of the ones I chose were not really that essential, so by being a bit ruthless I was able to cut it down to 8. By halving the number of animations I was then able to fit two infantry man animations on a single sheet. I further tested using 32x32 pixel sprites instead of the current 64x64 pixel sprites: It's difficult to see the difference at the normal level of zoom. You have to zoom in quite a lot of notice: Now you can see the big difference. I think the 64 tiles are much nicer than the 32 tiles. I don't think it would be worth cutting them down that much in quality. But since I will be loading the sprites from an external file, I'll think about including a set of low rez sprit...

I got over the lack of a North direction in the animations by giving each infantry man a default "north" facing when they are created. This will be either North West or North East randomly. That way there's a little more variation in their appearance. Making a good 4 frame walk animation is not that easy, it tends to look a bit like they are moonwalking. Still, being able to fit all the animations for one infantry man variant on a single sheet makes up for it. I changed the default animation (and prone default, trench default etc...) to be a fidget animation. This has a lot more movement (checking the gun, looking around etc...) and only plays 10% of the time, when the infantry man is idle. This should stop the infantry looking so static when they are just standing around waiting for orders. I gave the troopers a blue uniform, somewhat similar to those worn by Austria-Hungary armies during WWI. I think this gives more of the pan-European look I wanted. It...

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