1.5


  • Conveyor belt contents and turret ammo are now saved. As always, this will clear old saves.
  • Fixed routers distributing materials unevenly
  • Capped router item capacity
  • Conveyor belts can now pile up items and stop accepting new ones, instead of stacking them all in one location
  • Doubled countdown time for the first wave of every game
  • Capped turret ammo
  • Changed turret ammo display from a text indicator to a green health-like bar
  • Added additional description information for turrets
  • Healing turrets now rotate toward block targets like other turrets
  • Fixed bug that caused ridiculous amounts of screenshake
  • Other various bugfixes

Files

Mindustry-mac-1.5.zip 52 MB
Aug 26, 2017
Mindustry-linux64-1.5.zip 52 MB
Aug 26, 2017
Mindustry-windows64-1.5.zip 50 MB
Aug 26, 2017
mindustry-android-1.5.apk 23 MB
Aug 26, 2017

Get Mindustry

Download NowName your own price

Comments

Log in with itch.io to leave a comment.

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.

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!

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.

 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)