|
Jewel posted:You can't. You can use an addon someone made called Mecanim Event Manager but even then the events don't fire sometimes if it's mid-transition and basically: Unity is hot garbage and I'm in pain every day until I finish the game I'm forced to work on in unity You do what you're doing by making a totally manual animation system. You make all the play calls yourself, and when you do, you start a timer as to how long the anim is meant to last. Timer falls to the end, call your event dingus. There's a way of asking "is X is still playing?", which you do to catch the worst-case that your animation ended slightly earlier than expected / avoid cases where no animation at all is playing. ... sorry 
|
#
?
Sep 12, 2014 17:01
|
|
|
|
| # ? May 19, 2024 16:26 |
|
|
Jewel posted:You can't. You can use an addon someone made called Mecanim Event Manager but even then the events don't fire sometimes if it's mid-transition and basically: Unity is hot garbage and I'm in pain every day until I finish the game I'm forced to work on in unity Shalinor posted:This. This is exactly what I was dreading. Thanks for the quick replies!
|
|
#
?
Sep 12, 2014 18:17
|
|
|
It looks like they've cleaned this up a bit in Unity 5, with the Enter/Exit states for Mecanim. Really can't wait for that beta.
|
|
#
?
Sep 12, 2014 18:18
|
|
|
superh posted:Speaking of Mecanim, how in the world can you properly check animation completion? We're working on a 2d game that uses converted spriter -> Mecanim animations, and we need events to fire at the end of certain clips. From what we've seen with some off and on googling, the last few weeks, this may be impossible to do reliably? That can't be correct, can it? You can fine an event at the end of the animation by adding an event to the animation clip. In the nightmares tutorial they did this twice I believe but I can't find where it was done. Here is the unity documentation on it. http://docs.unity3d.com/Manual/animeditor-AnimationEvents.html
|
|
#
?
Sep 12, 2014 18:37
|
|
|
Is it a fetchable state or an event? A nicer polling model is sort of lipstick on a pig.
|
|
#
?
Sep 12, 2014 18:38
|
|
|
Stick100 posted:You can fine an event at the end of the animation by adding an event to the animation clip. In the nightmares tutorial they did this twice I believe but I can't find where it was done. Here is the unity documentation on it. We looked at this too, but I think we ran into trouble getting the desired clip, accurately? I think it's down to the transitions - I can't poll the Animator at the time we call a trigger ( or set a state variable), and get the upcoming clip back. It doesn't seem to be there until some indeterminate time after, not even the following update loop. We even messed with checking every update loop but that was fiddly too for some reason and STILL unreliable? Not to mention ugly. I also couldn't find a way to just iterate over all the clips within an Animator, at construction time. Is that also not possible?
|
|
#
?
Sep 12, 2014 19:12
|
|
|
Anyone have any idea how to go about creating water "foam" where the water intersects with geometry? Monument Valley did it really well:   Considering the water moves up and down and the effect still stands, I'm assuming it's done with one of the following: a) Some kind of shader that uses a camera depth texture or something to detect intersections b) An script that detects intersections and draws a foam mesh around the edges c) Spooky voodoo magic I've spend ages scouring but can't seem to turn up much. Anyone got any thoughts? Hanpan fucked around with this message at 19:22 on Sep 12, 2014 |
|
#
?
Sep 12, 2014 19:18
|
|
|
Hanpan posted:Anyone have any idea how to go about creating water "foam" where the water intersects with geometry? Monument Valley did it really well: The other approach is, do it geometrically. Intersect your world geometry with your water plane, extract the intersection polygon, bump the edges out, add vertices, noise the vertices, done. Pretty sure THAT'S what you'd actually want, to get the proper hard-edged look. You'd then render water plane, foam polygon, world geometry. Not great for overdraw, but slightly easier than fighting with bumping the z-depth just enough to make the foam render over the water (which you could certainly do). EDIT: Oh, on the stencil accumulation bit - you'd actually render the geometry twice, once for the behind-water and once for the in-front. End result, the "top" geometry and "bottom" geometry will have stencil value 1 per pixel, and the "water plane" aligned geometry will have stencil value 2. Think venn diagram. I'm pretty sure this approach would be doable on mobile, but then again, the CPU one would too, so long as you weren't running the whole boolean operation repeatedly per-frame. CPU-side one also gets WAY faster if you have representative/low-poly terrain mesh you can sub in for that calc. Shalinor fucked around with this message at 20:38 on Sep 12, 2014 |
|
#
?
Sep 12, 2014 20:09
|
|
|
Shalinor posted:Ho ho I'm smart. Both sound good. I've got to get this thing running on mobile so I guess it comes down to whichever method performs best. I'll see if I can figure it out and post the results for science.
|
|
#
?
Sep 12, 2014 20:32
|
|
|
superh posted:We looked at this too, but I think we ran into trouble getting the desired clip, accurately? I think it's down to the transitions - I can't poll the Animator at the time we call a trigger ( or set a state variable), and get the upcoming clip back. It doesn't seem to be there until some indeterminate time after, not even the following update loop. We even messed with checking every update loop but that was fiddly too for some reason and STILL unreliable? Not to mention ugly. (The game I was working on at the time was an FPS and only used animations as the trigger for the "setting a proximity mine" action - their lovely solution was "well then we'll just disable proximity mines for multiplayer", thus taking away the only thing the game did that wasn't boring "aim and fire" bullshit.) I don't know if this would be an issue with Unity, they were using the previous generation of Unreal Engine.
|
|
#
?
Sep 13, 2014 00:03
|
|
|
roomforthetuna posted:A thing to be wary of here, that caused massive hard to debug fuckups at a company I briefly worked for - if you trigger events on your animations then if you ever run a faceless server for a multiplayer game, none of those events will ever occur in the "canonical" server state, because a faceless server doesn't run animations. Ahh. Thats a good point. Events triggered off animations should only ever modify client state that won't effect the validity of the client to the server. Not an issue if you are making a single player only game. I can see that being an issue with any game engine though that allows arbitrary events to be fired from animations.
|
|
#
?
Sep 13, 2014 00:36
|
|
|
Yeah that's a good point, but this is a wholly single player (and to a large extent, animator driven) game. Well just manually time things out, it appears to be the only safe way anyway!
|
|
#
?
Sep 13, 2014 01:15
|
|
|
One nice feature in Unreal I've found is you can do all kinds of procedural adding of Static Meshes based on variables in the construction script. These show up in the editor and can have static light calculated on them, etc, very nice. You can even have little vector variables you adjust by moving them around like any other object. I also tried doing the same with C++, but it seems like OnConstruction, the C++ "equivalent" of a construction script, is rerun when the game starts so even if the editor lets you calculate light on your procedurally generated content, it's thrown away as soon as the game starts. Too bad.
|
|
#
?
Sep 13, 2014 01:17
|
|
|
Programmer Humor posted:One nice feature in Unreal I've found is you can do all kinds of procedural adding of Static Meshes based on variables in the construction script. These show up in the editor and can have static light calculated on them, etc, very nice. You can even have little vector variables you adjust by moving them around like any other object. yes definitely you could use this to create blueprints that make blocks of level procedurally. I haven't done it yet myself but a lot of work up front would come out with fast level building tools if you did it with enough flexibility.
|
|
#
?
Sep 13, 2014 01:56
|
|
|
one of the first blueprint tutorials is about procedural level generation and they make a wall making BP like that. it's inspirational
|
|
#
?
Sep 13, 2014 01:57
|
|
|
roomforthetuna posted:A thing to be wary of here, that caused massive hard to debug fuckups at a company I briefly worked for - if you trigger events on your animations then if you ever run a faceless server for a multiplayer game, none of those events will ever occur in the "canonical" server state, because a faceless server doesn't run animations. That said, I don't think that it's generally a good idea to trigger things that affect gameplay using the animations themselves if you can use timers instead, mainly because you don't have to worry about blending.
|
|
#
?
Sep 13, 2014 01:57
|
|
|
I'm putting together a highly multiplayer game and one area I'm chasing my tail is finding an appropriate physics implementation. Since it's SET IN SPACE the distances are vast and the velocities are high. The physics requirements aren't very demanding; craft motion & collisions, projectile collisions, basic gravitation. If they're a little bit rough around the edges it's no big deal. I'd love to avoid writing my own. The problem I've been finding is that many available physics engines are oriented towards FPS or racing gameplay. They tend to operate on "human" scales (Bullet especially makes a point of this) and are aimed at applications where the players will be sat in front of a PC with a beefy spec doing most of the work, and rely on syncing the results after the fact. They tend to be single-threaded single-worlds without sharding, high availability, and other handy things I've come to expect from working in the web world. Any thoughts or should I be looking for a copy of "continuous collision detection for dummies"? Jaded Burnout fucked around with this message at 17:53 on Sep 13, 2014 |
|
#
?
Sep 13, 2014 17:50
|
|
|
Arachnamus posted:The problem I've been finding is that many available physics engines are oriented towards FPS or racing gameplay. They tend to operate on "human" scales (Bullet especially makes a point of this) and are aimed at applications where the players will be sat in front of a PC with a beefy spec doing most of the work, and rely on syncing the results after the fact. They tend to be single-threaded single-worlds without sharding, high availability, and other handy things I've come to expect from working in the web world. It sounds like you're looking for a server side physics engine, and nobody does that because the player experience with high-latency physics is absolutely terrible.
|
|
#
?
Sep 13, 2014 18:02
|
|
|
Arachnamus posted:I'm putting together a highly multiplayer game and one area I'm chasing my tail is finding an appropriate physics implementation. Since it's SET IN SPACE the distances are vast and the velocities are high. Paniolo posted:It sounds like you're looking for a server side physics engine, and nobody does that because the player experience with high-latency physics is absolutely terrible.
|
|
#
?
Sep 13, 2014 18:32
|
|
|
Arachnamus posted:I'm putting together a highly multiplayer game and one area I'm chasing my tail is finding an appropriate physics implementation. Since it's SET IN SPACE the distances are vast and the velocities are high. What game engine are you working in and why do you feel the physics system in the game engine is not appropriate? Usually you can impact things like the timing and percision. A highly multiplayer game with vast distances is a very difficult problem. You might want to look at sharding your game space (zones) otherwise every client will have to track everything. If you have a fully deterministic physics system then running it on the client (with server sanity and cheat detection) is the most common implementation because server physics are usually undesirable. However if you have a slower moving game then you could do things like faking a players own actions but showing everything else from the server. In this case server physics might work fine, and latency is less and less of a concern every day.
|
|
#
?
Sep 13, 2014 18:34
|
|
|
Paniolo posted:It sounds like you're looking for a server side physics engine, and nobody does that because the player experience with high-latency physics is absolutely terrible. Think RTS more than FPS, there's no direct controls and no "feel" to worry about. OneEightHundred posted:For the problem of scale, the thing to do is basically create physical areas with localized origins to prevent floating point drift and hopefully limit the number of objects per simulation as well (this also lets you simulate the islands in parallel). To do that, you need a mechanism to transfer objects between those areas as well. This has been the main plan in my mind should I have to do it myself, but I'm assuming I'd have to have overlapping zones to prevent weird behaviour near the zone boundaries. Stick100 posted:What game engine are you working in and why do you feel the physics system in the game engine is not appropriate? Usually you can impact things like the timing and percision. A highly multiplayer game with vast distances is a very difficult problem. You might want to look at sharding your game space (zones) otherwise every client will have to track everything. If you have a fully deterministic physics system then running it on the client (with server sanity and cheat detection) is the most common implementation because server physics are usually undesirable. However if you have a slower moving game then you could do things like faking a players own actions but showing everything else from the server. In this case server physics might work fine, and latency is less and less of a concern every day. I'm not working in a game engine because of the very server-side nature of the gameplay. Any Unity or UDK client I put together would be just one of many ways to interact with the system and it's expected for players to be able to leave and come back while the whole sim continues. To that end any graphics library or player-side physics library could only be used for representing server-side actions. Obviously the only way this can work is for a more hands-off style of play, one without the direct twitch-control gameplay where latency is an issue.
|
|
#
?
Sep 13, 2014 20:30
|
|
|
Arachnamus posted:This has been the main plan in my mind should I have to do it myself, but I'm assuming I'd have to have overlapping zones to prevent weird behaviour near the zone boundaries. Technically you can also use any of the standard engines for the gross physics too, but to do that, you end up adjusting your frame of reference to set object scales within whatever range the engine likes. Unity/PhysX likes stuff around 1.0, for instance, so you might have an "orbital collision space" where your planet is radius 10, your asteroids are radius 0.1, and anything smaller than that doesn't exist. I kinda wonder if this is why you seldom see planets in games anywhere near the scale of an actual planet - because fitting your planets and your asteroids into the same collision space isn't really possible unless they're within 10-100x of eachother, scale-wise.
|
|
#
?
Sep 13, 2014 22:21
|
|
|
Shalinor posted:You can do it with existing physics engines too. Almost every physics engine has some way of separating objects into different, totally-unrelated collision spaces. What you do is create and destroy those spaces as necessary, to resolve interactions in "close" proximity spaces. You then need to layer logic over top that physics engine, probably custom, which handles the gross physical stuff - orbital interactions, planet collisions if you're crazy, etc. This sounds sensible. One advantage of planets is they're spherical and effectively static as far as collisions are concerned. Should be pretty easy to work with. Do you have any recs for engines which would work well as a library for the fine stuff? Best as I can tell Bullet is very popular but the docs are like reading a Minecraft wiki.
|
|
#
?
Sep 13, 2014 22:43
|
|
|
Shalinor posted:You can do it with existing physics engines too. Almost every physics engine has some way of separating objects into different, totally-unrelated collision spaces. What you do is create and destroy those spaces as necessary, to resolve interactions in "close" proximity spaces. quote:I kinda wonder if this is why you seldom see planets in games anywhere near the scale of an actual planet - because fitting your planets and your asteroids into the same collision space isn't really possible unless they're within 10-100x of eachother, scale-wise. Arachnamus posted:Do you have any recs for engines which would work well as a library for the fine stuff? Best as I can tell Bullet is very popular but the docs are like reading a Minecraft wiki. I think you can just check the PDF manual for Bullet though, it's reached the point where it covers what to do pretty well. OneEightHundred fucked around with this message at 05:00 on Sep 14, 2014 |
|
#
?
Sep 14, 2014 04:49
|
|
|
OneEightHundred posted:You could try Havok, it's free now. Ironically you can go back to Bullet once you've learned it because Bullet is a giant Havok ripoff. Thanks. I'm having a look at both as we speak. The PDF for Bullet is a lot clearer than the wiki. It's a shame they seem to both have these FPS constraints on size and mass ratios.
|
|
#
?
Sep 14, 2014 08:57
|
|
|
Anyone here going to Fantastic Arcade in Austin, TX this coming week? A small demo of Dropsy will be playable on the event laptops, and I'll be hanging around the whole time. 
|
|
#
?
Sep 14, 2014 17:19
|
|
|
I have a question about cameras in Unity. The game I'm working on is a first-person platformer. I haven't really had to futz with the camera since the sideways movement is handled entirely by my player movement. Vertical camera movement wouldn't be a problem, except the game has 6-directional gravity (I can fall toward any of the walls, the ceiling, or the floor, and the player rotates accordingly). All methods I know about how to clamp vertical camera movement completely fall apart, so I haven't been able to have vertical camera movement whatsoever. How do I even begin to figure this out? Chunderstorm fucked around with this message at 20:19 on Sep 14, 2014 |
|
#
?
Sep 14, 2014 20:14
|
|
|
I've got a question about cameras in UE4 although the answer is possible platform agnostic I want to add "lag" or "smoothing" to my camera movement. since I set my camera location as a set distance from my player it means it jolts around when the player hits something. the only way I can think of doing this is to get the location a second ago and currently and interpolate between them. but I don't know how to do this
|
|
#
?
Sep 14, 2014 23:35
|
|
|
The general way to do that is not to set the camera at a fixed distance but set its goal at a fixed distance from the player, then each frame move from its current location to its goal location with speed and acceleration that feel natural, which involves quite a bit of tweaking.
|
|
#
?
Sep 15, 2014 01:05
|
|
|
Not sure if it'll suit, but you could attach a spring arm component to your ship and add the camera as a child to the arm. It gets you the goal distance and allows it to move closer etc if it collides with the world and from tank thing test, when the main body hits and moves the camera stays stillerer (it's a word!) edit: now with gif 
Quiet_ fucked around with this message at 10:47 on Sep 15, 2014 |
|
#
?
Sep 15, 2014 10:40
|
|
|
So I'm running into a bit of a design problem with a thing I'm trying to do in Unity/C# Equipment -> Armor -> Helmet I really want/probably need to upcast and downcast as I go, so I want to preserve this. Anyway items are generated based on whatever inputs (materials, skill level, etc) and at the end of the creation process they get added to a generic list. As far as I can tell, everything works well. Item information is preserved, and I can shuttle things around from list to list. But now, I'm running into a problem when I want to instantiate a model into the game world that contains/points to a generated item and I'm not sure how to approach this problem. For example, let's say I generate an item when a treasure chest is opened and I want it to fall out into the game world. I have the item data in one hand and the GameObject in the other. How do I connect them? Actually in writing this I realized a dictionary might work, but I wouldn't have a way to ensure that each item has a unique key (I might have two instances of GameObject longSword coupled to two Sword longSwords, each with different values). I'll try it out now, but if anyone has some insight I'm all ears. Actually, I think that worked! Because they're all instances they have unique instance IDs ~anyway~, so it's no big. Sorry for garbage posting, also, thank you game development megathread for giving me a space to think out my problems. Pentecoastal Elites fucked around with this message at 07:03 on Sep 16, 2014 |
|
#
?
Sep 16, 2014 06:22
|
|
|
Ah, you figured out something so I'll edit what I posted. On the script attached to the GameObject you can just put a variable in as a reference to your sword instance. You do this the same way you would any other kind of variable that's a part of a class. Since you have that reference there you can also then have your GameObject be generic and configure itself based on that specific object. So if you wanted a little label in the corner of it that says the attack power or something that would be easy to do. If you wanted to make things more elegant you could have a single "pickup lying on the ground" object that could be your sword or could be a magic scroll or could be a piece of chicken representing health depending on the details of the specific object instance that's attached to that generic "pickup" GameObject. These kind of generic dynamic GameObjects can be really powerful if you make use of inheritance, and can help you avoid duplicating code or mucking around hand-configuring zillions of GameObject prefabs. So in your chest scenario you have your chest that has references to the instances of objects attached to it. When the chest is opened it instantiates generic GameObjects into the world for each item in the chest and passes the reference to those GameObjects which then configure themselves. When the character runs over the GameObject you pass those item instance references to your player character or your engine modifies the player based on whatever those items happened to be. Then you destroy those GameObjects since you no longer need them. ErIog fucked around with this message at 07:31 on Sep 16, 2014 |
|
#
?
Sep 16, 2014 07:19
|
|
|
Quiet_ posted:Not sure if it'll suit, but you could attach a spring arm component to your ship and add the camera as a child to the arm. It gets you the goal distance and allows it to move closer etc if it collides with the world and from tank thing test, when the main body hits and moves the camera stays stillerer (it's a word!) this effect is EXACTly what I want to replicate, only I can't do it that way. I USED to but I have lots of different pawns in my game to choose from and that means maintaining lots of cameras if say I want to change a camera setting. having a separate camera manager is the only solution I know. I've even tried using BP to add a camera and spring arm procedurally as necessary but the component adding system through BPs aren't flexible enough yet
|
|
#
?
Sep 16, 2014 08:31
|
|
|
Your camera controller should be complicated as poo poo. You might want it to lead movement, lead view direction, bring enemies into view, stop at boundaries and be lerping. always lerping. e: I forgot screenshake. Very important. Dr. Stab fucked around with this message at 22:32 on Sep 16, 2014 |
|
#
?
Sep 16, 2014 14:01
|
|
|
ErIog posted:These kind of generic dynamic GameObjects can be really powerful if you make use of inheritance, and can help you avoid duplicating code or mucking around hand-configuring zillions of GameObject prefabs. I ended up using your advice and abandoned the dictionary after all - it ended up being an unnecessary step when at the end of the day I'm just passing around reference variables anyway. But yeah that's exactly what I'm going for. Right now I'm trying to generalize the system so I have a method that just spits out an instance the correct subclass based on the inputs fed to it, and then be able to access appropriate methods by up or downcasting as needed. And it's working! Once I get it nice and polished the next step is to have have an object database pull from an external spreadsheet to set up input-output chains (so I can write item formulae at work  )Anyway thanks a lot for your input, it ended up leading me down a better path.
|
|
#
?
Sep 16, 2014 14:53
|
|
|
Dr. Stab posted:Your camera controller should be complicated as poo poo. You might want it to lead movement, lead view direction, bring enemies into view, stop at boundaries and be lerping. always lerping. yeah! so far all it does is zoom out as velocity increases but I also can't manage to make it do thy without it feeling horrible. doing the same with FOV also is a hosed feeling. it might not feel so bad but it's when you accelerate and the stop acceleration and the velocity goes up and then down and the zoom effect is in and out and it's a bit horrible I wish there was an easy way to do an average of my pawns location over a second or something, and the only way I can think of doing it is having a massive bucket brigade style delay which I don't know if I am prepared to do. this would probably solve the zoom out thing too
|
|
#
?
Sep 16, 2014 22:28
|
|
|
actually perhaps a bucket brigade wouldn't be so bad if put in a function or something to make it flexible and you might only need to run what 60 variables in an array for one second of delay? e: haha it was actually waaay easier to implement than I assumed, about 20 minutes or so. Will have to fiddle with the amount of elements and timing coz at the moment it's far too much! echinopsis fucked around with this message at 23:19 on Sep 16, 2014 |
|
#
?
Sep 16, 2014 22:29
|
|
|
Are any of the asset store systems any good? I don't remember specifics but I have seen a couple in the past that allow for multidirectional gravity.Chunderstorm posted:I have a question about cameras in Unity.
|
|
#
?
Sep 17, 2014 01:20
|
|
|
joe_eyemobi posted:Are any of the asset store systems any good? I don't remember specifics but I have seen a couple in the past that allow for multidirectional gravity. Joe please respond to quotes after the quote instead of above it makes reading your posts really difficult after many people have been reading here for 5+ years. Just press quote and start typing <- see like this.
|
|
#
?
Sep 17, 2014 02:36
|
|
|
|
| # ? May 19, 2024 16:26 |
|
|
Stick100 posted:Joe please respond to quotes after the quote instead of above it makes reading your posts really difficult after many people have been reading here for 5+ years. Just press quote and start typing <- see like this. Will do, thanks for the tip!
|
|
#
?
Sep 17, 2014 02:54
|
|