Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

1) Is that to simulate inaccuracy? Apologies if I'm overstepping, I find the simplest way of handling target prediction is,

aimPosition[x,y] = enemyPosition[x,y] + (enemyVelocity[x,y] - yourVelocity[x,y]) * (distance / weaponSpeed)

Which, ignoring acceleration, provides the perfect firing solution - then I add an inaccuracy factor on afterwards.

3) Yeah, stronger rather than more enemies will help, although it'll still likely lag due to the vast number of turrets and projectiles flying around. You could use a fixed time-step; the game would slow down as FPS drops, but it'd avoid the glitching through walls. Pick your poison.

4) I've been in that exact position, needing that functionality, but can't work out how to use the junction. I stuck it in the middle of two conveyor belts in a cross formation, but the resources just stopped at the junction and started to pile up. Maybe I'm just being dumb, but it could do with an example. Perhaps bung one in to the initial base setup at the start of the game?

5/6) Yeah, totally understand. Though I personally find the online highscore the most complicated bit to implement. I don't know what tools you're using; I usually put something together with, node and a small AWS server - but the score verification is always the hardest bit - it's really easy to spoof a highscore in some games.

+7) I also forgot to mention, not a bug necessarily, but when you're building things and run out of a certain resource, it auto de-selects that object, which is a little frustrating cos you have to go back and re-select it each time. Also your gun starts firing on that final object placement as you run out of materials.

Jeez, sorry if I'm bombarding you. I'm a sucker for resource management / tower defence games. Do you mind divulging what code / libs you're using for this? I've been mainly using recently but I'm not sure it'd handle so many sprites as your game requires.

 1) That is the formula I'm using, but after looking into the code, I found that the enemy velocity was incorrectly multiplied by the deltatime. Since I usually test the game at ~1000 FPS, this threw off the accuracy greatly, so during the initial gamejam, instead of attempting to fix it, I just "compensated" by subtracting 0.2 from the predicted bullet speed. Removing the delta and compensation has fixed the prediction.

3) I'll see if I can get a hybrid approach: use variable timestep, but if the FPS falls below a threshold (15), I prevent the used delta-time from getting any higher. So, game slowdown would only occur under 15 FPS, which is (hopefully) above the FPS where things start to glitch through walls.

4) Uhhh, looks like I broke the junction with a recent update. In fact, when I tried to use one, my game crashed. Just fixed it.

7) I'll see if I can disable the deselection and display some sort of error when you place something without sufficient resources instead.

I'm using libGDX, a Java game library, as the framework. I have Mindustry on GitHub, here.

(note: I'm also using a custom library, uCore, which provides utilities for and wraps a lot of libGDX classes, so big chunks of the code won't resemble standard libGDX)