Project Metal Storm

I uploaded another video, I need better recording software, but the game is running at 60 FPS.

in here we can see the AI, improvements to the camera system (bug fixes mostly), the anime shader, a new melee attack, double movement and more that I don't remember.

housatic I added the ability for the dark shades to disappear at a certain distance after your comment, but it can't be seen in this video because it's using the non metallic material.

Tomcat Is it possible to switch between realistic graphics (or close to it) and cartoon-like graphics by applying a shader?

it is very easy to swap these materials for realistic ones, in the case of this model it started as realistic. it could also be done with the flick of a switch in game. but it takes a lot more time to make detailed realistic models and bake all 14 or something textures, specially with blender 3.
I think there will be a normal map because it helps with the shader, a diffuse, although probably very simple, a metallic map, probably AO, and roughness. So I could make PBR versions of the models by adding an extra diffuse map. In the case of this model, it had aniso and clearcoat textures for the finish because the model was made in cycles, but no other model will have those.

Tomcat I'm not a fan of such graphics (although this one looks quite decent), but I know that many players like it.

if enough people complain, I might add the option to disable it. but some of the backgrounds will be handpainted and retain some of the style. well, it is too early to tell.

xyz it was the original idea, there is a height map and all the path-finding algorithms (AI included) are checking if tile is the same height for moving. there's also bools for can_fly and can_hover in path-finding, but so far the world is flat.
it will be possible to get on top of boxes and buildings, but I need to implement ramps somehow and jumping (with jetpack) and a third raycasting function since they currently work in 2D.

so to answer the question: elevations yes, but no bridges. the terrain will also be somewhat destructible, so that will add some more tactics.

MikeCL Jesusemora Awesome progress! One thing that sticks out for me is the camera that follows the character. It's a bit much with those fast turns. But maybe that's just me

It used to be worse, I'm trying to improve it. The problem is that there's no diagonal movement so the pathfinding creates these zigzag patterns that result in many turns, and then the camera follows the character.
A way it could be solved is by passing the movement to the camera as a list of positions and smoothing these patterns, but right now the camera just follows the unit.
Alternatively I could add diagonal movement (it's just a line of code), but I need a way to force 90º turns on corners to prevent units from phasing through walls.

MikeCL Sooo I added diagonal movement, while still keeping hard turns for corners. I just had to add this line of code:

for j in corners:
	var cpos : Vector2i = pos + j
	if cpos.x > 1 and cpos.x < TerrainMap.map_size-1 and cpos.y > 1 and cpos.y < TerrainMap.map_size-1:
		var direc : int = TerrainMap.get_voxel(cpos, 0)
		if direc == 0:
			var odir : int = TerrainMap.get_voxel(cpos, 1)
			if odir == 0:
				if TerrainMap.get_voxel(pos + Vector2i(j.x, 0), 0) == 0 and TerrainMap.get_voxel(pos + Vector2i(0, j.y), 0) == 0 and TerrainMap.get_voxel(pos + Vector2i(j.x, 0), 1) == 0 and TerrainMap.get_voxel(pos + Vector2i(0, j.y), 1) == 0:
					arr.append(cpos)

The camera was already slerping, but was using a curve sampled from the difference between the current rotation and next rotation, now there's fewer turns so I can use a simpler method.
Next should be camera clip and fixing some of the visual bugs.
I've also increased resolution to 1920x1080 and it maintains 40 FPS, so next video should have better quality.

kuligs2 integrated GPU. although I will investigate further.
games are playable as long as it's above 30 FPS, and any modern computer or pc with external GPU will be able to run it just fine. like, I can't record something like NORMORD, I can't get 60 FPS in something like that with my pc.

it's 1920x1080 HD, it is the most used resolution next to 1366x768 and 1366x864 according to the W3S, so it can be taken as a high end. anyone with a 4K monitor probably has a powerful GPU.
https://www.w3schools.com/browsers/browsers_display.asp

if I need more FPS I can use FSR, it's a tradeoff between quality and performance, the higher the resolution, the more it takes to render a scene because there's more pixels.

It's also a tactical turn based game so performance is not as important as in an FPS or RTS.

DJMaesen I can't record a game like yours with my setup, I had a scene with a water shader like yours and it ran at less than 30 FPS.
my GPU just can't handle a modern game at HD resolution, it doesn't have the power, but it's good enough.
but don't worry, the game is running at 40-50 FPS at fullscreen and next video will have better quality.
next version of godot (4.3) is said to have made some improvements to performance, and more are on the way.

xyz Jesusemora Do you have the next milestone set with this? If so, what are the main features for the milestone?

at the time I made the last comment I had implemented the weapon system (the selection at the corner). now the unit can fire the rifle, machinegun, or both, and it's designed to allow for more weapons for the mechs.
adding that feature caused some bugs because shots where coming from ControllableUnit and I moved them to a new class Weapon, and each weapon will fire their own shots. the bug was that when a unit shot another at close range, it would deplete the projectile counter and send the signal for next state, but new projectiles would be created, so the unit could die during transition but still take the turn, and would then be unable to move, causing the game to get locked.
I have been solving that and other difficult to reproduce bugs, like the camera positioning. I managed to fix some of the behaviors of camera. camera clipping I believe is now impossible, at least until I refactor the camera system.
I also improved the ai for now, it was halting resources and lowering FPS during the first phase of enemy turn, I added a counter that when filled awaits to the next frame and resumes, this adds some wait time to the enemy ai but FPS is maintained.

I also added a menu with settings, it helps with testing.
There are messages that now appear between turns that say "PLAYER TURN" and "ENEMY TURN".
And the camera no longer turns violently when moving in diagonals, but still does on corners.

I have also been working on assets and figuring out mechanics. The mech is finally finished, but I still have doubts about the head and weapons:

I might rework it again.

I also thinkered again with the lighting and painted a concrete texture. here's a (the first) higher resolution picture of the
game:

next milestone is adding the mech to the game, create a new class for mech, and implementing new features like heat and more precise localized damage, and breaking of parts of the mech.
There's also a morale feature that's on halt but should be easy to implement (the blue bar).

I'd like to comment but I don't want to comment on things that are not relevant for your current milestone.

please, do comment. better to hear it now than when it's too late.

xyz thank's for the advice, I will rework the head again and maybe the arms, then I will look at what can be done about the proportions.

xyz Always make mech heads small (in proportion to the torso), low hung (it can safely go below the shoulder line), possibly even completely fused with the torso. This makes the mech more bulky, brutish and menacing, which is typically a vibe you'd go for with mechs. The big head in your current design makes it look kinda chibi, and therefore - harmless.

yeah, I didn't have an initial idea when designing this, it was supposed to be a "basic" mech, so I tried to make it as uninteresting as possible, as I was saving ideas for other mechs.
But bulky and brutish is just ONE of the forms for a mech, one of the ideas is for a fast and agile mech or a glass cannon that's fragile but full of weapons, and also a bigger, heavier mech.
If all the mechs are the brutish type, the heavier mechs will not look as menacing

xyz For same reasons, it's better to keep the pelvic floor as high as possible, making legs much taller than the upper body. Shorter legs, again, suggest child-like proportion, which is not a good connotation for mechs.

I was going more for a gorilla. gorilla's have short legs and long arms.

xyz Also, for plantigrade configurations, large feet suggest more weight, which is another quality you want to have in a mech design.

I'll look into it.

xyz And last but not least, there's no limit on how big a mech's guns can be

those were supposed to be the small cannons, but I will rework the gun slots since it doesn't look as good.

xyz On a more subtle note, there's a very useful principle concerning shape and detail distribution in visual design, called big-medium-small. Applying this principle can help improve designs of any kind. It's a very good tool to have in your toolbox. Check out this presentation focused on big-medium-small in context of concept art and 3D modeling.

I watched the video, I think it's like another theory I knew about that's about distribution of detail, where areas must have few or no detail and others should have more detail.
I was going to do that with this, but the details would be added later on the higher-poly model and texture.

Thanks for the advice!