Markus
-
Posts
604 -
Joined
-
Last visited
-
Days Won
4
Content Type
Profiles
Forums
Events
Posts posted by Markus
-
-
Sounds interesting. The question is how it detects the other parts. One way could be that it reacts to all parts which are children from the detector. But then the question is if it takes the minimum health from all parts? or the average? Or maybe it can only detect damage from one part, but how would that be clearly communicated? Another way would be to detect damage in an area, which might be easier for some cases, but not so useful for others.
I think it's an interesting part/new tool, but I'm not certain how an elegant implementation for that part would look like
-
I'm not a coding expert, but if I understand it correctly, the PhysX Engine (which Unity uses) uses randomness and approximations to be faster. So it's inherently imprecise
But that's also the reason it still runs reasonably fast enough for our use-case
There are other physics engines which are more suited for games like nimbatus, but those did not exist when Nimbatus started (2013) so we're locked to what we have.
Great infos here on this thread. Another thing which might work. Try to have most of the applied forces in front of the center of mass, so that it's dragging it and not pushing. Otherwise it's like trying to balance a long stick on a finger.
For stability one single VTOL thruster in the front might already be enough to keep your drone stable.
Another tip: Buttons are wireless. This means you can but a button on a decoupler and let it split off in the beginning and you still have a button which works without adding mass. Depends if you're close to the part limit though. In that case just use the "is fuel full" trick as trigger.
-
I definitely see the value for different kinds of TNT. Imagine using cryo-tnt for those damn volcanos
Good ideas here ^^
(insta-dirt sounds super op xD. either use it as a wall for protection, or burying enemies in dirt and let the physics engine squash them to death
)
-
Yup
During our testing phase in a separate branch on Steam we quickly found out that allowing the Factory-Part in PvP is way to OP and it would be hard to balance. Therefore we just simply block it
-
1
-
-
12 hours ago, corona_wind said:
Could you adjust drag according to drone size just before launch? Not by rewriting Unity, just by fudging numbers inside the parts themselves.
Unfortunately not
Technically yes, but tweaking these values will alter the behaviour of the drones (most likely) completely - as it should be because that's what you want And changing these behaviour could potentially break the thousands of drones in the workshop & sumo tournament. Also the singleplayer would feel different and we're too far into the development as that we can change these things too much.
So ultimately we're stuck with the current behaviour of the drone and tweak the game modes to be fun, instead of tweaking the drone behaviour, as that could have too many unintended side-effects
I'm sorry for that, but that's the trade-off we have to do as game developers
-
Lovely ❤️
-
All I can add to the discussion is that the Unity physics engine is not really correct and uses tons of tricks to run smoothly with that many objects. It does have a drag / angular drag value, but I have no idea how that is applied when there are a lot of interlocking joints. So it's very likely that drones don't behave like in real physics. Unfortunately that's not something we can fix
But we still try to balance it in a way that it's enjoyable to interact with
-
I just quickly want to welcome @GizmosBoon. Cool that you come here over from the Steam forums
Quick note: Using parts will probably work differently in the new campaign mode. So parts which are overpowered (TNT
) might still be overpowered, but you are limited in their usage, so that balances it to some extend
Having more options to make TNT more useful sounds interesting. We added a modifiable radius for the TNT in one of the last updates. Let's see what other useful things we can add there
-
The thing corona_wind wanted to point out was, that with this shown drone, the upper afterburner is not overlapping, and the lower afterburner shows overlapping. So it's not about asymmetry of the whole drone, but that the collider of the drone brain might not be perfectly aligned, as both afterburners visually don't seem to overlap, but one is highlighted red anyhow.
In the end it seems that this is just an edge-case in which unity-physics is not 100% accurate with its colliders.
-
When introducing new versus modes (versus race, catch) we revamped the UI code for those areas. Because the close-ups were not needed in the new areas (versus arena, racing arena) and the code is the same as in the galaxy sumo locations, the images disappeared there as well.
With the next update the versus modes are in a completely separate mode, not accessible from the campaign/sandbox. So it's unlikely that we will show close-ups for those modes again in the future. On the other hand, other locations which are not planets are most likely introduced and those might get new close-up images.
Maybe this is a good occasion to show the close-up views we created for all the versus modes, since they probably won't be in the game but it's a bummer nobody will ever see them. I'll ask the team if I can post them here next week
-
@Galaxychild <3 It sounds like you meant Niche. Sorry for the sometimes confusing forum structure. You can post your suggestion here:
https://strayfawnstudio.com/community/index.php?/forum/15-feature-requests/
I will leave the post here, as there are already Nimbatus related ideas, if you don't mind
-
Interesting discussion. I would love to see a proper controller support for Nimbatus, as I think there might be big value for certain players wanting to control menus or their drone by a controller. Also, increased accessibility.
Unfortunately there are some problems which would take quite a while to solve. First being the construction of drones. Finding and implementing a good way of doing that takes a lot of time which we currently can't invest because of more pressing features. The other problem is that we don't have any clever mapping for analog inputs. That means while buttons could be mapped pretty easily, ideally the analog sticks could be used with their intended accuracy. But we don't have a concept of analog inputs in the game, and controlling certain aspects with the mouse (targets for VTOL, directional sensor, weapons) would work differently as well (albeit this one is solvable).
So I think for the time being we can't work on that and you have to rely on 3rd party tools (like joymouse) or other solutions (Steam controller, ...)
I'm sorry for that. Even though we would love to implement many many more things like that, we can't because of time / resource reasons
-
1
-
-
Really cool, thank you for sharing! Maybe one day we will have node-based logic, making explaining such concepts more intuitively understandable and shareable
-
Woops, Bug with the finishing line being detected
(Will fix it shortly. Will then come with the next update. Sorry for that.)
Nice ideas so far
-
1
-
-
20 hours ago, corona_wind said:
That is just weird. BOTH engines are plainly intruding on the collider, but only one collides!
Unity Physics 😓
So even if we show the "real" colliders like Micha said, it wouldn't even be a help, because in edge cases Unity is completely useless
We have to check how it behaves if we slightly adjust the collider and then fix the sprite so it matches the collider more accurate.
-
Here's a screenshot from the colliders. They don't match the visuals for the afterburner. So either we adjust the sprite to match the visuals, or match the colliders to match the sprite
I think we should let it have the exact same size of the normal thruster, then it's easiest to use them together. If the afterburner collider is smaller it might behave non-intuitively and makes building harder.
-
This happens because of the spawning mechanism of the debris combined how the colliders work in the physics engine. We might improve the spawning system in the next update which could minimize such strange behavior.
Thanks for posting!
-
Moved this topic from Nimbatus discussion to Niche.
-
1
-
-
Really cool idea. It would be awesome if such challenges could be directly accessed/shared and voted ingame
If someone wants to make a suggestion in the forum, feel free
How about leaving the Challenges open for one week and then create a new one? Or make a list of all challenges in the top post with links to the people who participated?
Challenges:
"Make a drone that can successfully go around the entire pvp race track without getting destroyed. The drone must only have one engine, and the engine must not be a VTOL."
"Make a spinner that works on planets! The spinner must be able to move in all 4 cardinal directions, and be weaponized. No limits to blocks"
-
On 4/6/2019 at 3:37 AM, SAibot said:
Hey, when do the wheels and such come out?H
Hi @SAibot. We don't have a time-frame yet for when we will release the "Terrain Rovers Update". We also don't yet have an internal date for when we will work on this feature. Currently we focus on improving the main game loop in the "Campaign / progression Update" (a Steam announcement about that will come soon). Additional features will come after this Update.
-
I see what you mean. I think randomness can be a fun thing as long as randomness is a smaller part than skill and does not screw you badly/regularly.
Ideally we would have a deterministic physics engine (which unity does not provide currently) and a physics engine which is optimized for such complex rigidbodies as nimbatus drones are.
Unfortunately the unity physics engine does not provide any of the above, so we have to work around those limitations and design game modes which are still fun even with all those drawbacks.
If you're micro-optimizing in the milli-second region, I agree that the randomness in Unity physics is a big factor and limits you. Unfortunately that's the technical limitation we have now
-
Very interesting discussion here
QuoteIf Markus and company are really looking for a way to make tracks more afterburner friendly, rather than completely overhauling the tracks, I would just have the waypoint shift farther ahead at high speed. Right now, afterburner drones have only a small fraction of a second notice before they enter a turn, the only way to really deal with that is insane angular speeds.
I think this could be a useful setting for the VTOL / Directional sensor. UI wise I think this might be a problem currently, because we're running out of space. But generally I think it's possible to set the distance for the waypoint technically.
QuoteWhen I say digital logic is too slow, I'm not kidding. One gate delay is the difference between steering and hitting walls. The same craft, without the gate delay but with equivalent dead weight, steers well. Perhaps several ticks of logic could happen per game tick, so a detector could fire and an engine could activate in the same tick?
This is a bigger problem currently. We already have some problems with logic gates which don't react 100% deterministic (if I recall correct) depending on the frame rate, even though we have something which is frame-rate independent (the unity physics step function). I'm not sure if we're able to squeeze in more ticks there. I agree with your problem, but I'm not sure if we can solve it this way.
Maybe tweaking the track still is the right decision. The tracks were designed before the implementation of the afterburner, so ideally we would simply adjust the tracks properly, instead of making workarounds. But the idea about the custom waypoint distance is a nice way to micro-optimize your design I think.
-
Ah, I see. Sorry, you're right. Steam calls these accounts limited/unlimited. Only if you bought games in value >=$5 you become an unlimited account and are able to write reviews (and more). Below that threshold you're considered a "limited account" and are restricted in certain actions. Now I get it, I'm sorry for the confusion.
-
Yes. We allow for systems to be full of arenas, but the chance of them appearing is low. We tried to balance the chances in a way that the likelihood of a dead-end by "arena-only" star systems is very low (albeit possible). So ideally there should always be a way around those systems.
-
1
-
boncy block
in Drone Part Suggestions
Posted
Sounds like a fun idea. We already have springs, but they are not omni-directional like a spongy ball would be. I'm not sure how possible such a construct is with the unity physics system, but it certainly would be a fun part to add to the game if we could find a good working solution. Thank you for the suggestion