Vector Drawing in Code

Much (okay all) of Matt’s design work for Mealtime is vector based. Up to this point we have mostly just exported images of his work to be used in the iOS app just like we would any other graphics. When I started working on the store, which is rather Picasso like picture frames, I decided to take a stab at drawing most of the stuff on the fly.

Why bother when we can just export the images and use them and save some programming time. First, while not a huge amount of data, it will save space in the binary when we submit to the app store. Back in week 4 I talked about about retina images and how their size was bloating our binary already. Remember that normally when developing an iOS app, you include all image sizes you might use. For menu elements, that could easily mean four or more image sizes. We have the iPhone 4s – 6, the 6+, iPad non-retina and iPad retina.

Second reason I wanted to do this was that it lets us be a bit more dynamic. Matt designed the store and other menu elements with different tilt angles on the edges. I thought it might be interesting to take that a step further and allow each element to have a different tilt angle each time the element is created on-screen. So for example, you go into the store menu, back out and into the store menu again, you would see different tilt angles for the same buttons.

Third reason? Why not. It’s a good programming exercise and gives me some, little, insight into more low-level graphics design.

So far it looks good. It has the potential of being rather CPU intensive. Because of the way I am currently coding it I am generating 12 random numbers each time an object is resized (generally only happens once, maybe twice, during the lifetime of an object). But if we are going to have a dozen or so elements on screen at once, that could be 144 random numbers being generated. I’m not sure how intensive that will be to the CPU so I will have to do some testing.

One option I have toyed with if that is a problem is a background thread that generates random numbers ahead of time and puts them in a FIFO queue. The UI thread could then just pull numbers off the queue as needed rather than wait to generate more. If by chance the queue empties then I can still block until there are more random numbers.

Affinity Designer

designer_filetype_iconI’d like to introduce you to an app I purchased today called Affinity Designer. Normally you would probably hear about something like this from Matt, since he is the graphics guy. I was using the trial version for a couple weeks and finally bought it because it was just so dang helpful.

As I said, most of what Matt does is in Vector files and he uses Adobe Illustrator to design them. You see, because of his day-job he has a copy of Creative ClownCloud. I, on the other hand, do not work in a graphics department so do not have access to the Adobe suite, nor do I have $50/mo to buy it. I could get just Illustrator for $20/mo but I really need a graphics program too, so if I’m going to get Illustrator I might as well get the whole suite.

I think Matt is the one that actually mentioned Affinity Designer to me so I went ahead and downloaded the trial to see if it would open the SVG exports he made for me to try working with. See, the real problem is that Matt designs the stuff and then I make it work in code which usually means tweaking sizes and positions of things, even if just a few pixels. That means I can either make changes and then wait, potentially, a few hours for Matt to export new files or I need to work with them myself.

Not only did Affinity Designer open the SVG flawlessly, it actually opened the AI file as well. I have tested about a dozen different AI files that Matt has for various things and only one of them has any visible issue. It happens to be the one with the actual cards in it. One single text layer/object is in the wrong position. I would be willing to bet that we could submit the file as a sample to Serif (maker’s of Affinity Designer) and they would be happy to debug it. I will probably do that at some point but for now it’s 99.99% accurate and that’s good enough for me to do everything I need.

It actually looks better than Illustrator and is far easier for me to figure out than Illustrator was. I’ve used Illustrator in the past to create to-scale building “blueprints” for marking locations of network drops and other things. It was a serious pain in the butt to figure out. You can ask Matt, when I was doing it I was bugging him every 10-15 minutes with, what were to him I’m sure, stupid questions. Affinity Designer has been a dream to work with. It just makes sense.

If you have any need for an Illustrator replacement, I highly recommend you take a look at Serif Affinity Designer. The cost? A single month’s worth of Illustrator. Yep, $50 in the App Store.


Speaking of stores, I mentioned above that I had begun work on the Store. I should probably clarify that I am only working on the UI. It will be some time before we actually start working on doing real purchases, since we don’t even know yet exactly what we are going to sell. We have some general ideas but nothing concrete just yet. Lots of stuff to sort out first.

Matt has said a couple times that we don’t want the store to become something that peopleĀ must use. We want it to be something that they can use if they want to jump ahead, or get past some obstacle quickly rather than trial and error. Evan, Matt and myself really dislike games where we are basically forced to buy stuff with in-app-purchases in order to even play the game. And to be honest, it seems like the most successful games (both in popularity and grossing) follow this model.

Working on the store UI is actually rather fun at this point, partly because of my attempt to replicate Matt’s design work in code. It gets me doing real, raw coding rather than just trying to position screen elements to match what Matt has already done. And now that Easter is over I am looking forward to getting some decent programming time in this week.

Week 6 : Daniel