Thanks, all! To the questions/comments:
-
Unity 3.2 looks fairly interesting, but we haven't upgraded to it yet. Past experience has taught us to wait just a bit when we are in a position to do so to avoid potential new bugs coming from the engine. It seemed like a lot of the biggest improvements were for the mobile platforms, but things that were of relevance:
-- Having a newer version of FMOD and better sound playback efficiency sounds quite nice, though it's not something that's been a big problem for us. The streaming improvement on
www.audioClip is particularly nice, as we use that for all sound and music playback.
-- The new debugger/profiler stuff could be interesting, although the debugger nor the profiler tends to work with our games because we have "too much" code. Since they store all their
profiling data in memory in the same process as the game, which is a terrible way to do it. Perhaps this will actually let us use the profiler, we'll see.
-- Some of the editor crash fixes sound nice, though we've mostly learned to work around them.
-- There are some rendering performance optimizations that aren't just related to OpenGL ES, so that could be quite nice actually.
-- The ability to disable log files, and thus have compatibility with the Mac App Store, is wonderful. Waiting to see if Apple rejects things for any other reason, though.
-- It's actually really annoying that they added a watermark to development builds on standalone, but we can work around it.
-- Their "other fixes" section has a number of other fixes to things that we haven't really run into, but which sound like they might fix things customers of ours
could run into.
-- Beyond that, there's not a lot, because we don't use Unity's physics, networking, gameobjects, editor-for-anything-but-compiling-and-editing-the-GUI, IDE, 3D shaders (we use our own), or 3D assets (water, trees, any of that). So there's quite a lot there that's exciting to many Unity developers, but not so much to us, heh.
- Glad the crafting and such sounds interesting!
- In terms of sorting shadows into layers, note that short stuff doesn't have shadows. Grass, bushes, and so forth don't cast shadows at all. Those are what we refer to as "doodads" in the game. The larger "game entities" all cast shadows, though.
- In terms of making the shadows shorter, that certainly would make them less dramatic, and mildly pointless since they would tend to be too close behind their object except in the case of something like trees. If we're going to have shadows, they're going to be flipping dramatic.
- Note that "splitting shadows" and "detecting the intersection" are ridiculously impossible to do in a realtime context. We can't chop up images or detect per-pixel image collisions in a realtime sense. And even if we precaclulated it, the hit to memory would be absolutely astronomical. As in, hundreds of megs of memory. I appreciate that the approach could work in a non-realtime renderer, but there are very good reasons why there is a lot of stuff that is possible in Photoshop isn't possible here.
EDIT: And note I do appreciate the suggestions on the shadows, that probably came out sounding way harsher than I meant it. It's just extremely out of bounds of what can be done in a raster environment.
