Here is a step-by-step walkthrough of how to get Xcode set up for programming simple console apps like you would find in any basic C book.

STEP 1: Install Xcode 4

It’s in the Mac App Store. Search for Xcode then get it. I believe it’s free. Next, after it’s downloaded, you need to run the app called “Install Xcode” (if you’re running Lion, you can find it by clicking the silver rocket ship dock icon). That is what will really install it. When that’s done, you can move on to step 2.

STEP 2: Create a New Project

This is the first thing you will see. Make sure you choose “Create a new Xcode project”.

Next, choose “Mac OS X”, then “Application”.

Then choose “Command Line Tool”. Click Next.

Now choose the options for your project, and where to put it.

Click Next.

Make sure to UNCHECK the option to create a git repository. You’re just starting to learn to code – source control can come later.

STEP 3: Set Up The Project Window

Now the project will start up in a window that will look confusing since you’re not used to this kind of information. Don’t worry — you don’t need to know about this yet, and you can get rid of it so you can focus only on your code.

First, select your main.c source by clicking on the name in the left pane.

Next, let’s get rid of all the bothersome info. Click on the View buttons so they’re all off like this.

Now you should be looking only at pure code.

Click on the PLAY button at the top-left to run the simple main() code that was generated for you. It will open up an output window at the bottom of the edit area.

Now, make the output area fill the screen from left to right by clicking the View buttons like so:

There! Now you have pure code and pure output!

To clean up the output and make it only show you your code output and no compilation messages, change the pulldown menu from All Output to Target Output.

Finally, I don’t like coding with a solid white background blasting my retinas all day, so I always choose a dark scheme.

To do this, press Command-, (comma) to bring up Preferences. Choose Fonts & Color. On the left pane, choose the theme Midnight. Your screen would look just like this…

That’s all there is to setting up a new console-only C project in Xcode with a simple environment! This is the view that my girlfriend Brenda prefers because it’s easy to just focus on her code.

                          

I wanted to make a social game last year, so my girlfriend Brenda told her employers (Lolapps, Inc., a social game developer in San Francisco, California) that I was interested. I started consulting in August 2010, designed the game in a few days, and got the team working on what I decided to call Ravenwood Fair. At the beginning, I did art direction toward a painterly style until the lead artist, Christine MacTernan, totally got the look and took over from there. I created and coded all the sound effects, and worked with a great composer named Aaron Walz from Game Audio Alliance on the game’s looping soundtrack. He did an excellent job, as the song can be played infinitely without annoyance – the true test of a great composition.

The team was very small: four programmers, two concept artists, two animators, a UI artist, a producer, Brenda and me. That’s only 12 people. In addition, the game launched on October 19, which means it took 2.5 months to go from concept to ship. This causes many a social game publisher to gasp, but there’s a good reason for it: the team worked very hard, and they had already been working on several game concepts for 7 months before I showed up, so they were already “at speed” and no ramp-up time was needed.

When I arrived at Lolapps, the owners told me I could create whatever, as long as the game would make money and launch by September 30. That was less than 2 months by the time I started working on it. I knew I had to hurry up and come up with a concept, so I quickly identified the best game on Facebook at the time, FrontierVille, and played it for three days so I could understand its design patterns and monetization model (I had been following the social game space since 2009). Then, I got the scoop on the engine we were using and found out it was really fast and could draw a ton of graphics on the screen quickly. I learned from the lead coder how much code had been written for the previous game prototypes, so I needed to use as much as possible to keep moving forward and not go backward much.

The idea for the game appeared very quickly. The setting was going to be a fairytale/storybook/magical place that floated in the air and was occupied by a slightly scary forest. Since the biggest games on Facebook were business sims, I needed to have the player build their own little business, and I wanted it to be like nothing else on Facebook. I thought a Fair would be a really nice obvious positive goal for the player to build, and there wasn’t a carnival/circus/fair sim on Facebook……yet. My thought was this: when you’re building a place for visitors to come and occupy, why wouldn’t you want them to be doing something really fun while they’re there? What’s more fun than Disneyland? I imagined what it must be like at a high-level point-of-view to actually RUN DisneyWorld in Orlando, Florida – to have to carve out a bunch of wilderness packed with alligators and other denizens, and then have to build a fun place in the middle of that – and KEEP it happy and fun, all the while the alligators and beasts want their place back. I figured that would be a fun game to play – as I cut back a scary forest, I build a Fair, visitors come and use all the things I’m building, and I get to interact with them in a light fashion. That was the basis of my design, so we had our first meeting, and the producer and leads wrote down the long list of things that we needed to start working on immediately.

After August, we were still working on the foundations of the game systems and entire art overhaul, when Brenda joined the team from Critter Island (it had been shut down by Facebook). Brenda immediately started working on the quests, the map layout, and the tutorial parts of the game. She had to basically try to get all the final parts of the game together while I was still working on the foundational stuff, and we had to make sure that they would meet in the middle and the game would be complete by September 30.

Near the end of September, to make the launch date, the game had been re-scoped and re-prioritized so much that it wasn’t going to be anything I’d want to play if we shipped it in that state. Facebook games are well-known to ship incomplete and get fixed post-launch. I’m not from that world – I’m from the world of “You only launch once” and the first impression is extremely important. There were game systems missing that absolutely needed to be included in the game for the design to harmonize, and it got very tense at the end of September with the execs pressing for launch and me holding the game back to make it great. Every day in October was a “Can it ship?” day. It took 19 more 12pm-to-4am days to get the game in a state that I’d launch. In fact, I held back on doing interviews about the game until I knew it was going to be something I’d put my name on. Finally, around October 15, the game was quality enough for me to do the Dean Takahashi interview in VentureBeat.

The game launched, but the team kept working. We had lots of holes to fill, and obscure bugs to fix. The launch on Facebook went as good as a launch could possibly go: millions of people played the game and hundreds of thousands still join every week. Brenda and I ended our consulting with Lolapps on February 25, 2011 so we could concentrate full-time on our new startup, Loot Drop, Inc.

Just recently at the beginning of March, Ravenwood Fair made the #15 slot on the AppData Top 15 Applications list – this list is of ALL applications on Facebook, not just games (over 125,000 apps are on Facebook). Ravenwood Fair is the #1 non-Zynga game, and that’s quite an accomplishment. Currently, over 25 million people play Ravenwood Fair every month on all social platforms (over 11 million on Facebook alone), and over 1 million play every day on Facebook only. I never thought I’d see the day that I would make a game that doubled World of Warcraft, player count-wise. I’d like to thank Brenda and Lolapps for giving me the opportunity, and the Ravenwood Fair launch team that worked so hard on the game.

Ravenwood Fair Trivia Time!

                          

The error I got when I tried running the code was this:

1180: Call to a possibly
undefined method xxxx

This basically means that Flash couldn’t find the class that I created. But I didn’t get any errors from the “import” statement that references the .AS file that has the class in it (inside a package{}).

If I changed the filename I’m trying to import I get an error. Ok, so it knows the file is there but it cannot find the class inside the file for some reason.

I searched all over the net for an hour trying to find the answer to this problem. NOWHERE DID I FIND THE SOLUTION THAT I AM ABOUT TO GIVE YOU. The solution to the problem is something that, evidently, Flash programmers JUST KNOW from experience but the solution isn’t written anywhere that I could find on the internet and my Flash coders don’t know how they know the technicality I’m about to explain.

So it comes down to this: the way you write the name of your class MUST be the EXACT way you name the .AS file it’s in.

For example: if I create a class named BugJar like so:

package
{
  public class BugJar
  {
    //...code...
  }
}

then I **MUST** save it in a file named BugJar.as!!!!

Inside my framecode I would have:

import BugJar;

…and it would work.

This is just completely disgusting to me as a programmer. Linking the name of a class to the filename of the file it’s in is just wrong.

What’s worse is that Flash doesn’t even give you the proper error for this:

filename: bugjar.as

package
{
  public class BugJar
  {
      //...code...
  }
}

framecode:

import bugjar;
var jarugJar = new BugJar();

The above example WILL NOT WORK and Flash doesn’t give you an error message that helps you understand or fix this problem that shouldn’t exist in the first place.

                          

One of my small hobbies is locating lost greats from the dawn of the game industry with most of my focus on the Apple II authors. Stuart Smith is one of those lost authors I have yet to find.

One of the earliest and probably first-published titles Stuart worked on was Fracas, a lo-res turn-based RPG that could eat up a LOT of hours. I recently ran the game again and remembered that it was written in Applesoft Basic, a language that I’m very familar with.

While scrolling through the game listing (this is a game from 1980, mind you) I immediately noticed the line:

5 DEF FN RN(I) = INT( RND(1)* I )

and I thought “oh yeah, I never did figure out what the hell that DEF FN keyword was used for.” Then I resolved to learn what it actually did so I looked up an Applesoft reference manual and found out.

Wow. I cannot believe I never learned the value of DEF FN and the countless times I could have used it in my games! It’s really simple: you are defining a function that you can call without a GOSUB and it can take a parameter. Basically an inline function…..in Applesoft Basic!

Amazing. And to think that I learned this from a game written at the dawn of the PC gaming age.

                          

Check out the celebration at NeXT Computers.org and browse the forums to find out more about this legendary company, their hardware and their unsurpassed software.

Why do I care so much about NeXT computers? Because we at id Software developed the groundbreaking titles DOOM and Quake on the NeXTSTEP 3.3 OS running on a variety of hardware for about 4 years. I still remember the wonderful time I had coding DoomEd and QuakeEd in Objective-C; there was nothing like it before and there still is no environment quite like it even today.

When id Software was stationed in Madison, Wisconsin during the winter of 1991, most of us were gone for the Christmas holiday – except John Carmack. John’s present, which he bought with $11,000 of his own money, procured by walking through the snow and ice to remove from the bank, arrived during the holiday and he spent the whole time learning as much as he could about the computer and started working on vector quantization algorithms for compressing graphics. His test graphic was a 256-color screen from King’s Quest 5. After his research was done it was agreed that the entire company needed to develop our next game on NeXTSTEP.

id’s first NeXT hardware was all black – both Cubes and Stations. We upgraded through the years to the Turbo model then to other hardware like the HP Gecko and then Intel hardware at the end. We were building fat binaries of the tools for all 3 processors in the office – one .app file that had code for all 3 processors in it and executed the right code depending on which machine you ran it on. All our data was stored on a Novell 3.11 server and we constantly used the NeXTSTEP Novell gateway object to transparently copy our files to and from the server as if it was a local NTFS drive. This was back in 1993!

In fact, with the superpower of NeXTSTEP, one of the earliest incarnations of DoomEd had Carmack in his office, me in my office, DoomEd running on both our computers and both of us editing one map together at the same time. I could see John moving entities around on my screen as I drew new walls. Shared memory spaces and distributed objects. Pure magic.

We wrote all of DOOM and Quake’s code on NeXTSTEP. We debugged the code in NeXTSTEP with DOOM and Quake’s 320×200 VGA screen drawing in a little Interceptor window while the rest of the screen was used for debugging code. When all the code ran without bugs we cross-compiled it for the Intel processor on NeXTSTEP then turned over to our Intel DOS computers, copied the EXE and just ran the game. The DOS4GW DOS-Extender loaded up and the game ran. It was that easy.

One funny and strange note: I’m left-handed but while using NeXTSTEP I used a right-hand mouse. Then when I ran the game on my DOS computer I switched hands and played left-handed. Windows is not yet hardcore enough for me to switch to right-handed mice.

I’ll bet you didn’t know that DOOM, DOOM II and Quake weren’t the only games developed on NeXTSTEP. When I got Raven Software to agree to develop Heretic for us I had them buy several Epson NeXT computers (Intel based) and I flew up to Madison, WI to get them all set up and teach them how to develop the game with our tools and engine. It was a great time I’ll never forget – seeing their team get excited about the power of the new environment and that they got the game developed and released in under a year. They signed on for another title and developed Hexen on NeXTSTEP as well.

Back at home base we were busy with the beginnings of Quake – developed on NeXTSTEP of course but we also had another game that we were having developed using our tools and tech by Rogue Entertainment – the super fun, one of a kind, action RPG that was Strife. Unfortunately most people hadn’t heard of the game because the publisher we sold the game to went out of business upon its launch. If you can find this game you should really play it – it’s quite a ride.

As I was leaving id Software in August 1996 the move to the Windows 32 platform was underway. John Carmack was porting our QuakeEd editor over to Win32 and preparing for a NeXT-less future. Several short months later NeXT made their fateful move over to Apple and a new era was begun as Steve Jobs set about changing the future. Again.

Up to that point I had spent 15 years of my life working on computers that Steve Jobs was involved in bringing to the world. First the Apple II+, then the IIe, the IIgs and finally NeXT. Maybe someday I’ll get one of those kickass iMacs.

                          

We’re close to landing a couple Gameboy Advance contracts, so I’m really excited to be learning that little machine. I can’t say what the titles are (of course), but as soon as they’re done I’ll let everyone know. It will take almost a year before you see either of them though, as the development time will be about 8 months.

click to enlarge

So, yes, I’m almost done with the PC version of Hyperspace Delivery Boy! Here’s a screenshot of the PC version. If you’ve played the Pocket PC version, you’ll notice a number of differences.

First, since there’s no stylus on the PC, you use a mouse cursor (the blue circle) to point and click your way through the game. Directional keys are also supported and there’s a new Controls screen that allows you to configure them to your liking.

No longer do you need to bring up your Resources and Deliveries as they are on-screen at all times. You can click on an item or delivery and get specific information on it as you would expect.

The sound effects are now at 44khz and the music has been lengthened and now plays at high quality as well.

There’s been a REALLY cool update to the AppleWin Apple II emulator. This has always been my favorite Apple emulator but the damn thing would NEVER run in full-screen mode – it was always a little window.

Well, the source code has been updated by a different guy, Oliver Schmidt, and he’s done a fantastic job adding DirectX support and FULL SCREEN mode!

I’m going to be putting all my old Apple II stuff on the site at some point and this is definitely the emulator that you should be running it in! Click the Emulators link at the top to download AppleWin.

So as I’m fixing up my site, you’ll notice more links appearing. Right now, most are disabled because I need to reformat those pages to match the new design.