Apple have imposed a new requirement that applications have "64-bit support" and are threatening to remove ones that don't from the store. So I'm forced to go through and update all of my older games, even though in reality they still work fine and there is no reason that Apple could not maintain backwards compatibility; they've deliberately chosen to put extra work on developers instead.
Isn't this just a matter of opening up the project, changing one line and recompiling? Should take five minutes, it's not really a big deal? Yes and no. The 64-bit change itself is small but they change enough other things every few months that recompiling against new versions of the libraries doesn't simply work. You get a few linker errors and have to look up the new names for a couple of functions. Or there's a new element in one of the libraries with the same name as one of my variables so I have to find+replace to change its name. And then you run it and find that it's in portrait mode, squished into half of the screen, so you have to look up what changes they've made to how screen orientation works and change a few more lines. Or the graphics are scrambled or just blank because they changed something in how shaders work. Then test everything to make sure nothing else has changed. Then upload it and it comes back with an error, you need to add two more lines to the info.plist file to say that no, you're not going to be using the device camera or location. Upload again, the build is accepted, you go onto the store backend and try to submit the update and it turns out now you need screenshots in three additional sizes. It adds up.
I made a few balance changes too since I was updating it anyway, so I've also updated the Windows build on Steam. I haven't updated the MacOS build because that is throwing me a completely different set of new errors from the iOS ones and forget it.
A while after 868-HACK was first released, I updated it with some changes to how the scoring worked (see this post), mainly making the .SCORE prog worth one less point, which made it less dominant for single-run scores. Now the single-run scores are dominated by scores achieved with the secret level, much higher than what could be achieved with either version of .SCORE. Of course single-run scores are not very important and the game is about carefully surviving for multiple runs in a streak, but it turned out that also nobody wanted to use .SCORE in this context either now. A few months ago moabbe (who for a long time held the top score, and still holds the top single-run score) wrote to me saying "please go back to the original .SCORE, you had it right the first time". And he's probably right? So now I've switched back and hopefully the slightly higher reward for the risk will mean it gets used sometimes; I want every prog to have some practical use. The other changes I made in that update still hold; increasing the rate at which BONUS POWERUPS modify the difficulty was definitely the right choice.
A few other changes. I wrote in this post about how I was slightly dissatisfied with the .ROW and .COL effects; they had been more fun to play with when they only hit once and only cost 3 resources but they overshadowed everything else. Whenever I went back and played the game again I was feeling this more and more. The big silly combos where you .PULL all the enemies in towards one spot and then hit them all at once are a fun part of the game but I was feeling like they were possible a bit too often and so there weren't enough situations where you have to find more specific solutions. So I thought about putting .ROW and .COL back to just hitting once, which makes for more complex tactics; you think more about the fact that they stun as well as damage, and you less often want to use .PULL to set them up because it's too expensive so you're more looking for the right moment when enemies can be tricked into lining up through their own movement. This makes them much more situational abilities, their resource cost is quite expensive for the effect, so I reduced their acquisition cost to try to compensate. I'm not completely sure about this change but let's try it and see!
I found that .WAIT was an ability I almost never use, it's just not very good. Which is kind of funny given how often people are asking for a wait button in my games! So I dropped the acquisition cost to just 1 enemy; it's not a big difference but I didn't have anything at 1 before so it's maybe nice if there is one?
OK time to see if I can compile the rest of my games again.
This comment has been removed by the author.
ReplyDeleteWhat happened to the music?
ReplyDeleteReally good to learn about the 64 bit conversion insights from a top-class game developer.
ReplyDeleteI guess with hindsight, the conversion to 64-bit would have been much less onerous if it were done as soon as Apple made this available? That's not a criticism, since Apple never warned of the 32-bit removal back then!
Please bring this to Android
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDelete