🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

Anuke

25
Posts
38
Followers
A member registered 1 year ago · View creator page →

Games

Recent community posts

Alright, I've added it to the development code, although the keys are E/R-- I didn't want to re-map the current rotate key and confuse people.

You can save your game, but only on PC or Android. The web version doesn't support saving (not yet, anyway).

Are you referring to rotating blocks that are already placed, or blocks that you have selected?

The Linux version works for me, and I don't have a mac, so unfortunately I have no way to test it. The binary file format seems to be correct, so I don't think there's anything I can do. Sorry.

I'm planning on implementing large multi-block turrets and walls in 3.0, which should address the one-shot problem. As for sorting, that should be coming in 3.0 too, when I implement block configurations. Teleporters might help with that as well.

..?

Thank you! A comprehensive tutorial is already planned for 2.3, and I'll see if I can implement the conveyor warning, if it doesn't end up looking too intrusive.

Replied to G3l0 in Mindustry comments

Not yet. Future versions should be able to support this, though.

(Edited 2 times)

Do you happen to have a screenshot of the error message? It would also be helpful to know what platform you're playing on (PC or Android).

EDIT: I did some testing, and found a major issue-- did you happen to have any empty conduit blocks placed on the map? Those cause an error when saving; I'll upload a fix now.

Are you referring to...

  • the method of obtaining it? You can get water by placing a pump on a water tile, then laying conduits away from it into the block you want the water to go.
  • the method of transporting it? Use conduits; they transport water similarly to how conveyors transport items. The Liquid Router also works the same way as the normal router, so you can use that to split a conduit into 3 other conduits or blocks simultaneously. 

It's also worth noting that you can lay conveyors across water to act as a walk-able bridge.

Replied to carrot-dev in 2.0 comments

Nope, it's not that either. Even with instant turret rotation, they're still somewhat inaccurate, and I made sure to target the center of the hitbox.

1. This is intentional. My reasoning was that player could theoretically chain a bunch of them together in a line and use them as faster conveyors, which was undesirable, although I never tested whether this "exploit" was actually viable. I guess I should enable it now?

Replied to carrot-dev in 2.0 comments

I did test the Flak turret, and added the overPrediction variable to it yesterday after seeing that it tended to, well, over-predict. After checking the enemy and bullet velocities to be correct, I tested again (today), and it seems that the prediction fudges up most when (1) the enemy is one of the "fast" ones and it's moving at least 45 degrees while the bullet gets there, or (2) the enemy has just gotten in range and the turret fires almost immediately without rotating all the way toward the target. However, even after completely removing "smooth" rotation and/or adding a condition to fire only within 1-2 degrees of the target angle, the inaccuracy persisted, so that can't be the main cause. I ended up removing the overPrediction variable, since in some cases it tended to under-predict as well.

You're right that there shouldn't need to be any tweaking necessary, but at this point, I have no idea what's causing the inaccuracy and it would be easier for me to just buff the mortar turret in some way to compensate for this, instead of spending hours bug-hunting.

Replied to carrot-dev in 2.0 comments
(Edited 1 time)

Currently uploading a fix to all of the issues, except the ones with turret prediction. 

I attempted to reproduce the bug, but while the turrets were slightly over-predicting enemy movement, I didn't see any major problems with them. And, no, the prediction code is the same as for other turrets'. Was the inaccuracy, perhaps, happening at very close range?

(Edited 1 time)

Is there a particular block you're right-clicking that causes the crash? I really have no idea what this could be caused by, so I'll see if I can implement an error reporter later.

Hmmm, does this crash happen when you do something specific, or just right before round 20? Which platform are you on (e.g. web/android/PC)? There's a known bug [which will be fixed next release] where placing a junction causes a crash; could that have been it?

Yep, sorry about that. That bug should be fixed in the next release.

Replied to carrot-dev in 1.5 comments

 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)

Replied to carrot-dev in 1.5 comments

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!

You can remove blocks by holding the right mouse button on them (or, on Android, by pressing and holding a block ).

Thanks! I was planning on implementing a difficulty slider, but ran out of time. And yep, Super Crate Box was one of the inspirations for this game.

Those aren't supposed to be there; I forgot to remove them while testing combat. Use the mouse instead.

(Edited 1 time)

Which browser are you using?

EDIT: if you're referring to the attack keys in the "controls" menu, those are unused (I was testing out combat and forgot to remove them). Just use the mouse instead.

If you're using the starter sword, most enemies can be killed with one or two charge attacks. Perhaps this should've been more clear, but the staff is only supposed to be used in situations where it's very hard to use a sword, and thus staves have very low damage. 

As for weapon switching, I'm not sure how to make it easier-- there's already scrollwheel and number selection support...?

This was made using libGDX and Java. (I wouldn't call it an engine, really-- it's more of a framework)

@Yriclium Ah, sorry about that. I think I fixed most of the crashes in a post-jam version of the game (which I will release once judging is over)