Super Happy Fun Block has been in development for 3 years already! That's a pretty long time, especially considering I thought it would only take a year to make! So what's been going on?
A Little History
Super Happy Fun Block started as a side project. I worked full time as a programmer and then came home and worked on SHFB late into the night. During the year or so this went on, not a lot of progress was made. The original plan was to get a working demo, iron out the game's architecture, and then get friends to help me finish the rest. Why did this never happen? I enjoyed the programming more than I thought. I worked on games as part of my real job and in college, but I'd never built one from the ground up before by myself. The game became my baby and I didn't want anybody else touching it. This was the first bad decision I made (and continue to make, oh the hubris!). In fact, I don't just do all the programming - I do all the art too. During this year I got a playable demo working on an iPad, an in game level editor working (best decision ever), but there wasn't really much of a game yet. Disappointed in my progress, I decided things needed to be accelerated. I quit my job and began working full time on the game! Since then I've gone through about 2 giant code refactors (worth it?), thrown out all of my art once and most of my art thrice, remade every level twice, and had several existential crises. The result is that there are now 3 playable worlds (with varying numbers of levels) and I've gotten and incorporated a ton of feedback! WHEW!
Architecture
SHFB uses box2d for physics and cocos2d from the beginning. They've both been pretty easy to work with, though a little hacking has had to be done here and there to handle how often things disappear and reappear, which box2d does not expect to occur.
I decided to make the objects component driven early on. I can't tell you what each components job was originally, but it was not well thought out. Objects now have 4 components: Physics Component, Sprite Component, Sound Component, Update Component. Each component handles pretty much what the name implies. The Physics Component builds the physics object and updates information when collisions occur. The Sprite Component handles creating the sprite, adding it to the screen, loading and playing animations, and color changes. The sound component loads and plays sound effects. The update component is the actual objects logic. How should it move? How fast should it move? When should the other components play animations or make sounds? If I did another big refactor, which I would not do, I would probably get rid of the Update Component and instead make objects extend the GameObject class. Oh well, not a huge deal. Each component is also largely data driven. This means most objects, despite having different animations, sounds, and body sizes have the same Sprite, Physics, and Sound component. Every object has a unique Update Component.
The "Game Loop" largely takes place in two places: The LevelLayer and the WorldManager. This is another spot where I made a mistake. There's not a pretty blurry line between the functionality of the two. Much of the functionality in the LevelLayer should be in the WorldManager, but would now be hard to move.
Art
The general style of Super Happy Fun Block has not changed at all, but it's actual implementation has. I knew I wanted something cartoony. This would make the game easier to animate, easier to color, and easy to parse when looking at it on a small screen. Because the mechanic is color driven, I decided to make everything that wasn't part of the puzzles black and white. This means the game is mostly colorless. Was this a good decision? It's hard to say with certainty. A lot of my friends have told me that colorful backgrounds would look nice, but I believe it would interfere with the mechanic and make things more visually confusing. Unfortunately, it's surprisingly hard to make grass look like grass without a splash of green.
Character Design has changed a lot. Ball, the main character, and the Blocks look pretty similar to their original versions -- though much better. The humans in the world have gone through several changes however. Originally they were larger and lankier, but this was difficult to animate and looked weird standing next to Ball who despite appearances is also a human. Over time they shrank and were given bigger eyes so they would appear more expressive. Some designs also had everything that wasn't Ball be relatively angular and square. This looked pretty bad and was quickly abandoned.
Animation has been a struggle. I have no formal animation training, but I picked up The Animator's Work Book on Amazon and it was a godsend. Keeping my main character and enemies simple also helped a lot. Additionally, to save myself time, animations are generally done at 10fps (even though the game runs at 60fps). Because it's pretty cartoony anyway, the animations still look great! I'm sure an animator would notice it, but no play tester has ever picked up on this. To be honest, I'm quite proud of my work.
Backgrounds were also a struggle - made more difficult by the lack of color. It takes me longer to make backgrounds I like than to make animations. Thankfully, I don't have to draw a unique background for each level. Since the game is on an iPhone, that would be pretty impossible to pull off (I don't want the game to be more than 100mb or so). Instead I create things that can be tiled or just repeated nicely on different layers.
Design
While the mechanics of the game haven't changed much from conception, the puzzles have gone through a number of changes and the levels are constantly evolving.
One of the goals in Super Happy was to have no filler puzzles. In each puzzle, you'd be using the mechanics in a way that felt new and interesting (excluding the very early tutorial levels, which have some repetition to help people learn the controls and how objects can be interacted with).
A second goal of this, was not to just keep adding in mechanics and objects every few levels so things felt different. This means I didn't just add in an object for a single puzzle. Objects and mechanics that are introduced had to pass a litmus test of sorts. If I can't get at least 5 interesting puzzles out of them, then they aren't worth putting in the game.
Level design has changed a lot as I've incorporated feedback from user tests. I'll do an entire post on this in the future.
