Archive for the ‘Unity3D’ Category

I’m really excited about using Articy Draft for my next project. The biggest issue with it for me is the tool chain. For sure you can buy Articy Access but unless they’ve changed it, it’s about 1700 Euros per project. and it requires the server version of Articy Draft which is way more pricey than the single-user version and more work (I assume) to set up and maintain because of the server component (which I have no need for). So price wise it’s sort of too expensive on several levels and waaay more complicated than I need.

So I’m whipping out my XML and LINQ hats, putting them one on top of the other, and gonna spend some time creating a more universal adapter for Unity3D. In the end I want it to be able to connect up to behavior trees (I’m using Angry Ant’s Behave2).   I noticed that there’s already a product that does some of that, but it’s written in JavaScript (why?) and appears to be simpler than what I want to do.

Honestly, with the zillions of Unity devs I don’t know what the Articy folks don’t make a simple adapter for getting their XML into Unity themselves, aimed at users who are using the standalone Articy.

First DUMB thing I ran into is that at least for Unity 4.2 you have to hunt around the Unity installation to grab the proper assembly for System.Linq and drag it into a plugins folder in your Assets window. It’s about 100 kB but for sure I’ll have to remember to remove it before a final release build. Sigh. Really doesn’t make sense that I can’t use that in an Editor-ish class but I understand why.

More as time passes…

 

51OEmPjLWkL._SL1500_One of the things an iOS developer needs to do is to capture screen shots for iTunes connect. Another is to create a gameplay video. They’re both annoying tasks.

Screen shots from an iPhone or iPad mean that you have to be able to play your game and also be able to press the front panel button and the on/off button at the same time. You need four hands. Maybe your game’s hero or a NPC has four hands, but you don’t. It’s a P.I.T.A.

Trying to capture a gameplay video ought to be easy. Theoretically you can use AirPlay to stream your game to a PC or Mac using one of several programs that will capture your video and save it to a file.  While I’m not going to disparage any of these programs, I did try the most commonly-used one and found the results to be sketchy. The problem is that you’re doing this over your wifi network and I was never able to get a video that would be visually glitch-free for more than a minute or so.

So I started to look for hardware solutions. Fortunately, Apple sells adapters (cheaper on Amazon…) that let you connect iPads and iPhones to HDMI. Web-searching and review-reading led me to the Elgato Game Capture HD. It had mostly good reviews on Amazon ( http://amzn.to/15xHwru ) and to make a long story short, I found it to be a great solution for BOTH the screen shot and video tasks. It’s not cheap (currently about US$ 160 on Amazon) but if you value good results and not wasting your time then it’s a no-brainer IMO.

My experience with it was total plug-and-play. You install the software, plug one end of the USB cable into your PC and the other end into the Elgato unit. You plug an HDMI cable between the iOS device AV adapter and the Elgato unit. I didn’t test it only my Mac Pro but it’s allegedly designed for both Mac and PC.

The software shows you an view of whatever your iOS device is displaying. There’s a delay of a second or two but that’s neither surprising or any sort of issue. The delay is constant so it’s processing and not buffering, which is exactly what you want.

There’s a setup page where you can set options like quality, matching aspect ratio for iPad or iPhone (or Xbox or PS3), and so on. Then you just click a big red record button.

When you’re done capturing, the software takes a few minutes to produce the output file. The Elgato software does have a video editor and that does appear to let you save a screen shot.  I created my videos and screen shots using Adobe Premiere Pro CC. So I can’t comment on the Elgato software editor.

Whatever software that you want to use to work with the video, the Elgato box was able to save a 10 minute video from an iPad 3 without a single glitch or visual artifact of any kind. And that’s great!

Here’s the video. OK, it’s not Hollywood….

 

Every once in a while when surfing the Unity asset store you come on something that inspires you with an idea. Just a few minutes ago I opened Unity and the Asset Store popped up and I spied something called “Circular Gravity Force.”   My first reaction was WTF is that? That sounds stupid!

But my curiosity got the better of me and I checked out this physics script from developer LaneMax. It’s only $5 so I am buying it. Here are a few of the sample videos.

Even the tutorial video is a lot of fun to watch!  http://www.youtube.com/watch?v=SWoUG9UFCwI

This is one of those scripts that gives you all sorts of ideas just from watching it work in a demo vid …

You’d expect that any 3D models that you’d use in a  Unity app would have been created in an external 3D modelling program like Maya or Blender. But there are a few Unity plug-ins that let you model right in the editor. I have purchased two of them: GameDraw from MixedDimensions and ProBuilder from SixBySevenStudio.

Both of these plug-ins let you create 3D models within Unity, and edit them on a per-vertex, per-face, or per-edge basis. GameDraw includes a UV editor so you can even do that task without leaving Unity. ProBuilder has really nice control over many things having to do with colliders. Actually, both have an almost overwhelming number of features, and I’ll gladly admit I have just started using these packages.

If the two companies combined what they have into one product they’d have something so amazing that it’d be unbeatable. More to come as I explore these products further…

Unity3D tech Tales, part 2

Posted: April 27, 2013 in Programming, Unity3D

In the last installment I wrote about supporting different aspect ratios. The second item I mentioned in THIS earlier blog post is: Different levels of CPU/GPU performance.

CPU/GPU performance: I found that the 1.0 version of Numberheads worked great on the iPads and the iPhone 5. Not so great on the iPhone 4 and iPod Touch 4. They ran, but there were “hiccups” when a lot of pieces were moving around or when a lot of animated effects are fired-off at the same time.

Well, this wasn’t that surprising, but i was expecting that since I’d had been able to optimize well enough for the iPad 1 that the iPhone4 would be roughly the same performance. Well, no. Here’s a bit of advice – if you are developing for the iOS market, make it work well on an iPhone4 first, or maybe even an iPhone 3 (which I have not tried).

After a lot of work I identified the two basic problems: the CPU and the GPU seem to be weaker on the iPhone4 than on the iPad1. This is quite perplexing since the SOC (System On A Chip) on both is identical, although it seems as if the iPhone4 is clocked a little slower. The iPhone4 also has more DRAM than the iPad1, but that wouldn’t make things worse. The iPhone4 has fewer pixels, too. I was left with three possible conclusions.

  1. The information on WikiPedia about what’s in an iPhone4 and what’s in an iPad1 is incorrect.
  2. Might have something to do with the difference in physical screen types (retina on iPhone4 and normal on iPad1).
  3. There’s something about the architecture of the device that’s unclear.
  4. It doesn’t matter, I have to make it work (the engineering approach)

The truth is, I could waste a lot of time having fun figuring out what was going on or have less fun figuring out how to fix it.

The solution turned out to be fairly simple. I combined a few smaller texture atlases into one, 2K x 2K atlas. Part of what made this possible was the newer PVR image compressor with an improved quality setting. Previously, I had to have some of the texture atlases uncompressed, at 16 bpp so that they’d look clean on an iPad3 with it’s huge retina display. There are a LOT of sprites in Numberheads: each playing piece is actually several layered sprites. There are also a lot of effect sprites – little puffballs when pieces are removed, several types of explosion sprites, etc. But that’s not really a performance issue (inactive sprites are turned off with GameObject.SetActive(false) ). So combining all the sprites on to ONE big spritesheet was a big deal and only practical when Unity4 came out because of the new “best” quality setting for compression.

I also spent a lot of time code-reviewing, looking for bottlenecks caused by inefficient code. This really didn’t make much of a difference, since of course all of my code was perfect to begin with (channelling my inner Sheldon there).

In the end, the work I did on combining and compressing texture atlases made the most difference. But I was still finding hiccups – brief pauses – only sometimes – when a “bomb” piece “exploded” on the playfield. Those sprites are much bigger than the other ones, so I thought that perhaps it was something to do with having a large transparent area being drawn. But even if I commented-out the explosion the problem didn’t go away.

Light bulb! Turns out that it only happened when a “bomb” “exploded” next to a locked piece. Common to this type of game, a locked piece can’t be moved. But when a “bomb explodes” next to a locked piece the lock gets removed. And when that happens, a counter is incremented that keeps track of the number of unlocked pieces as part of an achievement that the player can earn. Of course, that has to be saved, and right away, too. That’s because with iOS apps you never really know when your app will be interrupted. But I was doing this save as part of the loop that was removing pieces from the board and that was key. I changed things so that the number of locks removed was kept as a variable and only AFTER the entire process was complete was that value saved.

Conclusion: Since this was NOT an issue on the iPad1 (or newer) the only possible reason is that the memory interface to the Flash memory which implements the device’s file system was slower. Both devices were using iOS 6 so that really couldn’t be it. The only other explanation is that this (well worn) iPhone4 that I bought on EBAY for $100 had had so much use that the Flash memory memory was reallocating internally (a Flash memory thing, sort of “self repairing”) because the memory had been over-used. That slows down access time when writing data to the flash memory, often for several hundred milliseconds. Again, the problem was fixed so in the end, I didn’t care.

Stay tuned for part 3 of this riveting series…

In a previous post I talked about a few stumbling blocks to supporting the three different iOS aspect ratios. To review:

iPad, iPhone4, and iPhone5 have different aspect ratios, and the iPad3 and newer have whopping big retina displays. This issue has some simple side-effects, like needing different splash-screen images. Not a big deal. More complex is how to handle this in-game. Do you have different sets of texures for each aspect ratio and maybe different textures for the iPad3 and 4?  That’s tricky if you want to have a “Universal” app; one that can be loaded on any type of i-device, and still fit within that 50 Mbyte OTA download limit. One solution is not to care about the download limit. I didnt’ like that one. Or one could have two different versions of your app. That’s a potential QA problem and Apple (anecdotally) seems to like it better if you make Universal apps.

If you look around on the Unity3D iOS forum there are many many posts about how to handle this, and to be fair, many have to do with true 3D games and I was only concerned with Numberheads, my 2D puzzle game. So I don’t assert any sort of universal solution, sorry.

One way to lay out a 2D game is to have an Orthographic camera, a background image,  and then to layer the other game elements (sprites, control buttons etc.) on top of that background layer. The background layer has no transparency, and the whole scene is often unlit so as to improve performance on mobile platforms. But how to reconcile these three different screen sizes:

  • iPad3 (and newer) 2048 px X 1536 px
  • iPhone4 (and similar sized iPod Touches) 960 px X 640 px
  • iPhone5 1136 px X 640 px

It actually turns out that you can use the nature of the Ortho camera and automatic scaling(note 1) to solve the problem rather simply. Simply use a 1 pixel = 1 game unit sizing scheme for all of your game assets, size the background texture for the iPad3 screen size and then adjust the camera’s ortho size as appropriate. Here is an image that can help understand this:

NHBG_website

This image (you can click on it to enlarge) is a screenshot taken right from Adobe Illustrator. Note that the HEIGHT of the image is 2750 pixels and the width is 1536 pixels. Huh?   That doesn’t make a heck of a lot of sense at first look; doesn’t seem right.  But, if you position the camera “above” the exact center of the image  and pointing directly at it you can then adjust the camera for the different devices. The key is to keep your game elements inside the lines “iPad Top” and “iPad bottom”. The other devices (i.e., not iPads) will have some empty space, that is, the background (whatever you choose to show).

It’s easy to programmatically determine which device you’re on using the iPhoneGeneration enumeration. For iPad-type aspect ratios set the camera’s “Orthographic Size” parameter to 1024, for iPhone4-type aspect ratios set the size to 1160, and for iPhone5-type aspect ratios set the size to 1374. Note that you have to be sure to choose the correct size for iPod Touch devices as well, those are like one or the other iPhone, and note that (as of this writing) all the iPads have the same aspect ratio.

While this may sound a bit confusing, it works because the camera’s presentation is scaled to the physical screen size. Recall that the “Orthographic Size” parameter is “half of the vertical size of the viewing volume” (from the scripting reference). So if it’s set to 1024 for iPad then the vertical size is 2048 which maps 1:1 to the iPad3 screen pixel height in Portrait mode. But on an iPad2 or other 1024×768 devices, this 2048 x 1536 presentation is scaled to fit in that size.

Minor con – you need a huge background texture. But in actuality, if you compress the source image down to a square texture and display that texture on a cube with the Transform scaled to 1536 x 2745 x 1 you’ll have a “pixel perfect” display. That’ll  look great even on the large Retina displays. Be sure to use the “best” RGB (not RGBA) Compressed PVRTC 4-bits compression and the texture will only be 2 mBytes. That’s a lot less space than if you needed three images, one for each aspect ratio.

This actually works in Landscape or Portrait orientations, has been tested on devices, and is in a shipping product on the App Store. Hopefully some Unity developers will find this information useful.

Note 1: The mechanism by which the scaling occurs is way beyond the scope of this post but can be seen by examining a built project’s “Classes/Unity” folder from within Xcode. Clearly I can’t post any of that without violating the Unity3D license agreement.

 

You say you’re a smart dev using Unity3D Pro and you’re trying to make it to the under-50 megabyte OTA cap on iOS and ya just need a little more weight reduction?  Here’s a quick tip: use small, uncompressed png files for your unused splash images.

splashesNotice that since this App is portrait-mode only, there are three potential unused splash screen images. Well, if you look at your Xcode project or an archived build you’ll see that there are some PNG files there for these unused orientations. They’re just the Unity3D logo, but there are several – for normal and retina resolutions.

  • Default-Portrait.png is 59 Kb, Default-Portrait@2x.png is 195 Kb, Default.png is 65 Kb, Default@2x.png is 204 Kb, and so on. If you’re not using them why waste the space? Just add a very small (say 64×64) black texture to your assets folder and use that instead of leaving the Unity inspector setting as “none”.

For example, “Default-Landscape@2x.png” (corresponding to “High Res iPad Landscape” in the image shown here)  is a 64×64 black texture and is just 9 Kb.  Now of course Apple uses its wierd PNG compression and will reduce these file sizes a bit more but you will still save space – try archiving before and after and you’ll always save something.

Why waste the space – save bytes, and take comfort in the fact that when you sell 10 million copies of your masterpiece the energy save by not transmitting these spurious bytes you’ll save people money on their data plans and save enough energy to light a 20 W LED bulb for 29 seconds!

Notes: You need Unity Pro to change the splash screen images in the first place. If you use a compressed texture you’ll get a warning every time you build.