Pages

Monday, July 26, 2010

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.

Thursday, July 22, 2010

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

Tuesday, July 20, 2010

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

Wednesday, July 14, 2010

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

Thursday, July 8, 2010

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




Tuesday, July 6, 2010

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

Tools of the Trade

For low-budget indie developers like us, we try to do more with less. We want to use tools that are simple enough to use and are of course, free! So other than the 1500$ Macbook Pro and the 99$ Development fee that Apple charges per year, most of the tools that we use are pretty much free. Here's a rundown of some of the tools that we use:

Project Management: Google Docs
SCM: Project Locker (They offer a free 500 MB repository)
Visuals: Pen and Paper + Scanner, ZwopTex, Tile Map Editor
IDE: XCode
Development Framework: cocos2D, iPhone SDK 4
Test Device: iTouch
Sounds: Garage
Diary and Updates: This Blog!

It's amazing how much you can achieve for less! So until we earn a couple of bucks from this project, I'll be relying on these tools in completing our daily tasks!

Doodle Space Wings!

Well, This is it! Our first iPhone app is now under development - and it is called Doodle Space Wings! Let me explain: It's a 2D platformer - kind of like 1942 (for those of you who remember) - where you shoot everything in sight using really cool weapons - and of course, you get to fight big bosses at the end of each level - now how cool is that!! We do not have a graphic artist so we'll rely mostly on our mediocre (at best) drawing skills and hence, we hope to get away with the Doodle style :) Hopefully, we'll get it right and that every elements of the game will come together in the end. I am excited! I hope that we get to finish this and hopefully, earn a few bucks in the process :) I plan to track the progress of the development of Doodle Space Wings in this blog and hopefully, I will be diligent enough to post updates!

So who is Really Awesome Indie Games anyway? Well, right now, it's mostly just me and my loving wife - I do the programming, visuals, sounds, project management, and all sorts of technical stuff while she does the QA, budgeting (as in no Jim, you cannot buy an iPhone 4 - use your 1st generation iTouch instead!) and marketing-related stuff :) Apple has created a really good platform where anybody can use their talents and creativity to do something special and distribute it to the millions of people all over the world. This opportunity - which was not readily available to indie guys like us before the iPhone revolution - got us really excited and although it took us 2 years to finally get into the bandwagon, we're finally making progress and I for one am very happy with that!

I am under no illusion that this is going to be easy and me having a full time job does not make it any easier at all. But I believe that with proper planning (and spending less time visiting Facebook), we'll complete this project. But until then, gotta work work and work!!

Jim