There was a point during the development of VYDE when we were stuck with forty untested levels and a horrible main menu populated with text labels for each level. It was all too convenient, the text labels fit perfectly with the name ‘VYDE’ occupying all of the 6x4=24 tiles on the screen. I needed a reason to fix it up so I decided to double the number of levels in the game.
Initially, I wasn’t going to tell the players that they’re actually descending a building until the last level, but it seemed like a great idea to have an illustration of the building on the main menu itself. An eighty story building didn’t make much sense so we decided to group similar levels into floors where each level becomes a room on a particular floor. Some floors have five to six rooms whereas some have just one. We had with us a list of rooms for each floor, so we decided to paint the building with floor numbers and show the rooms expanded horizontally to the right.
A building on its own wouldn't look nice, to complete the scene, a set of mountains, a sun and some trees were added. All the sprites are given a depth value which is used to calculate their location on screen as a function of the camera position. So the mountains and the sun are given almost infinite depth, whereas the building and menu items are kept nearer to the camera. New positions are calculated every frame when the camera is moved to give a smooth transition as the user swipes between the main menu and level selection screens.
As you progress through the game, the time of day changes from very early morning (around 3 a.m) to daytime (8 a.m) as you make your way to the ground floor. The moon starts from being high up in the sky and disappears slowly into the top edge of the screen while the sun makes its way up from behind the mountains. All the images are being lit up with OpenGL Blend Mode magic, I darken the sprites at night and make them brighter in the day. The sun wasn't brighter than all the other elements on the screen, which I could have solved with a simple Bloom shader, but we figured the flat shaded sprites actually agree better with the aesthetic style of the game. Right now, I'm modulating the opacity of a plain white image overlay on the screen to simulate a cheap tone mapping effect. The overlay goes invisible as the sun is hidden behind the building, and then spikes and comes down back to zero using a logarithmic function over time when the sun is revealed immediately.
All the levels in the game are stored as text files which detail the color for each of the 24 cells, along with enemy and player colors too. On loading a level, the level background image is compiled using a render texture. Now we thought it would be only right that players are able to see the levels on the selection screen so they can recognize it. Compiling and storing textures for all the levels wouldn't be feasible (memory) and compiling the textures for each room when a particular floor is selected would be quite a pain (too much work). The solution to the problem was simple, since the levels are made of six by four flat colored cells, each level texture could be represented by exactly 24 pixels in memory. Cocos2D allows sprites to share a target texture and reveal only a part of the memory using spriteFrames. So the game bakes all the levels onto one small texture when it starts up and the eighty sprites are made with sprite frames of the size of 6x4 pixels. Those sprites are then scaled up to the required size of a clickable tile item on the menu.
Framebuffer Objects - Parallax Scrolling - Faked Lighting - Fun.