A while ago, a colleague of mine found a set of keys on the sofa while in the lounge area that our company shared with other companies. He immediately asked our group if we had lost our keys and when everyone's found their favorite beer opening key chain (we were young) in their pocket, my colleague promptly brought the keys to the building manager.
The building manager, after checking with all the other companies in the building, still had not found the owner for the keys. He came to our room where we're all sitting and asked if we all had our keys. By instinct everyone's hand went to their pocket again to double check, as is often the case when someone asked if someone is missing something. "Oh, I lost my keys!" says the guy who found them in the first place! He brought is own set of keys to lost and found. This guys was smart, he showed me how to play Go.
Another friend of mine went to the arcade and played a side scroller shoot them up game. He says "I remember how good I was playing them, especially since it was my first playing this game". After a good couple of minutes being awesome at this game, a guy came and force himself by him and on the machine. "I couldn't believe the audacity of this guy, to just push me aside like that". Than the newcomer dropped a quarter in the machine which promptly put the machine out of demo mode. "It wasn’t even me playing after all! I just walked away".
I swear this guy is one of the smartest guy I know. Although he was never as good as on that day at playing video games, he can make sense of very complex problems and "cut through the crap" that can sometime accompanied multiple level of management.
Seth Godin said in Linchpin: “Everyone, every single person, has been a genius at least once. Everyone has winged it, invented, and created their way out of a jam at least once”. I fully agree with him. I’ve been in plenty of meetings where the source of a much needed answer did not come from the expected “thinkers or leaders”.
On the opposite end, you find Scott Adams, Dilbert cartoonist who said: “No matter how smart you are, you spend much of your day being an idiot”. I can certainly vouch for this myself.
Only when you put the two lines of thinking together can you really appreciate the big picture of your daily life.
Most people go through their days patting themselves on the back when they do something smart, and so they should. What we don't do enough is to stop and think if we did something really stupid. We should celebrate our victories, but we should also give a good retrospection on our failures.
Next time, I’ll be picking on a personal example of doing stupid things, even though I might have looked smart doing it. The smart idiots are always the most dangerous!
Friday, June 29, 2012
Thursday, June 7, 2012
Minimum Viable Product - Curiosity
Whenever I look at a new project, I always ask myself what is the least amount of work that I can do to prove that this product can be fun or have a business case (and hopefully both). I was reading about Curiosity on Gamasutra.com today and I thought to myself: "That's probably the most MVP potential for a game I've ever seen". Seriously, they could release the game now with a cube in a room and spend months developing the actual product while people are chipping away at a cube. Only when the features are ready do you have to put in the field and say "The players chipped at it so much that now you have access to a slightly better hammer" (that you have to pay for). So that got me thinking, couldn't I release that game before they do??? How hard can it be to make a cube? So without further delay, here is my first release of Curiosity. Don't expect to chip away too fast at it though, I don't expect I'll ever have the foot traffic that 22 Cans would have releasing the exact same cube :)
Sunday, January 29, 2012
IOS Unity Essential book review
I received the IOS Unity Essential book to review from Packt Publishing. It seems lately that they have been getting a lot of books out that has been getting my attention and this was one of them.
You can find more info on the book here and there is also a sample chapter available.
Looking at the TOC, I couldn't wait to dive right in, so I skimmed some of the chapters for some of interest. Although even chapter 1 covered some topics that got me hitting my head against the wall when I first tried putting my game on the IOS devices. So if you are new to this, starting at the beginning will be helpful :)
The IOS performance guide was one of those chapters that peaked my interest. Unfortunately, it fell below my expectation. Many of the tips was more game design oriented rather than performance trick. Which isn't bad per say, but I'm a tech head. I would always consider a game design work around if I needed to, but I would first want to prove that I can't do it first. It seems like some subject should have been split in their own chapter (i.e. First Person shooter basics?) There was still some helpful tricks to learn though.
I found that the game design angle was repeated in some of the following chapter as well. Again, it's fine, but if my game is to be a game with based largely on a flying camera element, you can't say that you shouldn't do fly-by because of the cost of this feature.
Although few books on Unity covered the particle system before (sorry, no Shuriken coverage in this book), I believe this is the first one to cover Shaders! I thought they did a pretty good job at describing the surface shaders in Unity. They covered a lot of the basics and finished with examples of the Gem and Water shaders that you can find on the store or within Unity itself.
All in all, I thought this book was a good start, especially if you are new to Unity and you want to target IOS devices. If you have a lot of experience in Unity already, you can probably skip this one and hope that there is a more advanced book that comes out soon.
You can find more info on the book here and there is also a sample chapter available.
Looking at the TOC, I couldn't wait to dive right in, so I skimmed some of the chapters for some of interest. Although even chapter 1 covered some topics that got me hitting my head against the wall when I first tried putting my game on the IOS devices. So if you are new to this, starting at the beginning will be helpful :)
The IOS performance guide was one of those chapters that peaked my interest. Unfortunately, it fell below my expectation. Many of the tips was more game design oriented rather than performance trick. Which isn't bad per say, but I'm a tech head. I would always consider a game design work around if I needed to, but I would first want to prove that I can't do it first. It seems like some subject should have been split in their own chapter (i.e. First Person shooter basics?) There was still some helpful tricks to learn though.
I found that the game design angle was repeated in some of the following chapter as well. Again, it's fine, but if my game is to be a game with based largely on a flying camera element, you can't say that you shouldn't do fly-by because of the cost of this feature.
Although few books on Unity covered the particle system before (sorry, no Shuriken coverage in this book), I believe this is the first one to cover Shaders! I thought they did a pretty good job at describing the surface shaders in Unity. They covered a lot of the basics and finished with examples of the Gem and Water shaders that you can find on the store or within Unity itself.
All in all, I thought this book was a good start, especially if you are new to Unity and you want to target IOS devices. If you have a lot of experience in Unity already, you can probably skip this one and hope that there is a more advanced book that comes out soon.
Thursday, September 15, 2011
Multiple Instances Of Unity3d
Whenever I program in VS 2010, I normally have multiple instances of the studio open. Some times I use the extra instances because they are dependant solutions that I need quick access to, sometimes I have some good tutorials or example projects that I want to quickly reference, run and debug.
I thought I had lost this when I started working in Unity3d, and I never needed more than now. Although I can reference the code from other project easily enough using MonoDevelop, the code is only half the story. Often, the scene can tell you more than the actual code can. And although I've been programming in it for a while now, I still find the plethora of Unity tutorial online to be invaluable in my endeavour to better myself.
It turns out it's absolutely possible to do this. Just not as straight forward as you would launch it normally. There's a nice command line page for unity here, the option that is important for us right now is the -projectPath.
Now from the terminal, I type:
Yep, that works! I now have another Unity instance right next to my previous one. Now this is somewhat cumbersome as I don't want to go to the terminal every time I want to launch my project. I now have the habit of creating a small batch file in each of my project that can automatically launch Unity in a separate instance if need be.
Using nano, I would normally go in my project directory and edit a Launch.command file with the following:
The .command extension insures that I can launch the script from Finder. The & lets the application launch in the background so that I can close my terminal window without shutting down Unity.
Hopefully that helps all the learn by example type coders out there!
I thought I had lost this when I started working in Unity3d, and I never needed more than now. Although I can reference the code from other project easily enough using MonoDevelop, the code is only half the story. Often, the scene can tell you more than the actual code can. And although I've been programming in it for a while now, I still find the plethora of Unity tutorial online to be invaluable in my endeavour to better myself.
It turns out it's absolutely possible to do this. Just not as straight forward as you would launch it normally. There's a nice command line page for unity here, the option that is important for us right now is the -projectPath.
Now from the terminal, I type:
/Applications/Unity/Unity.app/Contents/MacOS/Unity -projectPath /Users/username/Unity/ProjectNameYep, that works! I now have another Unity instance right next to my previous one. Now this is somewhat cumbersome as I don't want to go to the terminal every time I want to launch my project. I now have the habit of creating a small batch file in each of my project that can automatically launch Unity in a separate instance if need be.
Using nano, I would normally go in my project directory and edit a Launch.command file with the following:
#!/bin/sh/Applications/Unity/Unity.app/Contents/MacOS/Unity -projectPath /Users/shadhex/Documents/Unity/ProjectName/&The .command extension insures that I can launch the script from Finder. The & lets the application launch in the background so that I can close my terminal window without shutting down Unity.
Hopefully that helps all the learn by example type coders out there!
Monday, July 5, 2010
Scrum vs Kanban
While having a twitter "discussion" on some of the differences between Scrum and Kanban with Alan Shalloway, he prompted me to an article he wrote about the subject. It's a very interesting post and I would encourage you to go read it now.
I like how he attributes a team's learning ability as a result of retrospective done throughout different projects. On a scrum project, this would happen once at the end of every iteration. Kanban, by Alan's thinking, do mini-retrospection every day while reviewing the Kanban board. Would many mini-retrospection be equivalent or better to a "prescribed" end-of-iteration retrospection? I don't know, but the thought is interesting. Obviously the team also gets key learning outside of retrospective but this is true regardless of process.
In the same section he describes scrum as a black box, with well-defined inputs and well-defines outputs (product backlog -> software built). Although he mentions that these words are not his but Ken Schwaber's, I don't agree with them. I hate the thought of any process to be described as a black box. It almost implies that the results are guaranteed when given a set of similar inputs. We all know that this isn't true in software development. In fact, that's why we look at empirical process in the first place instead of traditional prescribed methodologies. The input might be well defined as a product backlog, but the product backlog itself is not important, what's interesting is the stories it contains and the complexity behind them. Given a similar project with a different team, the product backlog might look completely different. Scrum is a black-box as much as any other process is a black-box, requirements-in -> resulting assets out. This usage of black-box in that context is not very interesting and obviously can't be used to differentiate methodologies.
In both Scrum and Kanban, they have a solution for one of the most frustrating aspect of our work: interruptions. There's ton of different types of interruptions (meeting, phone calls, company outings)but one that really is costly is switching tasks because of priorities. I don't know of a worst thing for a developer to put his solution on hold while he's switch to another "more important" task.
Scrum's approach is to lock an iteration down (normally 30 days) where you cannot changed anything that you planned to worked on (sprint backlog). If you do change something because of grave priority, then the scrum master may cancel the sprint entirely if the sprint goal is invalidated. This is normally an exception and not the rule.
Kanban's approach is more flexible, you cannot change the task that you are currently working on unless you haven't attained your limit, but you can certainly changed what's the priority for the tasks in your to do list. Iteration isn't a prescribed practice in Kanban.
In my mind one of the most important factor between Kanban and Scrum: Inclusion of Management. I actually agree that Kanban is better on the relationship between management and their team. Although I don't agree that Scrum stops management from providing "proper interference"(maybe an oxymoron?). Interference might not be allowed at the daily Scrum meetings, why waste everyone's time if only a few are concerned. There's no reason why a guiding discussion can't happen with the Scrum master on information that could help the team. Having said that, scrum does create a barrier between management and the members of the team that many managers would find uncomfortable (more on this later).
I disagree on the visibility being the main factor (it could certainly be a factor). One of the factors I attribute to Kanban being easier to accept by management would be "Controlled Change Management", which Alan says is the biggest difference between Scrum and Kanban. I think that this factor alone make it so much easier to get backing from middle management and above. I believe having buy-in from management is one of the most important aspects of adopting a process (agile or not) for a company.
If you do Scrum by the book, using the Chicken and Pig analogy, how many business do you think would be ready to accept it top-down? It takes so much control and power away from the management (even if it might be for the better good) and they are the ones that should make the decision to use Scrum. Or at least endorse it because the different teams believe it will help. Most of the time, Scrum is instead implemented bottom-up (it's easier to ask for forgiveness instead of permission), and then it's up to the Scrum master to act as a proxy between middle/high management and the team. Gantt charts over Product backlog, Scrum meetings where he urges some "chickens" to remain silent etc. Maybe eventually, the results will speak for itself and will break down the barrier for an adoption of Scrum throughout the organization, but that takes time. Managers that employs a "servant-leader" approach already know instinctively why a methodology like Scrum would work, but not everyone is so open-minded.
I've been with a company where one of a project really hit an impasse with one of our customer. We were in trouble, everyone was desperate. We called in some expert to put a process in place that would help us out with our problems. I wonder how many companies are in that state of mind when they accept Scrum? It's unfortunate, but I can see more companies accepting it because of desperation rather than wanting to change for the better. I think this is fast changing though.
So the ability to slowly adopt Kanban in your organization will certainly be easier to sell than the Scrum "in your face manager" attitude. Especially with managers reading books like "The inmates are running the asylum" :)
I like how he attributes a team's learning ability as a result of retrospective done throughout different projects. On a scrum project, this would happen once at the end of every iteration. Kanban, by Alan's thinking, do mini-retrospection every day while reviewing the Kanban board. Would many mini-retrospection be equivalent or better to a "prescribed" end-of-iteration retrospection? I don't know, but the thought is interesting. Obviously the team also gets key learning outside of retrospective but this is true regardless of process.
In the same section he describes scrum as a black box, with well-defined inputs and well-defines outputs (product backlog -> software built). Although he mentions that these words are not his but Ken Schwaber's, I don't agree with them. I hate the thought of any process to be described as a black box. It almost implies that the results are guaranteed when given a set of similar inputs. We all know that this isn't true in software development. In fact, that's why we look at empirical process in the first place instead of traditional prescribed methodologies. The input might be well defined as a product backlog, but the product backlog itself is not important, what's interesting is the stories it contains and the complexity behind them. Given a similar project with a different team, the product backlog might look completely different. Scrum is a black-box as much as any other process is a black-box, requirements-in -> resulting assets out. This usage of black-box in that context is not very interesting and obviously can't be used to differentiate methodologies.
In both Scrum and Kanban, they have a solution for one of the most frustrating aspect of our work: interruptions. There's ton of different types of interruptions (meeting, phone calls, company outings)but one that really is costly is switching tasks because of priorities. I don't know of a worst thing for a developer to put his solution on hold while he's switch to another "more important" task.
Scrum's approach is to lock an iteration down (normally 30 days) where you cannot changed anything that you planned to worked on (sprint backlog). If you do change something because of grave priority, then the scrum master may cancel the sprint entirely if the sprint goal is invalidated. This is normally an exception and not the rule.
Kanban's approach is more flexible, you cannot change the task that you are currently working on unless you haven't attained your limit, but you can certainly changed what's the priority for the tasks in your to do list. Iteration isn't a prescribed practice in Kanban.
In my mind one of the most important factor between Kanban and Scrum: Inclusion of Management. I actually agree that Kanban is better on the relationship between management and their team. Although I don't agree that Scrum stops management from providing "proper interference"(maybe an oxymoron?). Interference might not be allowed at the daily Scrum meetings, why waste everyone's time if only a few are concerned. There's no reason why a guiding discussion can't happen with the Scrum master on information that could help the team. Having said that, scrum does create a barrier between management and the members of the team that many managers would find uncomfortable (more on this later).
I disagree on the visibility being the main factor (it could certainly be a factor). One of the factors I attribute to Kanban being easier to accept by management would be "Controlled Change Management", which Alan says is the biggest difference between Scrum and Kanban. I think that this factor alone make it so much easier to get backing from middle management and above. I believe having buy-in from management is one of the most important aspects of adopting a process (agile or not) for a company.
If you do Scrum by the book, using the Chicken and Pig analogy, how many business do you think would be ready to accept it top-down? It takes so much control and power away from the management (even if it might be for the better good) and they are the ones that should make the decision to use Scrum. Or at least endorse it because the different teams believe it will help. Most of the time, Scrum is instead implemented bottom-up (it's easier to ask for forgiveness instead of permission), and then it's up to the Scrum master to act as a proxy between middle/high management and the team. Gantt charts over Product backlog, Scrum meetings where he urges some "chickens" to remain silent etc. Maybe eventually, the results will speak for itself and will break down the barrier for an adoption of Scrum throughout the organization, but that takes time. Managers that employs a "servant-leader" approach already know instinctively why a methodology like Scrum would work, but not everyone is so open-minded.
I've been with a company where one of a project really hit an impasse with one of our customer. We were in trouble, everyone was desperate. We called in some expert to put a process in place that would help us out with our problems. I wonder how many companies are in that state of mind when they accept Scrum? It's unfortunate, but I can see more companies accepting it because of desperation rather than wanting to change for the better. I think this is fast changing though.
So the ability to slowly adopt Kanban in your organization will certainly be easier to sell than the Scrum "in your face manager" attitude. Especially with managers reading books like "The inmates are running the asylum" :)
Monday, May 24, 2010
IPhone Programming, where to start---REBOOT
I've previously posted a where to start before. This is when I had just started doing IPhone programming and I think the list of books would still stand today as being great books to learn from to start programming on the IDevices. Beginning iPhone 3 Development: Exploring the iPhone SDK
, Programming in Objective-C 2.0 (2nd Edition)
, Cocoa(R) Programming for Mac(R) OS X (3rd Edition)
are all great starting points to get to programming quickly on the IPhone SDK.
Since then, I've added many other books to my repertoire. Some that I didn't even have time to read yet :) I've always been a fan of the gems type books. They list concrete and sometimes more difficult examples than the normal "learning" type books. To this list I added iPhone Games Projects
, iPhone Cool Projects
, iPhone Advanced Projects
. They are all great books, some of them helped me to work better in cocos2D and others gave me some good optimizing tips.
I'm afraid though, that the most important book that most of us indie type programmer can buy isn't a programming book at all. Let's face it, programming is rather easy for most of us. I've been programming in games for years, and sure there's new things to learn when switching to a new platform and language. But it's most likely not unlike anything you did in the past. So what is this important void of knowledge we need to fill? If you are on the Appstore trying to get noticed, you probably already know : Marketing. I've never really given marketing too much thoughts before going on the Appstore. Even while developing for our Zombie Planet game, marketing is something I was going to do at the end, once it's in the Appstore. Wrong! We were happy enough at first, but our numbers dropped quickly enough. Since we got good reviews from the users who did try it, I think our marketing effort (or lack of) is at fault.
So to refresh my list, here's the most important book you can buy BEFORE starting to program your application: The Business of iPhone App Development: Making and Marketing Apps that Succeed
. There's simply no better book out there right now on this subject. Although the book makes it very clear that marketing should start before your game, it promises to also help the poor souls who are already released in the Appstore. I haven't yet tried to apply any of these tips to our game yet. I've been busy with our new bundle of joy the past few months (a baby, not a toy or a game). I hope to do all of this soon though, as I'm working on releasing our first update to our game (way overdue now).
I absolutely enjoyed this book. Because I lack any formal training in this domain, I've learned so much from it, which is absolutely thrilling. Imagine my surprised when I actually saw code in there to help you along for things like in-app purchase and in-app email. I've always wondered how some games are able to give mojo or credits of some sort (We rule, imob) by downloading other applications. This book covers how to do this too; mystery solved. It also gives good tips on the benefit of free, when to use in-app advertising and how to properly use in-app purchase.
If there is one part I didn't like about this book, it's chapter 3: Protecting your intellectual property. If you find yourself in the same boat, just skip it. The main point you should take from this chapter is to do your research to make sure you don't use any existing trademarks. As indie developers, the rest probably won't apply to you unless you are very successful. If you are aren't indie, chances are you have your own marketing and legal department. In any case, this chapter didn't speak to me but maybe there is someone out there that will like it. The question is: if Mobigame had read this chapter, would they have changed anything about how they went forward with their great game Edge? Probably not.
Beside that chapter, the rest is pure gold. It answers a ton of questions and what it can't answer due to space limitation it provides in links to online resources. From affiliate programs to how to setup an ad-hoc distribution to social media integration, this book is full of useful tips!
, Programming in Objective-C 2.0 (2nd Edition), Cocoa(R) Programming for Mac(R) OS X (3rd Edition) are all great starting points to get to programming quickly on the IPhone SDK.Since then, I've added many other books to my repertoire. Some that I didn't even have time to read yet :) I've always been a fan of the gems type books. They list concrete and sometimes more difficult examples than the normal "learning" type books. To this list I added iPhone Games Projects
, iPhone Cool Projects, iPhone Advanced Projects. They are all great books, some of them helped me to work better in cocos2D and others gave me some good optimizing tips.I'm afraid though, that the most important book that most of us indie type programmer can buy isn't a programming book at all. Let's face it, programming is rather easy for most of us. I've been programming in games for years, and sure there's new things to learn when switching to a new platform and language. But it's most likely not unlike anything you did in the past. So what is this important void of knowledge we need to fill? If you are on the Appstore trying to get noticed, you probably already know : Marketing. I've never really given marketing too much thoughts before going on the Appstore. Even while developing for our Zombie Planet game, marketing is something I was going to do at the end, once it's in the Appstore. Wrong! We were happy enough at first, but our numbers dropped quickly enough. Since we got good reviews from the users who did try it, I think our marketing effort (or lack of) is at fault.
So to refresh my list, here's the most important book you can buy BEFORE starting to program your application: The Business of iPhone App Development: Making and Marketing Apps that Succeed
. There's simply no better book out there right now on this subject. Although the book makes it very clear that marketing should start before your game, it promises to also help the poor souls who are already released in the Appstore. I haven't yet tried to apply any of these tips to our game yet. I've been busy with our new bundle of joy the past few months (a baby, not a toy or a game). I hope to do all of this soon though, as I'm working on releasing our first update to our game (way overdue now).I absolutely enjoyed this book. Because I lack any formal training in this domain, I've learned so much from it, which is absolutely thrilling. Imagine my surprised when I actually saw code in there to help you along for things like in-app purchase and in-app email. I've always wondered how some games are able to give mojo or credits of some sort (We rule, imob) by downloading other applications. This book covers how to do this too; mystery solved. It also gives good tips on the benefit of free, when to use in-app advertising and how to properly use in-app purchase.
If there is one part I didn't like about this book, it's chapter 3: Protecting your intellectual property. If you find yourself in the same boat, just skip it. The main point you should take from this chapter is to do your research to make sure you don't use any existing trademarks. As indie developers, the rest probably won't apply to you unless you are very successful. If you are aren't indie, chances are you have your own marketing and legal department. In any case, this chapter didn't speak to me but maybe there is someone out there that will like it. The question is: if Mobigame had read this chapter, would they have changed anything about how they went forward with their great game Edge? Probably not.
Beside that chapter, the rest is pure gold. It answers a ton of questions and what it can't answer due to space limitation it provides in links to online resources. From affiliate programs to how to setup an ad-hoc distribution to social media integration, this book is full of useful tips!
Thursday, August 6, 2009
Using Cocos 2D MyFirstGame
I've recently updated my version of Cocos2D to the new 0.8 rev for a new game I'm working on with a colleague of mine. I was pleasantly surprise to see many changes, some of which I had to do in the previous version I was using which I was dreading about having to merge back in this version. For example, the original event handler used to only take a CocosNode, which is not always convenient especially since there was a perfectly good interface (protocol) for event handling. In my own version, I had changed it so that you could pass in (id ) and did some refactoring to have the TouchEventsDelegate in its own .m file.
I was a bit surprised to see the exact file name already created when I opened up the new Cocos2D, at first I thought I was looking at the wrong branch. They also up the ante by removing the the event handlers from the Director, which was a good change (single responsibility principle). I don't always feel well qualified to be looking through Objective-C code, I feel my IQ drops a few point every time I try to design with Objective-C simply because I'm spending more time then I normally would thinking about syntax. Looking through the new version, I'm at least relieve to see some decent improvement. Once I spend more time on it, I'm sure I will find some holes here and there. After all, there's no perfect framework.
My first gripe is that I had went through the trouble of creating a cocos2d template type so I could quickly create projects using the wizard. At the time there was a template for one specific version 0.6.? but when I moved to 0.7.1 I had to spend some time fixing it up. I didn't feel like doing this again, especially since I had heard that MyFirstGame was there ready for you to use! MyFirstGame is a very simple app with all the static link libraries (which I didn't have before) and a Hello World type construct. The only problem I really had is that I truly loath it's location (test/samples/MyFirstGame). I wanted to have quick access to this projects, so I moved it to the root of my directory structure. Unfortunately now all my files for my static link project were in the wrong directory, this would be simple enough for me to fix in Visual Studio, but in XCode, well I don't want to call it tricky, it's just a bit different. Once you know how to do it, it's really no more difficult than Visual Studio.
Once this was all done (drag/drop the source file on the target's compile sources), I was finally able to recompile my project from my new location. Grrr, why does the Active SDK only list 3.0 as a valid SDK? To fix this I brought up the info for the projects and went under the build tab. From here, I did a quick search for SDK (that search box is awesome! I wish Visual Studio would have something similar), and I found Base SDK set to IPhone Device 3.0, I just changed this option to 2.2 and finally had option to access all my usual SDK.
Now I'll go back and try to work on Templatizing Cocos2D again. Although I think I found some good advice here for it : http://iphonesdkdev.blogspot.com/2009/01/xcode-template-for-cocos2d.html so this should be easier than my last time where I was going blindly through this process. To be fair, doing wizards for Visual Studio is not fun to do either.
I was a bit surprised to see the exact file name already created when I opened up the new Cocos2D, at first I thought I was looking at the wrong branch. They also up the ante by removing the the event handlers from the Director, which was a good change (single responsibility principle). I don't always feel well qualified to be looking through Objective-C code, I feel my IQ drops a few point every time I try to design with Objective-C simply because I'm spending more time then I normally would thinking about syntax. Looking through the new version, I'm at least relieve to see some decent improvement. Once I spend more time on it, I'm sure I will find some holes here and there. After all, there's no perfect framework.
My first gripe is that I had went through the trouble of creating a cocos2d template type so I could quickly create projects using the wizard. At the time there was a template for one specific version 0.6.? but when I moved to 0.7.1 I had to spend some time fixing it up. I didn't feel like doing this again, especially since I had heard that MyFirstGame was there ready for you to use! MyFirstGame is a very simple app with all the static link libraries (which I didn't have before) and a Hello World type construct. The only problem I really had is that I truly loath it's location (test/samples/MyFirstGame). I wanted to have quick access to this projects, so I moved it to the root of my directory structure. Unfortunately now all my files for my static link project were in the wrong directory, this would be simple enough for me to fix in Visual Studio, but in XCode, well I don't want to call it tricky, it's just a bit different. Once you know how to do it, it's really no more difficult than Visual Studio.
Once this was all done (drag/drop the source file on the target's compile sources), I was finally able to recompile my project from my new location. Grrr, why does the Active SDK only list 3.0 as a valid SDK? To fix this I brought up the info for the projects and went under the build tab. From here, I did a quick search for SDK (that search box is awesome! I wish Visual Studio would have something similar), and I found Base SDK set to IPhone Device 3.0, I just changed this option to 2.2 and finally had option to access all my usual SDK.
Now I'll go back and try to work on Templatizing Cocos2D again. Although I think I found some good advice here for it : http://iphonesdkdev.blogspot.com/2009/01/xcode-template-for-cocos2d.html so this should be easier than my last time where I was going blindly through this process. To be fair, doing wizards for Visual Studio is not fun to do either.
Subscribe to:
Posts (Atom)
