Post by fazz in 1.5 comments

Viewing post in 1.5 comments

Great game, really addictive!

I noticed a couple of bugs when I played.

1. turret aim is off - sometimes firing in exact opposite direction to enemies. This is particularly prevalent when the enemies are moving. Could be a rads/degs mix up.
2. I quit a game, returned to the menu, then started a new game. The level reset, but my resources did not, i.e. I started with loads of resources.
3. Late waves (40+) I see FPS drop enough that player and enemies start glitching through walls.
4. I can't find any use for the junction tile? If there is a use it needs more explanation.

And a couple of suggestions; Showing turret range indicator while before you place it would be handy. Also, hard to implement, but an online highscore would encourage people to come back.

Good luck with this, it's cool.

Anuke7 years ago

1) I think this is related to target prediction-- when I was making the initial turret behavior, I ran into some problems with aiming and in the end made all of them over-predict. This (should?) be most noticeable for flame turrets. I'll be looking into this for the next release.

2) I'm surprised I didn't notice this bug before! It's fixed now, but I'll wait until next release to upload the changes.

3) This is most likely caused by the sheer amount of enemies and bullets, so the only thing I can really do is decrease the amount of new enemies per wave, and substitute them for more powerful "elite" enemies-- this should also be in the next release.

4) I intended this to be used for situations where you need to cross conveyor belts carrying different types of ammo or resources to different turrets. Maybe not particularly useful, but in my playtime there have been a few times when junctions were needed.

5/6): Placing range indicators should be easy to implement (added that to the list); online high-scores wouldn't be that difficult, but I'd rather focus on improving the gameplay itself first.

Thanks for the feedback!

fazz7 years ago

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 socket.io, 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 phaser.io recently but I'm not sure it'd handle so many sprites as your game requires.

Anuke7 years ago

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)

itch.io

Viewing post in 1.5 comments