Lots of improvements to infantry this month.
The infantry sprites shown in previous videos were put together in to a sprite sheet which was 512x512 for a single action.
The new sprite sheets are 512x1024 but include all 9 actions. There are two infantry types on a single 1024x1024 sheet, so that for 6 infantry types I only need 3 texture sheets.
How did I do it?
First of all each animation is now just 4 frames. Honestly that’s enough to show any action, from walking to shooting to dying.
Next I only rendered 4 [s, se, e, ne] directions instead of 8. The extra directions [sw, w, nw] are produced by mirroring 3 of those directions. Unfortunately this doesn’t work with the south direction, so there’s no North animation. I can live with that though as it’s not really noticeable.
Also one of the actions is a reversed version of an existing one. In this case “go prone” is reversed to get “stand up”.
You can see in the video that there’s an arrow that represents each squad. This “squad” object contains a number of “man” objects. Each squad is updated every frame and the squad updates each of its men.
This update is most often just to do nothing or to lerp from one tile to another. If they are on screen they also play the correct animation. The squad has a combat manager object which will handle shooting and taking damage as part of the update cycle. Most of the heavy logic like chosing targets, navigation, taking damage or shooting don’t update every frame but instead on a cycle of about quarter of a second, dependent on the speed of the unit (faster units need more regular updates).
This setup could be reproduced by having each man with its own logic, but the relation between the men and the squad is quite important so it’s best to deal with them as if they are connected.
One problem I had to overcome is that when you have objects which don’t update every frame they can miss important events if the event doesnt coincide with the update.
To deal with this I use command message lists.
For example when a tank shoots a squad or the player clicks to select or move a squad, a new message is apended to the squad’s command list. This list is processed and cleared according to schedule. The message is a python object with relevant properties which can be used as arguments when processing it. An example would be the select unit command. When you drag a rectangle to select some units it sends a message to each unit in the game with the screen co-ordinates of your selection box as the arguments. The unit processes this command by checking if the unit is the player’s team and if it is inside the selection box.
Rather than loop through every agent and do this (which would create a momentary logic spike) the units handle the command themselves on their own schedule, which is staggered to avoid spikes.
After some messing around I finally got around to putting the project on Github.
This is the first time I’ve tried anything like this, but I was having some problems with trying to deal with version control using pycharm.
In the past all my scripts were packed in the blend file, so if I wanted to try something new I just saved a version of the blend and then if things went wrong I could reload the old blend and get all the scripts back to their previous state.
With pycharm I ended up copying scripts, dumping them in a different folder and then replacing them, which wasn’t very elegant.
Hopefully I can start being a bit more professional and do branches and keep things more organized.
An example of a branch would be the work I did yesterday. Previously I was handling turning of agents differently from movement. There were two different actions. Now I made turning a movement action, and added a waiting action. Now there’s just one action that gets updated and has a progress meter (0.0-1.0) which the agent animations can use when controlling the agent’s visual movement.
Adding a “waiting” action to the agents was very important since it can be used to make tanks wait when surrounded by friendly infantry.
Now they will stop and let the infantry get out of the way before advancing on their goal. Previously they would try to go around, which made things worse as the infantry would move to the wrong place and everyone would get jammed.
Infantry is looking good these days, they are very fluid and use very little resources to manage.
I was just wondering , how many units you can show on the map with no lag. It seems you can add like hundreds or even thousands of them with your current setup.
I haven’t stress tested it yet but yes, it should be possible to have quite a few. One of the bottlenecks is on screen animation, making sure they follow the ground. They use a ray at the start and end of a movement action to get start and end heights, then lerp between them. This is ignored if not visible or off screen because raycasting can be quite expensive. I’m thinking of replacing the raycast with a lookup in a dictionary of tile heights supplied by the terrain generation algorithm, that should be faster still.
This is all based on my guesses about how they handled this kind of thing in the game I’m basing this on. I think I’m close to how they did it because the resultant behaviour is very similar.
My problem was inexperience. I haven’t used it before so it took a bit of messing around with the settings. (“Can’t find git path”, “who are you?” Set git config --user.password etc…)
This is just a basic test of the mini map. Later I’ll use real textures for the terrain. Right now I just want to show the different terrain types and the vision circles as well as the team id blobs.
The order buttons will be context sensitive and are currently just for show. They aren’t active yet.
Did some work on the UI, mini-map and infantry movement modes.
I wanted to start work on combat, but I realized that it would be hard to do that without proper controls. Also movement isn’t quite finished yet and it may change how combat works out in the end.
There is no word to describe your job, guy!
Awesome! All your videos, all your progress!! Are you going to do some graphic improvements? Because all the logic of your projects already is 100%.
PS: Create a list of all the improvements/updates you are planning to develop, because I can’t wait to see this!
Hi, thanks!
A lot of the graphics are palceholders at the moment. Infantry will look similar but not exactly the same, vehicles may get a reworking, though that took a long time so I’d prefer to keep that as a goal for an early expansion or sequel.
Terrain and buildings are going to be completely redone.
For an idea of what I want to do with the buildings, hereis my inspiration.
I will be modeling a high poly version of the building and baking it to a low poly mesh with normal map. For the initial model of the building I will be using small tiled textures. At the base I will use alpha to represent grass and make it so it isn’t sitting so squarely on the ground.
Of course it will be a little more complicated because it will need damaged and destroyed versions too. But it will only need to be viewable from a single angle, so that makes it less complicated.
A whole day of development wasted yesterday as I went through and reformatted some of my code.
In some parts I had been using dictionary keys with spaces, so they could be used for display in buttons and help text etc…
My advice; Don’t do that. Use_underscores_in_dictionary_keys.
It’s easy to strip them out for display in a UI.
Lucky I wrote a script to reformat my other scripts or it could have taken days to check them all.
Yes, next day it does seem better.
I needed to clean up the code because I have two more agent types to add. The first will be a combination vehicle/ infantry unit representing artillery, antitank guns, AA guns etc… the weapon will use code from the vehicle class while the crew will use modofied infantry code.
The other agent type is going to be buildings including trenches and pillboxes. These are complicated because infantry need to get inside them. They also need to be destructible and have the ability to change teams depending on who’s inside.
are yoo thinking in implementing Hotkeys? since you have already implement the ctrl+Num for fast unit selecction (which is fundamental), you should go with a set of hotkeys for fast building, changing unit state or get some tech upgrades (if there where this last ones).
Starting over, though I’m going to be reusing a lot of the code and assets. Found ways to overcome the hurdles which were slowing me down before. Hopefully development should be much faster from this point on.
Thanks. It’s not easy to stick with a project when there’s not much interest.
I’m pretty much making this game for myself anyway so it doesn’t matter really. I just miss the days when blender artists had more participation.
