Pickledtezcat Game Devblog

It's been a while since I posted here because I'm moving most publicity for this game over to a facebook page. You can see it here . Right now I'm working on buildings, I've done a mock up of some to show the damage progression from pristine to bullet marked to fully destroyed. There are some buildings at the back which are going to be used for a different map type, the "destroyed city" map. I hope to have several different map types, including winter and fall, desert and this one. It will represent later parts of the game where the defenders have fallen back to positions in their cities and are fighting desperate urban warfare. 

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

I finished working on the code for adding foliage and having some extra time I decided to experiment with the code for rockets. The original idea I had was that rockets would be large vehicle components that can be fired very quickly, regardless of how much manpower is used for reloading. They would use up a lot of ammo, so they would run dry after a short but devastating barrage. The problem here is that it's easy to take advantage of this by adding a lot of ammo, which is much smaller than in bulk than the rockets. There's also the problem of firing large caliber rockets. In real life rockets of up to 30cm were used, but I think that will be too powerful for the scale of combat in this game. lol. Somehow that one trooper survived the mother of all explosions... A 30cm rocket could contain nearly 30KG of explosive. That would be a very large explosion. I've tried to balance the game by using a simple equation to make bigger guns more powerful, but h...

Right now I'm working on the game's effects. Explosions, physical reactions, sounds etc... It's not easy to add really great effects without putting a drain on the Blender Game engine, so things will be as good as I can make them, but not at the expense of frame rate. Here's an enemy tank being bombarded by rockets. Hits by enemy weapons cause a vehicle to shake and rock. Later there will be more effects, such as rocket trails and a big explosion when the vehicle is destroyed. Here some infantry are getting hit by small arms fire. You can see the red section of their status bar increasing. This shows they are heavily shocked. When that happens their rate of fire and accuracy is decreased and they also can't move quickly. Finally here are some PBIs getting hit by automatic 40mm cannon fire. Machine guns and auto-cannons are very effective against enemy troops out in the open. The large caliber model also does splash damage, increasing the damage ...

I've started work adding trees back in to the game. They look nice already with the mipmaps turned off. I think I've got the color match with the ground for summer trees. The trees have a "shadow only" object which helps reduce rasterizer usage and match the shadow with the lamp. I'm not 100% happy with the trees right now, but I hope they will get better as I make more of them and refine the textures a little. I really don't want to waste any more time just fiddling with them. In a few days I'll take another look and see if I can see where the problem is. I think maybe the ground color is too uniformly light. It needs some more dark areas and contrasting sections. I decided to go with the hollow health bars, I like the effect. More than the black bars. I've also finished adding recoil and other physical effects to the vehicles. Even the guns move, with the main gun swiveling to track the enemies. It also tilts for range if it is a suppo...

It's been a while since i posted any updates. It's not tat I haven't been busy, only that the work hadn't reached a point where it was worth showing. It's been a lot of small incremental changes, building a modular menu system with widgets and buttons, porting over some of my old code for displaying vehicle models etc... This is just a dummy menu at the moment. From here I can set the active profile, manage vehicles for testing and jump right in to an in game testing environment. Each chunk of screen space like this is a widget. It can have a number of buttons. The buttons react to being moused over and clicked. They send a message to the widget to decide how to deal with that interaction. The widget then executes some code and might reset the menu page or load a different one. Clicking manage vehicles loads this menu: I've moved some of the structural elements of vehicles away from components mounted in the vehicle and in to a system of options w...

I've been working a lot on the game recently and I've nearly rebuilt it to the level it was before. Past that maybe, since now I have the beginning of a working combat system and the ability to save and load the game. Infantry can now occupy a building. It's quite an abstract representation, since they stay at the door and turn invisible. But they can then fire from one of the windows and take damage from shots at the windows too. I think I've set it up well so that when building damage and destruction is working then the system should continue to work. For combat I tried some new ideas, but they didn't work out that well. It seems that it's important that viewing range should be further than shooting range. Now shooting range is pegged at 18 units of distance, while viewing range can extend out past that. In the above image one unit has an officer, so has further viewing range. The other can only see as far as they can shoot, a dangerous situation si...

I'm going back to my real time tactics project, Vinland 1936. While working on the other project I overcame the problems which were stopping me from saving/loading the game and also cleaned up the base code a lot. After a few weeks I'm getting near the the state I was in before. Infantry are back to their previous state, and vehicles are running OK. This time I'm going to push ahead with mocking up the combat system though before I work any more on the vehicle builder or graphical aspects of the game.

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

Another video diary can be viewed here : This shows at least part of the screen layout. I'll be working on the inventory and UI next. You'll be able to drag and drop things right from the UI to the viewport.

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

I've been working some more on the map window. Right now you can only see the base, it doesn't show items, enemies or even doors on the map yet. These would be decals. In the top window you can see the modified result of last night's tile based map. It looks good but there are some visual artifacts related to the problems I encountered yesterday, and as well it takes much more code and time to calculate. The second window uses a cheap trick to fake an beveled look from a smoothed version of the 32x32 map. It uses black to mask unexplored areas. Finally the third version is meant to look like a had drawn map. I'm using a cross hatching texture to distort it and unexplored areas are shown as blank map paper. There's going to be a mechanic in game where you need to use some paper every level in order to activate the map for that level. From there it will fill it in automatically. Paper will be pretty rare so it might be worth keeping it safe for the more com...

I spent a total of about 4 hours trying to find out why my map wasn't displaying properly. Turns out there was nothing wrong with my code, or my shader, the problem was in the imprecision of the floating point numbers used to scale the UVs and the default use of sRGB color space by blender. (top left) This is similar to what I was getting, obviously not right, but I couldn't figure out why.   (top right) Using data from the map each square is given a red color from 0-255. (bottom left) There are 16 possible arrangements of tile and the red color offsets the UVs of that tile by a set amount. (bottom right) The rather unimpressive final base result. When scaling UVs Blender avoids imprecision in floating point number by just rounding up to a more suitable number, so 0.0625 becomes 0.063. This is fine usually, as you don't really care about pixel perfect placement in most applications. But when your total image is only 32 pixels across it can cause issues as 1 divid...

Treasures of the deep dwellers is not a triple A game. It's going to be pretty old fashioned, with a small viewport and a map on the same screen. Much of the rest of the screen is going to play host to the UI which will have a lot of the stuff you need all on one screen. I love the great graphics of modern games like Legend of Grimrock, but the blender game engine isn't really up to the task of making games of that caliber. I also don't have that much time to devote to asset creations, meaning my game simply wouldn't look as good even if I was as talented as the guys from the major studios. Anyway, after working on the viewports I found happily that it greatly increases the performance of the game. Rasterizer usage is way down, and the viewports mechanism also allows people with slower computers to reduce the resolution of the viewport without changing the main window. If you wanted you could ramp it way up too and enjoy my dated graphics. After a few tries I ...

This week I've been fleshing out the dictionaries for my dynamic item generation system. I made a few changes since it was first designed, like simplifying the materials and making them less exotic. Now there are a lot of normal materials (like COPPER and GLASS) and some exotic or magical materials. Items are generated with a number of attributes. Which ones they get depends on the type of object, its quality and its material. Here are a few examples: I think it's going quite well so far, though I'm having to generate a lot of items and check their attributes so I can fine tune the dictionary rules. You can see the "CLUB$1" up there, which is a rare, ivory, toy club. I think children's club would be a better attribute than toy. That sounds strange in some cases. There's a ugly, copper long-sword, which is both blunted and corroded. Items can have several damage attributes, depending on their quality. As they get used in game and pick up...

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

I ran in to some serious problems with Vinland 1936, so I'm shelving it for now and revisiting an earlier project. Kind of. Treasure of the deep dwellers was a 3d team based roguelike. Some ways it diverged from standard roguelikes is that it had multiple player characters (a team of 4), real time game play (not turn based) and it had 3d graphics. Unfortunately it was a bit more than I could handle. The new approach is an attempt to simplify the project so that it can function more like a traditional roguelike. A big problem I had before was keeping track of the 4 agents. They tended to run off or get lost. I had to calculate line of sight and map reveal from all 4 agents. Now I've switched to an "Eye of the Beholder" type setup, where the whole team is contained in a single tile. Likewise monsters are represented in mobs of up to 4 agents in a single tile. Other benefits of this type of gameplay is that you never need to see the player's characters (...

I've made a final version of my BGMC game and I'm hosting it on gamejolt. You can pick it up below:

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

Well another Blender game making contest is finished and as usual it's left me to re-evaluate what games I want to make. I had great fun making a story based adventure game, and I'd like to set up a collaboration to make another one, with some other artists. The game would be developed over a set window, like two months and then released immediately, maybe try for steam greenlight. It would be nice to try and do something in a set time span instead of the almost endless development cycles I have with my other games. Anyway, if you want to play the games from BGMC 23, including mine you can download them here . 15 games to try out for free, that's something you don't see every day. :) I'll leave with an animation of one of the scenes I designed for the game, a proper matte painting, the first I've ever tried:

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

I'm revisiting the vehicle editor currently, partly because of some issues what have cropped up with how vehicles are saved and loaded. If I'm going to go back and dig in to it that deeply, it's better to rewrite it.. and update the visual elements at the same time. Here's a preview of some of the elements of the UI, I've simplified and cleaned them up a little. I think it looks better already. On the writing front I blocked out the chapters for the story, I'm pretty happy with it. This is the first time I've approached writing like this, with writing a chapter summary for each chapter and then going back and expanding the scenes to fill in the chapter. It makes much more sense than just starting writing from page one and going with the flow. That's why all my previous stories failed probably. :)