Saturday, February 28, 2009

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.

Sunday, February 22, 2009

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) (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.

Sunday, February 8, 2009

Why use a Software Configuration Management system?

It’s not just about saving our code somewhere in a generalized place so that it is easily backup.  It’s not only for being able to work with someone else on the same piece of code.  When used from home, it’s main used is to keep you sane!  You will probably be the only person who will be accessing your SCM at home, but it doesn’t make it less useful.  Have you ever thought, “Oh, I wonder how the code would work if I’d changed this”?  Whenever you have a working version of a software and that you ask yourself that question, which might break working code for a few hours, you need a SCM.  This will allow you to have a source directory structure that works at one particular time.  If you are about to make major changes to a working product, check in your current progress and label it if it’s needed.  You can then do major changes and if you don’t like it, come back to your original changes, guaranteed.  Also, if you work on a few days and think you have introduced a bug, you can do diff on your files to see where the bug might have crept in.  There isn’t a day that go buy where I work on code that I don’t use a SCM, it’s that useful!

I do not know how many people do not use SCM when coding from home, I’m guessing most probably don’t, especially if the programming is more informal rather than professional in nature.   If it’s professional and linked to any delivery, then I hope you do have a SCM working for you.  I would also invest in a local backup system for that SCM and look at an offsite backup system for that rare case if your house burns down. I’ve already told my wife, “You grab the baby, I grab the Synology server and we meet at the front of the house”.  I don’t have an offsite backup, but I might be looking into this year if my moonlighting work requires it.

For those of you that don’t have a backup solution, this article is for you.  We’ll try to setup a Perforce SCM solution.  I have been using a Perforce client on my Windows PC for many years now.  We’ve also used Perforce in combination with Jira, which is a bit more process driven.  In my work environment, I can’t checked in a change list without have first written a Jira issue describing in details why I’m doing the check in.  In a home environment, we’ll probably very rarely need such an elaborate process.  You might still use a bug tracking tool, but if you are one or two developer, it will probably not require you to have it tied to your SCM.  If you have the patience for it, great, but in my experience, it would add too much overhead for the work I personally do at home.

Because I already use Perforce at work and at home, I’m going to describe how to do a similar setup, but for Mac OS X.  First thing we will do is to download a few tools from the Perforce Web Site.  Once here I download the Macintosh version of the visual client P4V, the command line tool P4 and the server P4D.


Once you have everything downloaded, then comes time for the install.  First thing to do is to move the file downloaded to some useful directory.  I’ve created a Perforce folder under Applications to which I then moved my p4v.dmg, p4 and my p4d file.  Once moved, you will probably need to use Terminal to go to that directory and make the p4d file and executable file.  Go to which ever directory you put your files in and execute chmod +x p4d, do the same for the p4 file.  You might want to move the p4 file in a more useful directory, which would be under $PATH.  The reason is that we want to be able to start this program from any directory that we would be working .  /usr/bin might be a good choice, so lets move it into there.   Go in your download directory using terminal and once you are in the correct folder, move the p4 file using the command mv p4 /usr/local/bin.  Hmm, did that not work?  Protected directory you say?  Instead try sudo mv p4 /usr/bin, this runs the same command, but as a root user which is needed to access certain directory.


Now that everything is installed, let’s try running the visual client, P4V.  Go into the applications directory where you installed the P4V.dmg file and click on it.  You’ll see a p4Merge and a p4v in the mount.  Let’s copy those directly in the applications folder we created instead of keeping them in the dmg file.  Now run p4v and you should see something like:

Maybe the 1666 is instead a $P4PORT environment variable, but it will be something close to this screen in either case.  Because perforce isn’t a known host, we’ll go ahead and changed this to localhost or, either should work.  For the port, you can either hardcode it to something specific like 1666 or use their environment variable and set it something similar (1666 is the default set by Perforce).

Before we can go forward here, we’ll need to start the Perforce Server.  On my Windows installation, I did not need to install a perforce server since I could just us the filesystem directly instead.  This doesn’t seem possible with the Mac version.  To start the Perforce server, navigate to where you installed the p4d file using Terminal and the simplest way to start the server is by calling simply ./p4d.  If you want to use a different port than the default, you would need to use the -p flag and specify the port as such: ./p4d -p 2666.  If you want to be able to launch the process in the background and forget about it, you can append a & character at the end of the command line.

One thing that you should know about launching the server in this way is that it will create all the file necessary to run the Perforce SCM under the root directory.  So make sure that you are ready to have your file saved in this directory before you proceed.  If you do want to change the root directory of the server, you can either provide a -r followed by the directory path you do want to use, or create an environment variable named P4ROOT that does the same.  On my own setup, once I’m finally done, my command line looks something like ./p4d -p 1666 -r ~/Documents/Perforce/&

As you can see, I created another Perforce directory under my ~/Documents folder.  This will be easier for me when I will be doing backup, since I might not normally backup my Applications folder, but I do backup my Documents folder.

With the server launched and ready, we should be able to create our own user!  In the p4v application we launched earlier, we can see a User field, click the New button on the right of it.  This will ask you to fill in your user name, full name, password (although optional) and email. Once you have filled all this information, you then need to fill in a workspace if you need one.

The Root folder of your workspace should be somewhere under the root directory structure that we started the server with.  Which in my case was the ~/Documents/Perforce.  So in that directory, I created a directory workspace and now my Workspace dum points to that directory.

Here is p4v, started and ready to go.  You can now drop files under that directory and submit them, you can then revert, compare, check out and check in all of your source file for greater control over your home project, little or big.

Next time we’ll look at the integration with XCode