Heinous Error - Still On Track

Ten days ago I said I was going to release an "early alpha" of an idle game today. This post is not a post to say that I am going to delay that release, but it is also not a post doing the release. I really do plan to make another post this very day on this very blog releasing it.

But I'm not quite there yet.

The one thing I'd like to fix before I get it out requires a little bit of fiddly graphics work, but I think I should have time to get it done this evening. Frankly, if I understood more about how browsers work and how they cache images I might know that I don't have to do the thing I want to do at all, but I'm going to go ahead and do it anyway, because I'm pretty sure it can't be worse, and could be quite a bit better.

Imagine you have an image on your screen which is going to change fairly frequently from one thing to another. One way to do that is to change the image every time you want it to change. Another way is to make one image which is twice the width of the two images, and simply reposition it within an element that cuts off the excess.

I started by doing it the first way, and I want to redo things so that it works the second way.

There are two reasons why I want to do this. First of all, it's possible that the size of the combined image is smaller than the combined sizes of the separate images, but it doesn't seem very possible that its larger. Worst case scenario it is literally no easier to save than the two images side-by-side, best cast it seems like the compression can do better with a larger image than with two smaller ones. Now I'm not actually very familiar with image compression, and I'd almost be surprised if someone couldn't, as an exercise, come up with two very particular images whose sizes added up to more than the sum of their parts for any given compression scheme, but generally my understanding of image compression is that the more uniform the image, the better it compresses - a solid white image is going to compress beautifully, for example. Well, these images I am saving have a lot of white space, so hopefully the compression can do something with that.

Secondly, though, if you download one big image then you get one big image once and just hold onto it for the entire time you run the game. If you swap between images then you need to get one, then the other, then the first one again. As I said, I don't really understand how browsers cache images, but I do know that when I was actively running the game and changed one of the image files the image on the screen would not change, but if it later swapped to it, it would change. That means that at the very minimum every swap between images means a check to see if they have changed with a hash or something, and at worst it means downloading the image all over again.

I looked down the images I am working with and the largest one I have so far is 7KB. That's not really very much, but what if people like the game and share it with their friends? What if this time next week fifty are playing? And if the game swaps that image onto the screen on average every minute? Well, that's 500MB a day. Google doesn't actually publish the limit on accessing info from their free drive accounts, but I read someone doing a test on it that suggests that this might start brushing up against the point where they notice. I do plan to pay for web hosting in the near future, but I haven't actually started doing that yet, and I don't want to get Google upset at me.

For the code this will mean only minor alterations, but for the actual images this means I have to open them up and paste them together. That probably happens after bedtime, so don't expect to see the game up until about 10:00 or 11:00 EST.