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:

/Applications/Unity/Unity.app/Contents/MacOS/Unity -projectPath /Users/username/Unity/ProjectName


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:


#!/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!

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" :)

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!

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.

How do I start and complete a new game?

How do you start a project and bring it to completion? This isn't as easy as it sounds. We all have different level of motivation for making projects at home on our own time. Personally, I'm somewhat of a self learner in the programming profession. I started sharpening my programming skill before I was in high school, and the only way I could really learn anything was to create projects for myself almost every other month. Have I finished many of those applications? I've sold one of my programs to a few schools; one out of hundreds of applications that I "completed". My point is that "complete" needs to be defined, for any projects. My personal projects were always more about the learning experience than the end utility about the program in question. Once I learned what I needed from the experiment, I would move on, hence "complete".

The definition of "complete" is no more well defined in most work places. How often a programmer is given a certain task, asked how much time he thinks it will take him to complete it and the reply would be something like "Oh, for that no more than an hour". An hour goes by, you come back to the programmer and ask if it's done and he says "Yep, all done, I'm just finishing the review of it now. I'll have Jake go over it to make sure I didn't break anything, then I need to make sure it also builds and run on the target". Huh? What just happened, it's not done is it? Well, the programmer has a very different definition of done than a delivery manager or a producer. It might still need to be committed to the SCM and then submitted against a specific enhancement request, or maybe a defect. After that, it might need to be build as part of an automated build process and be unit tested. Then there's the smoke test on the build, installing on the target and QA finally needs to go through it. Ok, so maybe it's not to this extreme everywhere, but you get the point.

Define Complete
The best thing you can do to avoid a miscommunication of what you thought "complete" meant is simply to define it. Does complete means "when I'm done with it", or "when it's ready to be in the customers' hand". When you have a personal project, make sure you define what it is your goal. Do you want to make money out of the application, make a prototype that might get you some funding, or just playing around with a cool idea cause you want to learn? There's no bad answers, just make sure you know what it is.

Since I have starting working on my own time to develop on the IPhone, I now have different goals. Some of those goals are conflicting unfortunately. For example, the platform is rather new to me. I never did Objective-C or Cocoa programming before and never even owned a Mac. This means that I need to create some projects to learn. Thankfully, learning new language for me now isn't the same as when I was in 7th grade, when I did not quite understand how pointers worked. This means that my projects can be a little more varied and elaborate. I just need to accept that their might a bit of overhead to my normal programming velocity. I'm very surprised at how low that overhead is, to be honest. So it is possible to learn while making application that would be somewhat fun and useful. Ok, I'm not talking about Valentine Tips here. I didn't particularly enjoy working on that project, but I did learn a lot. My goal was mainly understanding the process that I was going to need to go through to publish the application on the Appstore. As such, it was a great success. A money maker, it was not :)

Come up with ideas
Duh! I know sounds stupid. What I mean by this is not to limit yourself at the first idea that pops into your mind. You need to come up with a TON of ideas. Don't go into too much details at first, prefer to go wide instead of deep. So you got a pirate game idea that you like; great, pirates are always cool. But wait, before you go into too much detail you come up with a cool Zombie idea. Obviously, those always work right? Now, what if you take the two games and take elements of each and turn it into a game? What do you have? Probably a law suite from Disney for infringing on Pirates of the Caribbean! So go back to the drawing board and start again! Every year, gamedev.net has a game contest, check out Four Elements IV Contest. Replace the pirates with robots and Zombie with Ninjas and your back in business. If you need inspiration, read books and comics, watch movies or watch sports. Look inside of you for different experiences that shape the person you are and see if you can use it to make a game (Think the game Bully was created by a bully or the person being bullied?). Could be either really, the point is that they had experience with the subject in question. Learn as much as possible once you have identified raw ideas, the learning process might give you new and better ideas.

It's not easy to have a brainstorm of 1 person, so if you can, try to bounce ideas off your spouse, friends, dog or mirror. Talk through your ideas out loud, it helps to make them clearer. Write everything down, so walk around with a piece of paper and a pen. Your memory will FAIL you, even if you think you have this great idea and you can't possibly forget it, POOF, it's gone 10 minutes later.

If you are not the only working on the project, then awesome! You are in a much better spot when it comes to coming up with game ideas. Brainstorming with a group of people (2-4) is great for generating ideas very fast. People truly feed on ideas from others and morph them for the better. Again, write down everything. Don't be rational at this point, you should be saying stuff like "Oh you can't do that cause bubbles can't bounce off walls, they would explode". This isn't the time for killing ideas, just generating them (unless your ideas is exploding bubbles, which might work). When it comes down to narrowing down ideas, keep your ego in check. It's not always easy to have your ideas shot down; keep them for another time or forget about them completely. Just be ready to move on with the project, it will need your buy-in.



Do your research
Over the years, I've created many games that was never truly finished, some new ideas and quite a few clones. In 1998, I created a 3D tetris using Java and VRML as the rendering engine. I was very proud of myself for creating this somewhat original idea. Later I found out that Blockout existed for almost 10 years prior than my version. Humph, but it wasn't running in a browser now could it? There's nothing wrong with making a clone, but it would be really nice to know that's what you are making. For working on the IPhone, I personally use AppShopper to see if what I want to make already exist in some form or another. If you decide to continue, you should know the price point of your competition and what feature you can include that will differentiate yourself from them. So be ready to buy someone else's game/software.

Flush out the design
Make sure you understand what it is that you are creating. Once that's done, make sure you can give a document to someone else so that she can understand it also. I'm not saying that things won't be changing throughout the life cycle of the project, but that's ok, you can change the document as you are going through the development process. Just remember that the latter you change things, the more work you'll need to redo. Changing zombies to ninja will require a lot of remodeling and texturing and animations (unless they are zombie ninjas?).

Prototype
Awesome, you got your great idea! Now what? Well, with any projects (game or application software), the first thing you need to do is to create a risk list and provide solution for them. Most likely, the solution will come in form of prototypes. Prototyping doesn't necessarily mean creating a program in this case. If you came up with a card game idea, you can always play it with real deck before writing any line of code. If you do some kind of manual prototype, be wary of how it will port to the target platform. Not to long ago, my father, who is an avid game maker (puzzles), came to me with a few new puzzles to see if any of them would fit the IPhone platform. We played a few hands with cutout card boards of one of the puzzles and the game was fun and fast enough, but there was many times when neither of us could make any moves. So we had to pick another piece and skip. This happens very fast when you are playing on a table, but I'm not sure how it would have transfered on the IPhone. I think the pacing would have been a bit wrong. So it might be that the game needs a bit of tweaking before it's ready for the IPhone, but it makes a very fun puzzle game nonetheless.

I'm currently making a board game for the IPhone. Because my board was going to be a certain size, I knew the squares of the board were going to be too small to be easily picked by anyone with fat fingers. So what's the first thing I did? That's right, I prototyped a board to test how I could resolve this. No fancy graphic, and no picking as of yet, but I did create what I think is a solution to my problem. I'm still not sure my current solution will be my final approach, but my top risk as at least been mitigated and I can move on to my next biggest risk. The next risk isn't actually a technical risk, but more of a design risk because of how the AppStore works. How do I provide a free version of the game that leaves the player wanting more? It seems like you need to provide a free version of the game to be on the map on the AppStore. I understand why, I just wish that there was a better way to go about it then to write a slightly different application. Unfortunately, the AppStore doesn't allow time based trial or anything of the sort. I'm afraid that a simple prototype might not do here, so I'm looking at it from a game design and architectural design instead. If I can identify game design aspect that I think I can play with, then I can design the application to enable certain hooks that can disable or enable different game type (for example), depending on what version I'm compiling. What I want to minimize is to have 2 different code branches. I'll keep you updated on how this will progress.

Big vs Small

During day time, I work for a rather large company. When I'm done work and finally get home, I have a few hours of play with the family and then move on to work for myself. The difference between working for a Big Company and for yourself is extreme. The company I work for employs about 400 people or so. There's multitudes of games being developed in parallel for many markets, all with their different rules and regulations. We have game designers, artists, programmers, QA, integration engineers and delivery managers (this is equivalent of a producer). Add to that managers for each of those groups and probably managers to manage them and you got lots of people working on intertwined projects.

Then I come home, and I'm the manager, designer, programmer, QA and on some occasion, artists *shudder*. That last role is a bit scary...I have no artistic bones in my body except for a bit of photography.

I don't mind day time work; sometimes I can truly find a lot of fun in it. After I'm done filling all my TPS reports that is. I find the overhead of doing things when you are in big groups a bit frustrating. Things are normally very simple, but put a simple problem in a large group and all of a sudden, it becomes really complicated. Politics, egos they don't really play a big role when you are developing by yourself.

Deadlines are probably some of the most frustrating element to deal with. Everyone has deadline. They are part of the software industry, it doesn't matter if you are on the gaming side, or the application side. If you have a client, you will have a deadline. As frustrating as deadline can be, they are a necessary evil in the software cycle. I've read once that if you give two equally bright programmers the same task, give a 1 week deadline to the first and a 2 weeks deadline to the second and they will most likely take the exact amount given to them to finish the task. I believe it. I've seen people take 1 day to do an hour job. Mainly because a task is never schedule for less than a day on a schedule.

What I don't like from deadlines is that they are more often etched in stone by sales department or middle management than by those doing the work. So if the date can't move, that's ok right, we can always throw out some features? Nope, they are etched on the other side of that same stone. So what gives? Personal time and quality of work is normally what goes first.

In my own personal projects, I try as much as possible to impose deadlines on myself. If I do come close to a deadline that I know I can't meet, I might put a bit more of my personal time in the project (but hey, it's all personal time right?) but I will also cut features if I need. As you can read in my post for my first AppStore Application, I had a very real deadline and had a long enough feature list. When I started planning in January, I had a mini game planned for it, although I knew it would be almost impossible to finish on time (I was just too new to Iphone development). So I cut the mini game, I also cut on some needless features. All in all, I finished about half a week ahead of schedule but I rather have more time than not enough. I really didn't know if my app was going to make it through the appstore review in one piece and I'd rather have more time to fix and re-submit than not enough.

I just recently did an estimation on a project I might be moonlighting on(if we get the contract). I normally estimate tasks, not entire projects. I have to say, it's not easy and I don't particularly like it. I've given an estimate that I think will be as accurate as possible given the current knowledge I have of the project. I added time for defect cycles in there for good measures. We'll have to wait and see if the project is approved and what our deadlines will be. Regardless, I think it will be interesting to see how our team of two compares to a team of 20. I bet, that our schedule will hold up better, but it certainly doesn't mean that I can do a schedule to manage 20 people. I probably would fail, like everyone else I know.

Using an off the shelf engine or build one yourself?

When doing games, this is a question that you will come across over and over again. I've went through the pains of writing a 3D engine and a physics engine a few years back. I never used it in any of my own games, but it was a blast to work through all the different problems, and there was many problems.

One of the biggest problems to coming up with your own 3D engine is a general lack of direction if you don't tie it to a specific project. Aimlessly doing an engine with no goals is not necessarily a bad things. Just make sure you understand what is your own personal objectives of the project. If you want to learn, then this great way to go about it. If you want to build an engine that you'll be able to use on all of your future projects, then I'm afraid you'll probably fail. I'm not attacking your own skills or dedication. The problem is that it takes a lot of time to create a generic 3D engine that can be used by multiple projects. By the time that you get finished a couple of projects with a successful engine, you will probably need to provide an update for it. That time could be much better spent on an actual game. Before creating your own engine, ask yourself what you want out of it. If what you want is to create a game and not the engine itself, then chose an existing engine that will cover your need.

So what are the engine of choice? It really depends at what level you are working at I guess. The only professional engine I've worked with was Gamebryo, so I can't compare it to Unreal or any of the other engines out there. On the free side, I've worked with Irrlicht and Ogre3d. I have a preference toward Ogre since I find the user base larger and more active. There also seems to be more updates on the Ogre engine itself. Although I have to say I was pretty impressed with Irrlicht software renderer.

Wait a minute, this is an IPhone blog. Well, it turns out that at this time, there's no Irrlicht or Ogre port for the IPhone. Although I've thought long and hard about porting Ogre to the IPhone myself, I've decided that my time would be better spent on working on a game instead. So, what engines can we use on the IPhone? Well, if what you want to do is 2D, then I would suggest a look at Cocos2D for the IPhone. This is the engine I'm currently working with and I have to say that I am pleasantly surprised. One thing to note is that it is completely written using Objective-C, which I'm still not completely familiar with at this time. Although looking through the code of the engine, I have a much better appreciation for the language than I did when I started. I just hope that I can get to a point where the code I write in Objective-c just rolls out as easily as C# or C++/STL/Boost. Another alternative if you want to build 3D games would be Oolongengine (doesn't roll of the tongue quite right). I've personally haven't used it yet. It uses mainly C++ with some help from Objective-C for gluing the whole thing together on the IPhone SDK. A person of interest working on this would be Wolfgang Engel, who I believe had started (don't quote me on that) gameversity.com (I attended some class there) a while back and also who is the editor for the Shader X series of books. A personal favorite series of mine along with Game Programming Gems.

Do I regret working on my own engine for the better part of a year? Absolutely not, beside learning a few things of myself, I now understand other peoples engine much easier. Also it's normally not too complicated for me to go and change the engine if there is something that doesn't work the way I like or if there's a defect. For example, I had to rewrite quite a bit of code in the Gamebryo engine to make it work on Linux. It was a challenge, but it was well worth it.