|
Zizi posted:Most of the pros/studios I know do art assets and stuff in-house, scripts a mix of the in-house you need and some awesome Asset Store scripts that save you a bunch of time and are useful(IE: 2D toolkit, Playmaker, NGUI, etc). That's good to hear. I usually have a habit of creating everything myself, even if it's already been done and open source (because, dammit, it's my way or the highway!) but in the case of Unity it's just a scary amount of programming to think about doing by myself.
|
#
?
Oct 15, 2013 04:55
|
|
|
|
| # ? Jun 6, 2024 08:12 |
|
|
xzzy posted:Isn't Unity overhauling their GUI features in the next release, making NGUI potentially redundant? It's not coming in 4.3. Only the new 2d stuff.
|
|
#
?
Oct 15, 2013 05:09
|
|
|
xzzy posted:Isn't Unity overhauling their GUI features in the next release, making NGUI potentially redundant? It's going to be a while-- UI won't be out in 4.3-- just sometime in 4.x. Also, ArenMook, the guy who develops NGUI and Unity hired to help them build the new uGUI, has been pretty forthcoming on that score. Essentially, what he's said about it is there's a tradeoff. uGUI is faster(of course), and integrates a bit tighter, but it's held back somewhat by having to adhere to Unity's UI guidelines for the editor and the way Unity wants it to work. NGUI will still have a place simply because it a) works pretty well with Unity anyway (he's been allowed to take a lot of what he's learned and apply it into NGUI) and b) isn't tied down by internal convention, which means the editor experience for NGUI is sometimes just a bit better due to not being as consistent with Unity's sometimes iffy conventions. My suspicion is a lot of people will go uGUI for mobile due to performance and NGUI on standalone and web because the workflow's a little better.
|
|
#
?
Oct 15, 2013 05:15
|
|
|
Zizi posted:My suspicion is a lot of people will go uGUI for mobile due to performance and NGUI on standalone and web because the workflow's a little better. Honestly, I expect uGUI to become yet another half-baked Unity feature that no one but freshies uses. They are... not very good about making their extensions actually work the way studios need them to work - they always end up leaving critical features off, or not designing them to be extensible, or whatever else. They might just have had a bad run lately, but their latest effort, Animator, is a freaking embarrassment once you get past the "oooh retargeting" stuff that turns out to be a mostly useless gee-whiz feature. It's half-baked, and needs another 6 months of dev, at least. Hopefully, we'll see it improved, but it hasn't as of yet. Shalinor fucked around with this message at 06:02 on Oct 15, 2013 |
|
#
?
Oct 15, 2013 05:58
|
|
|
Yep partially because unity pointlessly closes off their official plugins too much. Why do I have such little access to nav mesh data? Why is mecanim api access a year later still incoming? Frustrating! The 3.0 update to ngui looks to be the good stuff from ugui rolled into it already. I haven't had time to dig in too much so that's just from watching Aren's presentation and looking at the release notes.
|
|
#
?
Oct 15, 2013 06:55
|
|
|
Obsurveyor posted:Why are you implementing the knockback over time instead of just doing it all at once from the perspective of the projectile? If it hits a player(that's not the monster) and not shielding, impulse a player by the correct amount once, to knock them back and destroy itself. It also seems that setting the projectile's transform parent to the monster means that if the monster moves while the projectile is mid-flight, the projectile is going to be moved as well, not sure if that is intended behavior or not. Yeah, it's intended. The "projectile" is going to end up a melee attack, just with a fair amount of reach. It doesn't really go that far. I'm doing it over time because simply jumping the target to a spot created some weird issues with collision, namely just trying to set the position inside a solid object. I've tried a few workarounds to no avail, and setting to the projectile's position is worth a try. I really appreciate the help and your offer, and may take you up on it if I can't fix it. At the very least, I can try to better explain my intention and you may have a better solution. Again, thanks for the responses. I really appreciate it!
|
|
#
?
Oct 15, 2013 07:16
|
|
|
FuzzySlippers posted:Yep partially because unity pointlessly closes off their official plugins too much. Why do I have such little access to nav mesh data? Why is mecanim api access a year later still incoming? Frustrating! Yeah, NGUI 3.0 was basically Aren's big push to make NGUI's workflow feel as much like uGUI's as possible ahead of uGUI coming out. It's something he promised to try and do a while back so people that need to transition can do it easy. personally, I'm probably going to just keep on with NGUI, because I like the special editor widgets and so on. Shalinor posted:NGUI is already more than fast enough for mobile (and what everyone uses there), and phones are only getting faster. According to Aren, uGUI is actually quite a bit faster (because the draw splits are more intelligent, it's all in C++ in the engine, etc) and apparently the event delgates are better-designed, but the tradeoff is that you're stuck with Unity's UI conventions, whereas NGUI is free to do workflow and UI however Aren wants(and as you noted, NGUI's damned performant already). The good news is there's a lot of shared skillset between the two now that NGUI 3 is out(and the performance gap has narrowed due to all the re-factoring).
|
|
#
?
Oct 15, 2013 07:33
|
|
|
It sounded to me that once uGUI was released he would switch most of NGUI over to it and just keep the custom editors. Also he had mentioned that he was trying to / had convinced them to keep some portion of the uGUI code as scripts that people could change anyway.
|
|
#
?
Oct 15, 2013 15:19
|
|
|
Chunderstorm posted:Yeah, it's intended. The "projectile" is going to end up a melee attack, just with a fair amount of reach. It doesn't really go that far. I'm doing it over time because simply jumping the target to a spot created some weird issues with collision, namely just trying to set the position inside a solid object. By impulse, I meant a physics impulse. Assuming your objects have mass, friction and gravity will animate the movement of the knockback properly(not just warp the target into a wall or something) including colliding with walls. I'm assuming things are still low enough speed to not worry about breaking Unity's physics, though it is pretty easy.
|
|
#
?
Oct 15, 2013 16:05
|
|
|
Anyone knows any handy resources about the internals of simulation games (ala Maxis)? I've ran into some articles on Sims / SimCity stuff before and they were really interesting and I'd like to know more.
|
|
#
?
Oct 15, 2013 23:48
|
|
|
SupSuper posted:Anyone knows any handy resources about the internals of simulation games (ala Maxis)? I've ran into some articles on Sims / SimCity stuff before and they were really interesting and I'd like to know more. The new SimCity game has a lot of videos on the internal engine design and they're all really really inspiring and interesting. I don't currently have access to youtube but I think this is one of them: https://www.youtube.com/watch?v=vS0qURl_JJY‎ They're on the official SimCity channel and it's about the engine they used called GlassBox. There's an indepth look into every system, water, people, generation of the buildings, pollution maps, production, snapping of parts together, all that goodness.
|
|
#
?
Oct 16, 2013 00:30
|
|
|
They had some great in-depth stuff shown, but modeling after that would be sort of like finding these great engine schematics from Yugo ... Just kidding, my dad had a Yugo and it was a pretty good car.
|
|
#
?
Oct 16, 2013 00:43
|
|
|
Downside being every single feature in SimCity turned out to be a steaming pile of crap.  Lots of good ideas matched only by how poorly they were implemented. Which does makes it pretty valuable for post-mortem analysis for making that sort of game.
|
|
#
?
Oct 16, 2013 00:43
|
|
|
xzzy posted:Downside being every single feature in SimCity turned out to be a steaming pile of crap. Oh of course. But the engine itself isn't to blame necessarily I'd say. That's more the game's rules applied to the engine.
|
|
#
?
Oct 16, 2013 00:44
|
|
|
Chunderstorm posted:Yeah, it's intended. The "projectile" is going to end up a melee attack, just with a fair amount of reach. It doesn't really go that far. I'm doing it over time because simply jumping the target to a spot created some weird issues with collision, namely just trying to set the position inside a solid object. I've tried a few workarounds to no avail, and setting to the projectile's position is worth a try. I really appreciate the help and your offer, and may take you up on it if I can't fix it. At the very least, I can try to better explain my intention and you may have a better solution. Not sure if this is the cause of the problem you're encountering, but I've heard that at least one of OnTriggerEnters or OnTriggerStay (or both!) has a delightful quirk where it refuses to fire if, on its first frame after creation, the collider is already overlapping with whatever you want it to collide with. (Shalinor and a few others discussed the difficulties with this behavior and the workarounds they'd used in their games somewhere a few weeks/months back in this thread, is where I'd heard it.)
|
|
#
?
Oct 16, 2013 00:56
|
|
|
Paniolo posted:I've definitely done a 180 on using unsigned ints. I used to feel that you should use them whenever the quantity you're representing doesn't make sense to be signed. Unsigned numbers act as a promise that the value is non-zero, and in turn, require you to promise that you've done the appropriate checks when you convert from signed. The same is true in reverse for values exceeding INT_MAX. It's a major benefit to have those promises be mandatory in the first place they become an issue.
|
|
#
?
Oct 16, 2013 04:14
|
|
|
I thought the reason for mainly using signed integers was just because they're usually the native processor type. 
|
|
#
?
Oct 16, 2013 05:10
|
|
|
SupSuper posted:I thought the reason for mainly using signed integers was just because they're usually the native processor type. Registers don't have types. Instructions do.
|
|
#
?
Oct 16, 2013 06:09
|
|
|
OneEightHundred posted:Unsigned numbers act as a promise that the value is non-zero Guessing you meant to say non-negative here. In any case your post is a good summary of the way I used to think about it, and is theoretically correct. In practice, and this is purely anecdotal but it's something I've observed again and again, code using unsigned ints is inherently more vulnerable to bugs, largely because you can't trust people to actually do range checks every time they cast from a signed value, and quantities often don't have a well-defined maximum value. The other major benefit is that you can use negative numbers as sentinels which is really useful in games where you don't use exceptions for error handling. e: if there were a compiler flag that would emit a warning any time you used a c-style or static_cast to convert a signed to unsigned number, and then you could use pragmas to turn off those warnings inside some explicit conversion functions with well-specified bounds checking behaviors, I'd be way more enthusiastic about it. Paniolo fucked around with this message at 06:55 on Oct 16, 2013 |
|
#
?
Oct 16, 2013 06:47
|
|
|
Paniolo posted:largely because you can't trust people to actually do range checks every time they cast from a signed value quote:e: if there were a compiler flag that would emit a warning any time you used a c-style or static_cast to convert a signed to unsigned number, and then you could use pragmas to turn off those warnings inside some explicit conversion functions with well-specified bounds checking behaviors, I'd be way more enthusiastic about it.
|
|
#
?
Oct 16, 2013 07:55
|
|
|
OneEightHundred posted:The point is that you have to do those range checks anyway, but unsigneds are more forgiving in that regard because you risk fewer bugs from failing to check for negative numbers. If you fail to range change on an unsigned integer, you'll get a max integer that is NOT obviously incorrect and may well have severe ramifications in your code despite. If you plug an incorrect signed value into a secondary function that does the missed range check, it'll catch the error. If you plug an incorrect unsigned value into a secondary function that does the range check, it will NOT catch the error. Unsigned wrap arounds are an error state that exists between frames... they're effectively impossible to catch unless you happen to do the check the second before you break the value. It's way, way easier to keep signed integer code from exploding. Don't use unsigned. There is almost never a good reason to use unsigned.
|
|
#
?
Oct 16, 2013 14:44
|
|
|
Shalinor posted:they're effectively impossible to catch unless you happen to do the check the second before you break the value. The only hard-to-avoid breaking case with unsigned ints is subtraction that yields negative numbers. OneEightHundred fucked around with this message at 15:35 on Oct 16, 2013 |
|
#
?
Oct 16, 2013 15:17
|
|
|
OneEightHundred posted:It's very easy to check "the second before you break the value" when the code fails to compile unless you do the checks. You don't have to avoid unsigned ints in that case if you just treat static_cast as unsafe. code:Edit: not that I'm strongly agreeing with the opposition premise - those ints being signed wouldn't really make the thresholds-unchecked code any less broken, it just makes it slightly easier to debug.
|
|
#
?
Oct 16, 2013 15:37
|
|
|
So I'm working on a ship-building game, think of it as The Sims or Evil Genius in space. I've got a Ship object, that has multiple Deck objects, and a Deck has a collection of Cells. The cells have a floor and wall property, which I've got working great, but now I'm on to placing objects around. Only one feature will be allowed to occupy a particular cell, so that should be a simple property, but where it gets tricky is that a feature can be larger than one cell. What's the best way to handle this? I'm thinking I could just have multiple cells reference that same feature, but I feel like the feature itself will need a collection of cells that it spans as well. For instance a door is two cells wide, and when it opens it could mark each cell within it as walkable. On the other hand, the cells could just check their feature in the IsWalkable check and the door would simply be blockable or not depending if it's open, so maybe this isn't needed. I mostly feel like I'm not thinking of something that will become a huge problem down the road.
|
|
#
?
Oct 16, 2013 15:53
|
|
|
SlightlyMadman posted:So I'm working on a ship-building game, think of it as The Sims or Evil Genius in space. I've got a Ship object, that has multiple Deck objects, and a Deck has a collection of Cells. The cells have a floor and wall property, which I've got working great, but now I'm on to placing objects around. Only one feature will be allowed to occupy a particular cell, so that should be a simple property, but where it gets tricky is that a feature can be larger than one cell. Sounds good so far to me. Have shared references between the cells to the same large object, no problemo there. You can handle it multiple ways from there; as you said you can have the cells do a check on their object to see if they're walkable. But you could also make it a bidirectional relationship, and have the object have an array/vector/whatever of cell references, so that it can directly update the cells' states. They both work fine IMO. It'll just depend upon how your logic works out which is cleaner. Evil genius on a spaceship? Color me interested. 
|
|
#
?
Oct 16, 2013 16:11
|
|
|
Thanks! My first goal is a ship builder and basic static ecosystem of crew working the stations and trying to get the most efficiency out of the ship. Once I've got that worked out, there will be trading and ship-to-ship combat added as well, but since there's already plenty of games that focus on those things, I mostly want to focus on ship design and crew management. Here's my wiki if you're interested: https://github.com/bsarsgard/warp9/wiki
|
|
#
?
Oct 16, 2013 16:28
|
|
|
Your Space game idea reminds me a bit of SunDog Frozen Legacy on the Atari ST, You flew your ship, if it got damaged there was random damage to system functions, you had to walk through the ship and repair the engines or lasers etc, The number of times I had to disable the guns to get the engines working..... http://en.wikipedia.org/wiki/SunDog:_Frozen_Legacy
|
|
#
?
Oct 16, 2013 16:40
|
|
|
SlightlyMadman posted:So I'm working on a ship-building game, think of it as The Sims or Evil Genius in space. I've got a Ship object, that has multiple Deck objects, and a Deck has a collection of Cells. The cells have a floor and wall property, which I've got working great, but now I'm on to placing objects around. Only one feature will be allowed to occupy a particular cell, so that should be a simple property, but where it gets tricky is that a feature can be larger than one cell. (A utility virtual function "GetOccupiedCells" could return a list of cells based on the known shape and location, for those operations where a list of cells is more practical, such as removing references.)
|
|
#
?
Oct 16, 2013 16:41
|
|
|
SlightlyMadman posted:So I'm working on a ship-building game, think of it as The Sims or Evil Genius in space. I've got a Ship object, that has multiple Deck objects, and a Deck has a collection of Cells. The cells have a floor and wall property, which I've got working great, but now I'm on to placing objects around. Only one feature will be allowed to occupy a particular cell, so that should be a simple property, but where it gets tricky is that a feature can be larger than one cell. What I do is keep track of the shape of the object (the cells it spans and which ones should have collisions) and when the object changes state (door open, door close etc) it just sets the relevant tiles to either air or a dummy block that is only used for collisions on objects. Lucid Dream fucked around with this message at 17:23 on Oct 16, 2013 |
|
#
?
Oct 16, 2013 16:58
|
|
|
I just discovered that JSON.NET is way slow. Like, an entire second to deserialize a 500k level. Any recommendations for faster stuff?
|
|
#
?
Oct 16, 2013 17:08
|
|
|
The shape is a really good point. I need to track the object's orientation anyways, so base location, orientation, and shape should mean it's trivial to determine the cells it overlaps. Also, SunDog looks insanely cool! I'm always happy to find more places to steal ideas from!
|
|
#
?
Oct 16, 2013 17:09
|
|
|
Orzo posted:I just discovered that JSON.NET is way slow. Like, an entire second to deserialize a 500k level. Any recommendations for faster stuff? I'm getting 64ms to deserialize a 481KB level using System.Runtime.Serialization.Formatters.Binary.BinaryFormatter, including encryption. Is that an option for you?
|
|
#
?
Oct 16, 2013 17:19
|
|
|
SlightlyMadman posted:What's the best way to handle this? I'm thinking I could just have multiple cells reference that same feature I think you'd pretty quickly run into the desire to have different parts of a feature have different properties. Consider splitting up features into parts which map 1:1 with cells, then the linking becomes straightforward (cells and feature parts reference each other, parts reference features, features own all of their parts) and you can decide for each property whether or not to set it at the part or feature level. This is all based under the assumption that this is essentially a grid based layout, if features are oriented arbitrarily it's a somewhat different problem. In any case the thing you want to be asking yourself is: what queries am I going to need, and how often am I going to be running them? That tends to drive your design. Paniolo fucked around with this message at 17:24 on Oct 16, 2013 |
|
#
?
Oct 16, 2013 17:20
|
|
|
Stupid Unity question incoming. I know that there are RenderTexture size limits, but I can't seem to find concrete information on which iPhones support which sizes, and same for Android. Also, with OnRenderImage, which passes in a source RenderTexture from the camera - is it safe to copy that source texture as is to another RenderTexture without downsampling or will it potentially run into the size limit?
|
|
#
?
Oct 16, 2013 17:41
|
|
|
Paniolo posted:I think you'd pretty quickly run into the desire to have different parts of a feature have different properties. Consider splitting up features into parts which map 1:1 with cells, then the linking becomes straightforward (cells and feature parts reference each other, parts reference features, features own all of their parts) and you can decide for each property whether or not to set it at the part or feature level. Ooh yeah, that's a really interesting thought. In the instance of a door taking up two cells, I could really have it be a single host feature in one cell, that's linked directly to a child feature in the second cell. It's a slight increase in complexity, but the big advantage I see with it is that it could allow non-adjacent linking. I'll have to give it some thought, as the only features I'm planning right now are doors, computer consoles, and inert boxes like generators.
|
|
#
?
Oct 16, 2013 18:00
|
|
|
Manslaughter posted:I'm getting 64ms to deserialize a 481KB level using System.Runtime.Serialization.Formatters.Binary.BinaryFormatter, including encryption. Is that an option for you?
|
|
#
?
Oct 16, 2013 18:04
|
|
|
roomforthetuna posted:I don't get what you're saying here. I think we're talking about situations like... The D3 gold duping thing might have been caused by a botched conversion, but my question then would be what they're using signed numbers for in the trade system in the first place. Unless you're playing Eve, negative numbers are not valid as any quantity or currency numbers, so why use them? Why risk a dupe exploit if you don't meticulously check that (quantityToDraw < quantityOwned) is also followed by (quantityToDraw > 0) every time? My general view on it is that most integers numbers not directly related to game physics tend to be invalid below zero anyway, because they're for things like quantities and indexes, and most of the difficulty comes from mismatches and conversion rather than arithmetic underflow/overflow. Using signed/unsigned consistently with their purposes (which minimizes conversions) and handling subtraction and casts with caution is easier than checking for negative numbers everywhere. OneEightHundred fucked around with this message at 18:33 on Oct 16, 2013 |
|
#
?
Oct 16, 2013 18:31
|
|
|
I finally solved my problem, and it had nothing to do with code. I did several workarounds to get the attacks to detect differently and apply force differently, but to no avail. Then I put rigidbodies on the attacks themselves and the collision suddenly started working flawlessly. 
|
|
#
?
Oct 16, 2013 22:33
|
|
|
Chunderstorm posted:I finally solved my problem, and it had nothing to do with code. I did several workarounds to get the attacks to detect differently and apply force differently, but to no avail. Then I put rigidbodies on the attacks themselves and the collision suddenly started working flawlessly. Oh, yeah. The Physics system needs rigidbodies. I'm surprised anything worked at all without one.
|
|
#
?
Oct 16, 2013 23:45
|
|
|
|
| # ? Jun 6, 2024 08:12 |
|
|
The grid at the bottom of this page is a good thing to check when your collisions seem wonky.
|
|
#
?
Oct 17, 2013 00:00
|
|