Reasonably efficient y-sorting in Unity with 2D Toolkit

It’s been quite some time since I’ve posted anything – we’ve been busy launching Letter Quest Remastered on Steam, launching a game at my day-job, and all kinds of other things. I’ve finally found a bit of time to start getting back into some coding, so it’s about time I start posting on here again! 🙂 I’ve been learning how to use 2D Toolkit more effectively in Unity – Letter Quest Remastered uses 2D Toolkit for most of the in-game art, with all of the animations being handled by the awesome Spine animation tool. The new game idea that I’m thinking about tackling next requires sorting all characters and enemies on the screen by y-value, so that things that are closer to the bottom of the screen will appear over top of things that are further up (back). Without doing any y-sorting, you get results like this: You can see that there’s no sorting going on, slimes are overlapped at random (actually based on the order that they were created). With a bit of y-sorting, we get a much nicer result: Unity makes it very easy to do this sort, it’s actually just one line of code in an Update function in each class, and takes advantage of a renderer’s sorting order: void Update() { mRenderer.sortingOrder = (int)(mScreenHeight - this.transform.position.y); } I can get away with simply using the transform’s y-position, because with the way I have everything set up, that actually corresponds to the bottom of my enemies. You might have to do a bit of offsetting based on the height of your enemies – you generally want a sort like this to be based on the bottom of objects. To make this more efficient, you could set the sortingOrder of all objects from a single Update function in a manager class, and you could probably get away with calling it 10 to 20 times a second, instead of every frame. I don’t need the performance (yet!), and I also have other logic in Update for each enemy, so it makes sense to do this in each enemy’s Update...

read more

Apple’s new Advertising Identifier Usage and App Updating

We recently released a huge update for Letter Quest, and when we went to submit it to Apple, we were presented with some new popup asking all kinds of questions about an advertising ID, whether or not we were using it, and how we were using it. I read up on it and figured out how to answer everything, and submitted the update like usual. A week later, the update was rejected. The reason given was that we were using the advertiser ID in our app, but didn’t have any ads. Strange, I could swear that we added AdMob banner ads and Vungle video ads in the most recent update. A quick test in the app and yes, both of those ad types are actually in there (until you buy something in the game, then they’re removed). So what gives? Turns out that Apple reviewers probably don’t spend a lot of time testing each app update they receive, which makes sense given the volume they must deal with. However, the ads in Letter Quest are quite easy to find. So I assumed that our app actually was okay, and should be approved, so I entered an appeal to the rejection. Basically I explained in painstaking detail how to find the banner and Vungle ads, how to trigger them, when they show up and under what conditions, etc. Two days later and the update was approved with no changes on our part. So what should you take away from this? If you use ads in your app (iAd doesn’t count for this purpose), then make sure to include very detailed instructions about how to view/access them, how/when they show up, and what type of ads you have in your app in the review notes when you submit your app or app update. All told this silliness caused us to have an app that finally became available on a Monday afternoon instead of Friday evening, which is brutal, considering we tend to see our highest revenue on weekends. Disappointing, but at least it should never happen again – I’ll be giving tons of info with every app review in the notes from now...

read more

Word Definitions in Desktop Version!

It’s been a while since I’ve posted! I’ve been incredibly busy working on the desktop version of Letter Quest! I’m excited to announce that I’ve managed to get the definitions of about 150,000 of our 180,000 words into the game! This is a feature that we’ve wanted to add since the beginning, and it really takes the game from just a fun word game, to one that can actually teach you a little bit as you play! As you can see in the screenshots (which include some VERY placeholder UI, it will be much prettier soon, we promise!), the last word that you spelled will be shown along with its definition in the panel at the bottom-left. Also, as you spell words, if a valid word is spelled, there will be a little question mark button you can push that will instantly bring up the definition of the word you’re currently spelling. We’re trying very hard to see if it’s possible to cram all of this information into the mobile version, but for now this is a desktop-only feature. We’re doing everything we can to make it work on mobile too, but it’s a challenging problem to figure out! As usual, the bandits will try to work their bacon-infused magic to make it happen! 🙂 Here’s some screenshots showing off this sweet feature! If you like what you see, consider voting for Letter Quest on Steam Greenlight, it would really help us out! Have a great weekend...

read more

“Proper” Android Support

Letter Quest: Grimm’s Journey was just approved by Apple earlier today! Very exciting as it’s our first game. Since submitting to Apple five days ago, I’ve been focusing on getting an Android version working. Overall it’s been pretty straight-forward, although I’m not sure that my approach is the “correct” one (if there is such a thing!). I’ve seen plenty of people talking about dpi, if the device is a tablet or phone, different resolutions, etc. Seeing as our game has quite a lot of art that doesn’t resize very well (we do use 3 and 9slices extensively, but that’s only for component backgrounds, buttons, etc. – doesn’t help with icons, etc.), I ended up going with my own approach. My solution is actually pretty simple. I now have 1x, 1.5x, 2x, 3x, and 4x assets for Android. That might seem crazy, but here’s my reasoning: there are so many odd resolutions that are somewhere between what you would use for 1x or 2x assets, for example 800×480 – the 1x assets are way too small, and the 2x assets are way too big. I tried doing some zooming in/out and scaling up/down of the stage, but it always ended up looking pretty terrible. So now I just check the lower of the two resolution values (from the width and height), and use that to decide on which set of assets I use. Surprisingly, this works out for every resolution I’ve tried! I had to do a bit of custom positioning for a few components in the game, such as the battle buttons and the tileboard, but overall everything just worked. Sure, I now have 5 separate copies of all game artwork, but that’s actually less horrible than you might think – all of the 4x images together only total about 9 MB, so in total for all 5 sets of images it’s sitting around 28 MB, and that’s before any kind of optimizing (PNG crushing, etc.). I can live with that! Here’s a screen shot from a battle at six different resolutions, simulating six very different Android devices, just to show how it ended up looking: 1024×600 (we use 1023×600 in-game) Galaxy S @ 800×480 Galaxy S3 @ 1280×720 Nexus 5 @ 1920×1080 Nexus 7 @ 1200×800 Nexus 7 @...

read more

Source Code Visualization With Wordle

I recently heard about Wordle which is a website that will create word clouds from text that you provide. I figured it might be fun to run that against the full source code for Letter Quest. Letter Quest is currently 45,482 lines of code, 37,329 if you ignore comments and whitespace lines. There really isn’t too much to learn from this image, but it is neat to see the game’s source represented this way. Although you can see from the image that I’ve still got quite a few “TODO”s left, mostly optimization items at this point. Also, “public” is used a whole lot, and that is because ActionScript is still pretty slow at making function calls, so I use public vars in a lot of places instead of getters and...

read more