Skip to main content

Posts

Showing posts from 2016

More Health Bars

Something I didn't point out yesterday was that the status icons only display when the specific status is valid. You won't see them most of the time. I decided to go with more transparent health bars in the end, the previous version looked nice and crisp, but it was too obvious, it preoccupied the eye, taking it away from what's really happening on screen. The new version is a little less obtrusive, there will be different color schemes available depending on your faction, or your personal preference. The rectangle with an "X" in it is the state icon. I've chosen 4 icons to show which state / stance (aggressive, sentry, defending, flanking) the unit is set to. I'll have to change the control buttons to match these new icons though otherwise it could be confusing.

Health Bars

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

Engagement distances.

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

UI buttons.

UI design, and 2d artwork in general is one of my weaknesses. I'm trying to improve my work in this area and one thing I've been told is that it looks better to have cleaner textures, not so much grunge as I've been adding. Also thinner borders with more room for the icons. Here's a mock-up of the buttons I've been working on: The top ones are deactivated or not clicked, the bottom ones are when something is selected or clicked. I think they look pretty good, even when small on screen. Let's compare them to some other games: One game UI I like the look of is "Order of battle". The icons look clean, the faded paper texture is nice. It's similar to the UI adopted for the Blitzkrieg spin off, Stalingrad: I like this three tone effect. it doesn't detract too much from the main game action and it's pretty easy to tell one icon from another even if it's not easy to tell what they mean. The blitzkrieg 3 UI goes back to

Vinland UI

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

Diablo Trees In Game.

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.

Diablo Trees

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:

Infantry Squads

My video diary is up on youtube so you can see the results of my experiments with infantry working in game. Here's a shot of the finished designs for the European faction's early war "Summer" infantry: I may do some work on the scout because I'm not 100% keen on the design, and the Machine gunner needs a lighter jacket, but for the others I'm pretty happy with their appearance. Adding the other factions infantry should be easy from this point. I want to add some more infantry types though, such as commandos, paratroopers, gun crews, snipers, radio operators, bazooka troops and so-on. Some of them will be specific to each faction, like ski-troops for the Vinlanders.

32 vs 64

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

Rifles

Added a second infantry type in to the game for testing. Now there are riflemen and sub-machine-gunners. I found a way to reduce the time it takes to do the animations, which is nice. It was really pretty quick to animate this one.

7 directions

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&#

stormtroopers

As I said in a comment my last post, by duplicating some frames and mirroring them I can get 7 directions out of just 4, so the final result should be similar to what I was showing in earlier videos. Today I worked on some new infantry models: These are some Holy Roman Empire troops. The HRE is a large sprawling pan European Franco-German empire, similar to but much more successful than the Holy Roman Empire in our timeline. Right now they look a bit too like Germans, with the grey uniforms. I'm probably going to make them more brown or blue-green. Here's a preview of the animated sprite doing all 16 animations: It didn't take that long to do all the animations, though some will have to be modified for other infantry types (like riflemen or machine gunners etc..) The important thing is that all animations are available, so I can get to work adding them in to the game for testing and see how it goes from there.

4 frames

After testing the infantry extensively I've come to the conclusion that it's possible to depict an infantry man with just 4 directions of movement and 4 frames of animation. Previously I was using 8 directions and 8 frames of animation. That's; 4x4=16 vs 8x8=64 Obviously 8 frames looks much better, but not so much that it's worth 4 times as much resources. An 8x8, 64x64 pixel animation takes up 512x512 pixels. That means for a 1024x1024 sprite sheet I could fit in 4 animations.  Each infantry type has 16 animations at the moment: default : Just standing around waiting. walk : walking, running, marching, it's all pretty much the same. fidget : A general all purpose action, for laying mines, serving an anti-tank gun, etc... ride vehicle : Crouching atop a tank or assault gun for quick transport.* shoot 1 : a variation on shooting their weapon. Maybe standing. shoot 2 : so it doesn't look boring, an additional shooting action, crouching f

RTS pathfinding

I spent some time today looking at the possibility of adding A* path-finding to my game. I've used it in the past and I actually got it running pretty fast, even though it's written in python. So I was optimistic about replacing my less than stellar dumb path-finding with A*. However I ran in to some problems. First is the fact that I'm working with quite a fine graph, each infantry man takes up one tile, and tanks and the like take up several (a big tank takes up something like a 12x12 chunk of tiles. When you're working with a graph which might be several hundred tiles square, you get slow performance. When I've used it before I worked with either a pretty course grid, or with navigation nodes. [a* with grid] [a* with nodes] Both these situations give you quite a limited grid and so, good performance. Working outdoors with such a fine and almost unlimited grid makes the algorithm work too hard, especially when you have a lot of agents. Looks

Scrunchies!

The infantry are coming! You can see a quick video here . Infantry are moving around as expected, it's easy to select them and get them to go where you want. As of yesterday there were still problems with them getting too near to tanks, and not knowing to get out of the way when a vehicle wants to come through. I think I got that covered today though. Here's a first version, you can see something is up right away though if you look carefully. That's right, I forgot the camera is rotated 45 degrees for an isometric style view so the infantry are facing the wrong way when moving. After adding a 45 degree offset to the code for sprite display I got them to face the right way. I also tweaked the code to stop them from walking through each other. Now they won't occupy the same square as a fellow squad member. They also adjust their avoidance radius based on their state. If they are standing still they will move out of the way sooner. But while walking they ar

Infantry experiements.

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

General Principles for Reducing Logic Overhead (Part 2)

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.

General Principles for Reducing Logic Overhead.

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