Another short update:
Looking good!
One more demo. I’m ready to start work on coding AI and combat now.
In the video I talk a bit about top speed vs handling and the feel of the game I’m aiming for.
Looks great, can’t wait for the next update.
Will it support touch?
Looks great! Will there be hills to drive over in the game?
I don’t like the interface design though. 
Seems to heavy on texture details and thick frames with small icons. I think it will look better if it is more simplistic.
Keep up the good work!
Like as in touch screen? Sorry, it’s PC only.
It’s kind of an old school game for guys like me, people who enjoy old strategy games and prefer single player to multiplayer.
There will be hills and rough areas. The vehicles are designed to conform to the ground so they go up and down hills.
The interface is supposed to capture a certain aesthetic from 1990s CD rom games.
Here’s a screenshot without the textures, I’m not sure which is better…
I guess I could probably do with some help from a UI artist, since it’s one of my weak points. Maybe something with higher rez textures and thinner lines: http://www.deviantart.com/art/Game-Interface-106551767
Anyway, today I’ve been working on the Fog Of War and line of sight code.
I could do with some feedback about which version looks best:
There are 4 types:
- Anywhere my units can’t see is 100% black.
- Anywhere I haven’t been is 100% black.
- Same as 1 but only 50% black.
- Same as 1 but with an outside area which is 50% black and a far viewing area which is 100% black.
There are some possible combinations of one or more of each, but they start to make the code more complex.
I like 4 since I like the idea of keeping distant areas completely hidden. The game is procedurally generated and each time you play it will be different. Scouting out distant areas will be important.
A small fast vehicle could get a look at villages or bases without entering full visibility range. Enemy units that are beyond engagement range would show up as a question mark. You can tell someone is there but you don’t know it it’s a truck or a tank.
It could be annoying to not be able to tell what’s going on in areas which you’ve already visited but can’t currently see though. Like “Where’s that supply dump I found 10 minutes ago?” Maybe it would encourage the use of scout units, small, cheap infantry teams whose job is to keep an eye on places you’ve been…
More progress, but mostly code writing this week.
My favorite new feature is a profile filter. When you call a method through the profile function it times it as it runs, and sends the time to the debug text on screen. The result is that I can beak down the logic overhead in to different areas and see which are running too slowly and try to figure out why.
I’ve already fixed a lot of slowdowns and bottlenecks.
Another important trick I learned was separating update() in to two functions.
The reason for this is because of inheritance. Sometimes you have multiple levels of process, for instance in a particle. There can be basic behavior, followed by specialist subclass behavior using super(). You may want to do an exit check at first (see if the particle has expired or collided or become too small or transparent to see) and then if there’s no need to exit then do the subclass update (grow ore move the particle, change its color, do sprite animation etc…), but it’s difficult not to stop the subclass behavior from within the main class.
You could always do return super(), but it gets complicated. Having all the subclass behavior take place in a different method is far more robust. Just run the main class, and if there’s no need to exit or finish, then run the sub-process.
This is particularly good practice in state machines as it can also help to eliminate that annoying one frame delay when a state finishes but a new state didn’t start yet which can cause little jerky movements or strange state exit choices in some cases.
This type of games were one of my favorite games back in 2000y. When I’m watching your videos I feel the same vibes. It is a good thing, also I feel everything that annoyed me back then…the slow rotation and movement of the mechanical units.
Great progress! It looks like you are definitely going somewhere with this game!
Yeah. I’m going to have to take care that the rotation happens slowly but responsively. Nothing worse than when you click to turn and nothing happens.
But part of the game is planning ahead. If you get flanked because you didnt anticipate enemy being in a certain position then you should pay the price.
The vehicle movement system is pretty much how I want it now. There’s some more stuff to be worked out, but I think i should start merging my infantry system first. it’s going to be important to see how vehicles and infantry work together, loading infantry in to vehicles or buildings, and seeing how infantry can cause traffic jams (unless you jut roll over them).
I think infantry are going to be worked out as a kind of invisible vehicle agent, with particles as the sprites for the individual soldiers.
I don’t want single soldiers to be included in the agent calculations, and when it comes to controls I’d rather move infantry as squads.
Above is a preview of my “blank” a simple model which I’m going to be using for infantry. infantry sprites are going to be really very small, so there won’t be a lot of detail.
I want to make sure the infantry model and rendering set up for producing sprites is available for other people to use. I’d like my game to be mod-able, so other people can make their own alternative history scenarios with very little effort.
how much polys do you intend to use in the infrantry model? and how many units you think can be spawn and used at a same time without getting fps troubles?
The infantry is going to be sprites. With BGE using models would be fine for rendering, but the animations would eat up processing time really quickly if you had a lot of them.
Great idea to organize infantry in squads to save even more resources. You really know what you’re doing. Nothing else to say than “keep it up!”
Thanks!
I did get infantry working in the end. The method I came up with seems pretty low impact, can’t see any big spikes on the resource monitor, even with several large groups of infantry in play. There’s still more to do, making it so infantry can enter buildings and trenches next probably, then maybe moving on to combat.
I could make this a lot more complex, but then probably never finish it.
Probably better to make something that works and then try and get some support to extend/expand it.
Latest video diary:
(Might still be processing, something strange at youtube right now).
Very cool update, enjoying this games progress very much, thanks for posting ;)…
Thanks!
I’m always thinking of how I can improve the game, and trying not to get worn down by the ways that it doesn’t quite live up to what I want it to be. I’d love to make the pathfinding a lot better, actually that would be a breeze, but the trade off would be performance.
To some extent I need to focus on what I can make without dreaming of something better but impossible with my current skill set and free time. 
Lots of stuff to do anyway, I’ll keep working hard! 
The only thing I would suggest is having a marker or outline on selected units (or at the very least the tanks) because otherwise the player won’t know if they have selected an item properly or not.
Apart from this it looks great, I like the dirt effect that the tanks kick up!
Thanks, that’s coming soon. It will be part of the user interface based in the UI scene so the labels are always on top and don’t get enlarged with zoom. Until then there’s a debugging function which deals with it but turned it off for the video.