Last Bug Squashed!

On my bugs todo list there was still ONE bug remaining. It had something to do with touch. Bugs are mostly easy to solve, but touch bugs are a … little touchy. I will describe the bug in detail. When you select an action verb like ‘Look At’ and you wanted to look at something in the gameworld, but you changed your mind and you wanted to walk to somewhere else, you would stick to the ground as if your soles were nailed to the floor.

Dave will die if can’t walk

Eventually it was a boolean that was unnecessary but blocked walking around.

 

Archived: Uncategorised

Testing, testing, testing….

The Lost Adventures is finally getting into a releasable state. Major bugs are solved and game assets are polished to the max. The only task remaining is testing it on a variety of devices that can have a lot of different sizes. Over the years I collected quite some iDevices. The Lost Adventures is a universal compatible game targeting iOS8 till current iOS version (now 12). I discovered that the game didn’t run smoothly on the lowest specced device show below, and that’s the iPad Mini 1. In the last post I mentioned that this was a problem in the A* algorithm I used. It was really slow and not  optimized. Now it runs OK on that iPad. On all devices I get a decent framerate! And the game is compatible, I still need to check  for memory leaks though!

Archived: Uncategorised

Revisiting AStar performance

I was testing on an ipad Mini 1 and saw there was a noticable lag when the pathfinding had to do its work. I always knew this was not optimally coded. It also was a lot of code, and a lot of code is hard to optimize. So I integrated another AStar implementation into my game that runs much faster. To notice the lag more evidently I zoomed my map  out for a factor of 4 to reach a far away target tile.

Astar was bogging down my FPS

Now it runs smoothly on low end iOS 9 compatible devices like the iphone 5 and ipad air and up.

See the difference in this video :

Archived: Uncategorised

Final Push with Icon Hell

I am going to the gruesome phase of the final push towards the Apple App store.
It is fun to make a game, but it ain’t fun to get all the other assets in the game in order to get the approval of Apple to submit a review request.

That is what I call : Icon Hell!
And hell it was…..

When I started making this game I had the icon assets managed by Cocos2D. This is nice, because with a small number of icons you can get a releasable archive. This was always messy of course, but it worked. Then Apple started with a mechanism called Icon and Launch Assets. This is nice because dependending on the target version you can provide icons from iphone4 until the latest iphoneXS Max.

All is well, all icons and launch screens of various sizes dragged in.

Making icons is still fun
When you have pixelart it is better to make each icon look it’s best

But I knew I wasn’t done. You have to edit info.plist a number of times. Got this error first (did not expect a first time right).

So i scoured the internet and I tried to insert this into info.plist :

	
        <key>CFBundleIconFiles</key>
	<array>
		<string>Icon-60@2x</string>
		<string>Icon-76@1x</string>
		<string>Icon-76@2x</string>
	</array>

When I validated my project (Xcode 9.4.1), I got a valid archive message!? Was this my lucky day?
Nope, I sent the archive to apple for real now to let the validation happen on Apple’s servers.

Then I thought… Icon-76@2x is the correct icon size for that?
After validating a load of times, I discovered that CFBundleIconFiles does not help me at all providing the correct icons.
I removed these completely and started looking for answers on the big bad web….
After many hours and countless stackoverflow suggestions I found a stackoverflow post and it mentioned something about the Target Membership.

This is how my Icon Asset settings looked before I corrected it :

This can be found in the side panel of the Assets folder

This was some remnant of the Cocos2D setup ( I know I should move towards a new framework 🙂 ). So i selected the correct target membership (what’s this for anyway? ) And now it looks like this.

I was certain this was the correct format so this was definitely an improvement. But one validation gave me this :

This was a lot easier, because of the support of iOS 7 I needed to add the following xml to info.plist

	<key>UILaunchImages</key>
	<array>
		<dict>
			<key>UILaunchImageMinimumOSVersion</key>
			<string>7.0</string>
			<key>UILaunchImageName</key>
			<string>Default</string>
			<key>UILaunchImageOrientation</key>
			<string>Portrait</string>
			<key>UILaunchImageSize</key>
			<string>{320, 568}</string>
		</dict>
	</array>

Now the problems are completely gone and can make builds for testing etcetera.
One thing bugged me though :

	<key>CFBundleShortVersionString</key>
	<string>1.0.0</string>
	<key>CFBundleVersion</key>
	<string>3</string>

CFBundleShortVersionString corresponds with Version in the Xcode label and CFBundleVersion corresponds with the Build label. That was a head scratcher too! I think Apple will never name things as they appear in the GUI.

 

Archived: Uncategorised