Level 1 Boss Fight!

Well, August has been very long, hot, and busy but I finally managed to finish the boss fight for Level 1! Here are some of the screenshots that I've managed to take (gotta learn how to capture videos really soon!):



Level 1 is almost done - all it needs are just a bit of polishing and of course, the other big thing in my list - Collidable Terrains!

Cheers,
Jim

Early Screenshots! (Yeah, no video yet)

Well, I did promise to produce a video - but unfortunately, the video capture tool was giving me a lot of problems - and so, I've decided to upload some screenshots instead. I know these doesn't give a lot of justice in showing how awesome our game has become but something is better than nothing right? :) So here it is, a couple (well, just two) of screenshots from our Doodle Space Wings!




Cheers,
Jim

Starcraft 2 (finally started to play.. project in danger..)

Well, it was inevitable. Who was I to resist the temptation of not playing the best ever RTS of all time? After saying to myself a hundred times that I'm not going to play Starcraft 2 until I finish Doodle Space Wings, I finally succumbed to the temptation and got the game after my dentist appointment :) So, after playing 5 missions on the Terran campaign, I lost nearly 6 hours of development time - but I've successfully implemented the homing missle, sub-weapon item pick-up, player hit cue, and player dying animation. So all in all, it ain't bad :) And the plus side is, I've picked up some really cool hints from StarCraft 2 on how to better our doodle side scroller! Also, one really cool thing about that game that I really appreciate was this mini-game called "The Lost Viking"! It is also a side scroller game that I have started using as a reference and as a point of comparison to our doodle game. So yeah, the weekend was pretty productive - all in all. I will try to power through the next wave of tasks for this week and hopefully, the game will even be in a better shape!

Cheers,
Jim

2 types of Bullets, Collision Detection, Game Items, and a whole bunch of other stuffs are now implemented!

Well, it's been a while but I'm happy to say that I've made a very good progress with the game that we're making! And because of that, I've decided to treat my self to a 3-day trip to Tofino last week and not work at all :) I needed the break badly as I felt like my head was about to explode from continuously working on this project! Anyway, here are the new features that I've added to our game:

1. Really fast broad-phase collision detection
2. Game Items (Health, Speed Up, Power-Up, Weapons)
3. 2 Types of Weapons (Fireball, Gatling) with 5 levels of power-ups
4. HUD (Health meter, Score, Lives Left, Pause)
5. Item Spawner Enemy (Mr. Wiggles)

..and a bunch of other small things!

Despite all these wonderful achievements and me working on this ~7 hours a day during the night, I'm still behind by 6 tasks! I hope that I get to finish all of these in time for X2!

I've been meaning to post some videos of how awesome our game is quickly becoming but for some reason, I've been too lazy to do it. I promise to try again tonight and do it :)

Cheers,
Jim

EXC_BAD_ACCESS

Yesterday, I was so happy to have finally implemented both the bullets and the collision detection system. The performance was really good that it can even show up to 100 sprites on the screen at the same time - and all of this is happening with collision detection enabled! I was ready to tackle the next feature in my list - which is making the enemy drop items - but that is until our game crashed. I tried to relaunch it again, thinking that it might just be Steve Jobs' fault.. but then it happened again - only this time, it happened after 2 minutes of waiting. Hmm.. I tried to view the console - and there it was: EXC_BAD_ACCESS. I also tried to view the stack trace to see where the error has originated but to my luck, the stack trace was already gone at that point.

Being a new Objective-C developer, I am still not used to it's style of managing the memory although I am aware of how they work and what are the pitfalls that needs to be avoided. But then, it's bound to happen sooner or later and fortunately for me, I found the problem out while our game is still at it's infancy - where there's not much class hierarchy yet. And so I did my research - and according to my research, here are the main reasons for you to get this error:

1. Releasing an object that is already released (this mostly means that you do not release the objects that you are not directly responsible for releasing - unless you have retained it).
2. Accessing an object that is already released (this mostly means that if you'll be working with an object that's passed via a parameter outside of the call stack where it was delivered, then you'd want to retain it).
3. Adding or removing objects from an array that is currently being iterated (ehem..)

Nevertheless, EXC_BAD_ACCESS is that kind of error that doesn't give you a lot of clue as to how and where it happened. All that it gives you is the error name - and a lot of headache. As it was for me, I spent nearly 4 hours trying to debug this single problem only to find out that I was modifying the array that I was currently iterating! After tweaking the code a bit, our game is finally EXC_BAD_ACCESS free! Yay! So yeah, I'm happy that I was able to move past that and move on to the next item in my list.

Cheers,
Jim

P.S. There is an article that I found on the net on how to debug this error:
http://www.codza.com/how-to-debug-exc_bad_access-on-iphone

but for some reason, it didn't work for me. Oh well - still good to know just in case I get this problem again.

Bullets are now implemented!

After the fireworks show here in Vancouver last night (http://www.celebration-of-light.com/), I got stumped with a bug that made all of my actors (bullets and enemies) run erratic. As I was using multi-threading in my factory to prevent a linear algorithm from blocking the UI, I've learned from the past that if you can't explain some bug after 4 hours of investigation, then it must be caused by multi-threading :) So anyway, it has been a long night last night but I finally managed to implement the bullet system in our Doodle Space Wings! I had to rewrite some sections in my Sprite Factory in order to eliminate the parts that were implemented using multi-threading as it had a critical flaw with regards to accessing critical sections of the code. Anyway, I'm happy with the new solution since even without the threading part, I still managed to meet my 60 FPS goal even when the screen was displaying 50 sprites at the same time!

I also had to redesign some of my sprites in order to make them more attractive. It's hard to do everything by yourself but I guess it's a path that every low-budget indie developers have to take. I'm learning a lot of things right now and I'm happy with the way the things are progressing despite the fact that I'm loosing more sleep :)

So next stuff on the list - collision detection, weapon drops, implementing 5 more kinds of bullets, and loosing more sleep :)

Jim

Goal: 60 FPS

It's been a tough week. I was barely able to keep up with my schedule and the goal of having 60 FPS is not making it any easier. Our Sunday hike at Garibaldi Lake took a toll on my body - and now, I am playing through the pain. Nevertheless, after cutting back my sleeping hours to around 3 to 5 hours, I have managed to keep up with my schedule, still maintain the 60 FPS goal that I want to achieve, and most importantly, hike and bike around Vancouver! Anyway, so how do you go about keeping a high and consistent frame rate? Well, I keep the following guidelines in mind when designing our game:

1. Do not allocate a lot of things in your main game loop - especially during the draw routine
2. Try to reuse your sprite allocations as much as you can. I've implemented a sprite factory which maintains a sprite pool that can reuse sprite allocations. This ensures that dynanic memory allocations during the game loop are kept to a minimum.
3. Cache complex mathematical results.
4. Rely on O(n)-based algorithms only as a last resort. Choose O(logN) or if possible, O(1). For example, using a hash table is a lot better than using an array when you need to search for an item as it cab give you O(1) when using a very good hashing function.
5. If you have to use linear-based algorithms, sorting the array will usually yield better performance if doing search.
6. Remember the trade-off - memory vs performance - you can gain performance improvement by sacrificing some memory.
7. Do not try to reinvent the wheel. Check if the framework that you are using already supports what you are trying to do. The guys who built the framework that you are using spent a lot of time working on it and what they did is probably better than how you will be doing it.

8. Keep the texture size in check. It usually boils down to using a texture size that is a power of 2 (e.g. 512x512).

Hmm.. I guess that's my list for now - I might add some more if I learn something :)

Cheers,
Jim

I can now see it on the screen!

One thing that's really good about the summer is that the number of things that you can do outside of your house exponentially increases. The days are longer, the nights are warmer, the reality shows are in full swing, and well, it just gives you a perfect excuse to not stay home, sit in front of your mac, and do programming! If you live in Vancouver like me, you'll know how many dark, rainy, and cold months we've had to endure before we get to this point - and so whenever we get a chance for a sunny and warm day, we get out as much as we can!

I love the summer but sometimes, I worry that I enjoy it too much that I will have to move my X1 milestone after the summer! But nevertheless, we're still on track and despite the wonderful BBQ, mountain trips, biking trips, and waterpark slides that we've done over the week, I still managed to complete some key of the tasks that I needed for that week and all it took was to move my sleeping time to 2:30 in the morning :). Anyway, here's a small video of what I've managed to accomplish so far. The background still needs some rework since I think it looks very messy! I will try to reduce the doodles to make it look cleaner. Today, I'll probably try to make the ship move using the accelerometer and touch... but after do my biking exercise around science world :)

Jim

Character and Enemy Sprites for Level 1 now Drafted!

Well, I've finally drafted some illustrations for the main player and 5 enemies! Here's a screenshot of what I've done so far:

How do they look? I tried to keep the enemies that will be appearing in Level 1 consistent so that they'll look good together and well, I hope that they all are :) Hopefully, they'll look good on the iPhone screen as well! I can't wait to make them move!

I tried to cover a wide variety of enemy behavior on this one in order to make the game more interesting. I've put weak, agile, mysterious, fast, and grunt enemies in the hopes of giving the players a good challenge!

What's next? Well, I have to convert them into a sprite sheet using Zwoptex in order to increase the efficiency of draw calls to Open GL and I hope to finish this by the end of the week!

So there you go! The casts of Doodle Space Wings - Level 1!

Jim

X0 Milestone Reached!

Yeah, I know, 3 posts in a day! I just started writing this blog today and I wanted to post how our project is progressing so far. And well, our project has just reached X0 Milestone! Hurray!! But wait, what does this mean? Before I started the project, I have laid out a couple of milestones that the project needs to hit before it is deemed to be App Store worthy:

X0 - Plan Complete

X1 - Game is Playable with 1 Level

X2 - Code and Feature Complete

X3 - Store Ready

I have assigned a set of tasks for each of these milestones and in order to track the progress of our project, I made my own burn down chart - here's how it looks like as of today:

Basically, this chart tells me how we are doing in the project in relation to a projection of how we are supposed to be doing in order to meet our milestones and deadlines. This means that if the red line is ahead of the blue line, then our project is delayed. If it is behind the blue line, then we are ahead of schedule. And if it is exactly within the blue line, then we are just on time.

Judging from our burn down chart, we are on schedule so Hurray!! We are on the right track! As you've noticed, the project is supposed to complete somewhere around March 2011 - but wait, that's too long! iOS5 might have come out by then and the game might not run anymore with this new update! To deal with this, I have a sub-milestone called PD1 which is supposed to happen after X1 (around Week 35) and what that means is that I will need to revisit the schedule and adjust it accordingly in order to be more competitive as well as reasonable. Right now, our game features 10 levels and I've conservatively estimated that in order to finish one level, it will take us at least 2 weeks. Now depending on how fast I finish one level after X1, this should give me an idea on how much time I need in order to finish the rest of the levels!! Pretty neat! But until X1 is done, it's March 2011 for us! (oh dear God, please help us!)

Jim