Housekeeping

Running a little late on the post this week. Somehow the week ended before I realized it. Most of this week was spent doing some housekeeping on the Mealtime app. Matt has been working on the BBQ deck and I haven’t been able to come up with any major work that needs to be coded. Truthfully there is still a lot to do, but we are in that weird spot where the app works but isn’t finished. That means the driving desire to “get it working” is no longer there.

So I have been doing housekeeping jobs on the app. I made some tweaks to the graphic files that shrunk them nearly 3x with, from what we can tell, no loss in quality. Each game card was running a resolution of 600×840 pixels at about 85KB. There is only one place where the card is displayed at anywhere near full size, the deck browser, and even then I think it gets scaled down about 30-40% anyway to fit on screen.

Matt renders the graphic files out at over 4,000 x 5,600 and then I use a script to shrink them all down to our desired 600×840 size. The script was doing a high quality down sample resize. This means the image looks much better but takes up more space because it introduces anti-aliasing effects, which drastically reduce the compression levels around those pixels. We switched to a low quality resize. The new images looking a little more pixelated around the edges, meaning the angled lines don’t have anti-aliasing to make them look smooth. This reduced the file size of each card to around 24KB. The entire deck went from around 3.6MB to 0.6MB.

Because the image size of 600×840 is still far larger than we need, by the time we scale them down to the size we actually display them at, we couldn’t see a difference. For example, on the game screen when the card is in your hand the largest size it renders at is 170×238, and that is on the iPhone 6+. Other devices have a smaller render size. Most are at 110×187. So we are still scaling the images down by 3 or 4 times. We did some before and after compares and couldn’t really see a difference, so we called it a good decision.

Some of the other housekeeping tasks I have been doing is to take what Matt has made for generated graphics and convert them into dynamic elements on screen. I believe I talked about this a bit last week. I’m still working on various pieces. This again reduces the size of the application binary, but it also gives us a little more control over how things look in game. If we want to try a slightly different color for something we just change a single setting in code and run again. With static images Matt has to make the change, export it, then I import it into the app. Usually with a few resize operations in there somewhere.

State of the App

So, just where are we at with Mealtime Sabotage? Well, as it stands right now we have two single-player levels. The first is the Taqueria and the second is the American Diner. Matt is currently working to finish up the third, BBQ, but it isn’t done yet. We track lots of information about each game. Did you win, lose, tie, total calorie count, etc. We also have the first in-game currency implemented in terms of earning mints when you win.

Multiplayer is functional, but has far less testing done on it. This is where dedicated devices come in handy. In order to test Game Center functionality your device needs to be in Sandbox mode, which will break any other Game Center app. Or at least it will potentially break. Some games only use Game Center for achievements and taunting your friends. Those games are just fine. Games that use GC for match making will basically break becauseĀ all apps get put in Sandbox mode instead of just the app you are testing. AppleĀ really needs to make a way to put only a single app in Sandbox, or automatically put “sandboxed” apps in Sandbox mode.

Anyway, because of that it is rather difficult for us to play multiplayer games with each other for casual game play testing. We need to just start doing it and force ourselves to play multiplayer a little every day. Anyway, as I said Multiplayer is functional and, as far as we know, works. The only real difference between single player and multiplayer is the inclusion of the network protocol. The actual game mechanics don’t change. In single player your own device decides what move to make for the other player and injects that move into the “move list”. In multiplayer another device injects the move into the “move list”.

We do not really have anything for the Store yet other than a very basic template of an interface. You can’t actually buy anything yet and we haven’t decided on exactly what will be up for sale anyway. We are still trying to figure out all the ratios and everything for the in-app-currencies. Once we figure out some of those things we can start solidifying what will be in the store and start building up the interface a bit more. We will likely throw some placeholder stuff in in the next week or two so that we can get an idea of how the interface works on different devices.

There are lots of other things that still need to be done. We need sound effects (even though almost everybody turns them off first thing), options/config menu and that is just for starters. This is where things get difficult for me as a programmer. It’s hard to stay motivated after “it works” even though there is so much work left to do.

Week 8 : Daniel