Mobile - The Beginning

From where to begin this story of getting to know self better and really getting to know how much do you know to program or not. A little bit before Runestone Chronicles and my one year anniversary i was transfered to work on our soon to be Mobile Team. Our primary focus was porting PC HOPA games to iOS as it was only at that point supported mobile platform by our in-house engine. My mobile experiance in that that was equal 0. Mostly because the iOS equipment was expensive and i really couldn't afford it to self learn it, and as for androids i had a phone just good enough for calls, messages and music. So let us continue to the story.

For someone who had zero knowledge regarding mobile programming i was terrified. In the essence the programming was similar yet there were differences. My first iOS port was game Rite of Passge - Child of Forest Saddly it is not anymore available for download as game is pretty old now. For first project i was given then task and small team, when i write small team, there was me as lead programmer / developer and two additional technical artist / animators. Idea was this: "Convert PC based mechanics to touch based and if there is time add mobile specific gameplay mechanics" We were ambitious and we were caught in the trap, a trap called iPhone 4!
Why iPhone4 you may ask?
In that time iphone4 was our lowest supported device with iPad Mini 1, and these devices had really low target regarding CPU and RAM memory. We were struggling to prepare and optimize our game just a little bit under of 150mb of RAM. Anything higher than that and would increase chance of getting game crashes, not something you want to. At first we cutted the number of particles shown on scene, and this decreased a little bit but just not enough.
What next could we do?
We have notice that all our movies uses theora 10 video codec which is known to be a little bit more memory and space hungy. So we have reconverted all movies to use theora 6 codec. This lowered the total app size but still not the RAM usage. Next thing what we done is changging how movie data was loaded. Instead to be preloaded in the memory, it was loaded only when movie was requested to be played. Although this improved startup memory it gave us problem the more game was progressed.
For current movie implementation we couldn't do anything more so we moved to see what we can do with sound?
Usually on PC the game had several music tracks running for each scene:
*Ambients tracks
*Music tracks
*Effects
Memory usage on music and sound was huge, mostly because music and sounds were not streamable which means they all were preloaded into memory at startup. For iOS version we have decided to remove Ambients tracks and stick with music and effects, and also to convert all sounds to 22khz Mono. This grately improved memory but in my head it was still bangging why the sounds stay still in the memory if i know from the gameplay wise that those sounds will never ever be used!?
So what i can do about it? I have implemented a new option for sounds. Even thought they are preloaded, they will get released few seconds after they are used, if they are requested within that timeframe again, their release schedule was delayed. And this yield very good results but yet again it was not enough...
So what now? Tell our publisher we can't deliver to the requested minimal target device and that we should increase it or try to find next solution?
I usually dont give up that easly and then to be stubourn to try to squeeze every possible idea, solution until I can say " I really tried everything i could think off!". We have started to work on implementing something we called "Dynamic" atlas.
Like in almost all 2D based games, and some 3D games all smaller textures are packed on one huge texture called atlas. This has some pros and cons. Pros: - There are not many draw calls - Less memory is used for textures overall Cons: - You can't use shaders well with atlases - You need to implement it for own workflow for multiple platforms Currently on iOS we use two formats for textures: Anything GUI related is packed onto BMP format textures for best quality and anything gameplay related is packed with compressed PVR textures. Using PVR textures on iOS does have some advantages like texture reading and uploading time to GPU, but has very poor quality visual wise. So we had static atlases and dynamic atlases. Static atlases are textures which once are loaded they are not getting released from memory and they stay locked in memory until game has been shut down. Dynamic atlases are loaded into memory as long it has at least 1 element visible from that atlas on the screen. Dynamic atlases can be controlled gameplay wise but it requires a little bit knowledge in organising all assets. Bingo! This was the thing we needed to lower our RAM usage. Dynamic atlases gave us ability also to not have all Localization wise textures loaded into memory but only those required for current running language.

Mobile - The Path to Better Self

For all our iOS games we had a publisher - BigFishGames and one of their requirements was integrating their SDK.
SDK consists of several features that had to be integrated on all levels:
- Main Application OS Level ( Objective - C )
- Engine ( Communication between Application Level and Game )
- Game / Script ( Communication between game - our scripting language and engine and application level and SDK )
I had already knowledge how to work in our in-house Engine, ( Add some new features, work on new script commands, ... ) but integrating BFG SDK was something new and i could say really interesting. I got to see how big companies and developers work on their technology - Organise Code, Assets... Most time we have spent integrating purchasing process and analytics, the rest was easy. Once we have implemented everything, we have made own workflow and optimized for faster project delivery. After a while team was already releasing multiple project and everything was going smooth until iPhone6 got released. Luckly all this time if i got stuck a got a help from our CTO, but what happened is that he was away for a few days and i had to deliver a product and new iPhone just came out.. I was at first afraid, i didnt know how to solve it yet i had to.If i dont solve it company loses money and potentional all our future projects gets cancelled, if i solved we continue forward. The stress was hight, but in those few remainning day i was able to finally solve it. It was cry or fry situation...Joking xD...It was eaither solve it or fail. This situation really helped me to build up as programmer to work more towards independency. If it didn't happen i probably would be still co dependend in some areas on our CTO. So conclusion is that sometimes things like that needs to happen so we can harden and see where we are.