MacWorld has an article detailing a lot about Xcode, Apple’s development tool for the Mac. It is a good general overview on what Xcode is, and what other programs come with it like Interface Builder, or Shark. John Welch, the author, also goes into the benefits of Apple deciding to make the developer tools available on any Macintosh. To read the article, click the link below.
Related Links:
• Macworld.com: Xcode: Apple’s not-so-secret weapon
Those new to developing on Mac OS X, or new to programming in general, can have a difficult time finding resources to aid them. Luckily there are some resources for those who need them.
Here are two resources for programming on the Mac. The first is from MacZealots.com, called “Beginning Mac Development: A Solid Foundation”, it is a short article giving a series of steps and tips for those who want to learn to develop software for the Mac. The second is a free eBook called Become an Xcoder by Bert Altenburg, Alex Clarke, and Philippe Mougin, written for non-programmers. It is hosted on CocoaLab.com and has pdf versions in a variety of languages. It is an excellent resource for new programmers. Links to these resources are below.
Related Links:
• Beginning Mac Development: A Solid Foundation
• Become an Xcoder
So after sketching out the general features, statistics, skills, creatures, and background story of the game, I put all those numbers together in a spreadsheet page. Then I had to solve a big problem—how to make the graphics of such a game? The solution was Poser, a great 3D character modeler and animator. I purchased several ready-made 3D models, and after several weeks spent on various renderings, I had the basic 48 avatars ready (20 avatars for the 4 elements plus many neutral/evil ones).
I added a role-playing element to the game, so that in addition to your “deck of cards” you also had an in-game alter ego, with an inventory of items that could affect your power and a set of basic skills that would influence the game in general.
I used Xcode and a very simple but powerful 2D programming API called PTK, marketed by Phelios. I had previously licensed this SDK for my earlier games with great success. PTK is a multi-platform 2D game engine with 3D capabilities built around OpenGL, that just requires a very basic knowledge of C++.
As previously mentioned, the graphics were mostly created with the help of Poser 5, for example the monsters and characters, and Photoshop was utilized for designing the user interface of the game. Music was acquired through the purchase of a royalty-free online source.
Since its launch the game had a good group of loyal followers. This may be partly because I decided, shortly after releasing version 1.0, to add “bonus packs” or “expansion packs” with new game features and new avatars/quests, completely free for registered users. This was both a hard move (once I had announced it, I couldn’t change my mind) but also a winning one because it greatly helped to improve customers’ loyalty and is keeping my game always “on the news” thanks to those frequent updates—usually about every 2-3 months.
As always happens in this sort of game, despite having planned everything you’ll need to perform some serious testing. When you make a simple match3 game, it is hard to have bugs after hours of playing (because game mechanic is always the same). With this kind of game, though, I had many bugs in the initial version because I didn’t take the time to test it properly, since I was too eager to release it (a mistake I will never repeat in any future games!).
I can say that this was both a very rewarding experience (I got so many enthusiastic email responses!) but also very stressful. The day after release I was working 10 hours a day to fix all the bugs and I also had a tight deadline to deliver the first expansion “The Bone Lord” in time for Christmas 2005. Also, keeping the game updated is not so simple, since I need to add more content like new art/sounds, and new gameplay elements. But overall I like this kind of game, so in this case the passion plays an important role.
* Genre: Fantasy / RPG
* Developer: Winter Wolves
* Url: http://www.winterwolves.com
* Team size: 1
* Released date: October 8, 2005
* Project length: 8 months for initial release, then an update about every 2-3 months
* Development hardware: PowerMac G4 1.2 GHz
* Critical applications: Xcode, Poser 5, Photoshop
Apple has now posted on their website a very helpful web-page assisting coders to move from the aging (and soon to be obsolete) CodeWarrior to Apple’s very own Xcode. While die hard CodeWarrior users may find this a smack in the face, and possibly offensive, the rest of the user base may find this eases their switch. Viva La Xcode.
I always liked the idea of making a fantasy-card game, so I started to outline the basic idea on a piece of paper. Yes planning was essential in this kind of game, I knew it from the start (and luckily I did it). I decided to base everything on celtic mythology, so I first started to do some research both in local library and also on the net. Found the celtic runes and thought to assign to each one of them a spell or a summoned avatar in the game. I divided the runes into 4 elements (the classic air, water, fire and earth) even if their original meaning is a bit different (but hey is just a game!). So after sketching out the general features, statistics, skills, creatures, background story, etc of the game, I put all those numbers together in a spreadsheet page.
Then had to solve a big problem, to make the graphic of such a game, and found in Poser a very good solution. Bought several ready-made 3D models, and after several weeks spent on various renderings, I had the basic 48 avatars ready (20 avatars for the 4 elements plus many neutral/evil ones).
I added a roleplaying element to the game, so that in addition to your “deck of card” you had also an in-game alter-ego, with an inventory of items that could affect your power and a set of basic skills that would influence the game in general.
I used Xcode and a very simple but really powerful 2D programming API called PTK that I had already used in all my previous games with great success. As I already said, for graphics I used mostly Poser 5 for the monsters, characters, etc and Photoshop to design the interface of the game. For the music I just bought royalty-free music from one of the many online stores.
The game had since its launch a good group of loyal followers. This maybe also because I decided, shortly after I released version 1.0, to add “bonus pack” or “expansion packs” with new game features and new avatars/quests, completely free for registered users. This was both a hard move (once I had announced it, I couldn’t change my mind) but also a winning one because it helped greatly to improve customers loyalty and is keeping my game always “on the news” thanks to those frequent updates (about every 2-3 months usually).
Despite I had planned everything, as always happens in this sort of games, you’ll need to TEST TEST and TEST. When you make a simple match3 game, is hard to have bugs after hours of playing (because game mechanic is always the same). With this kind of game instead, I had many bugs in the initial version 1.0 because I didn’t took the time to test it properly since was too eager to release it (a mistake I will never repeat in any future games!).
I can say that it was both a very rewarding experience (got so many enthusiast email feedbacks!) but also very stressing. The day after release was working 10 hours a day to fix all the bug and I had also a tight deadline to deliver the first expansion “The Bone Lord” in time for Christmas 2005. Keeping the game updated also is not so simple, since need to add more content like new art/sounds, and new gameplay elements. But overall I like this kind of games so in this case the passion plays an important role.
I even went out and bought a book on Greek Mythology to help me better understand the nature of my game. I also imported the Japanese version of Ikaruga for my Dreamcast. This was essentially my design document. I tried to stay true to as many elements of it as possible—minus the whole 3D background thing going on, though it was considered in the initial phase.
My choice of IDE was Apple’s Xcode. Once again, a wonderful environment to work in. And combined with my powerhouse of a Dual 2GHz G5, I was able to compile my source over and over again in mere seconds. This is great for fixing things up and recompiling.
I used Painter 8 to paint the background images, a most wonderful program. I also borrowed my dad’s graphics tablet. The first level is done entirely in charcoal except the water, which is oil painting. It is such a natural tool, almost as easy and a lot more powerful than traditional media. For those interested in what is to come next, I will touch up the ending of level one, and start doing level two entirely in thick oils.
Contrary to popular belief, all the entities in Icarus are in fact models. Most of them are 3D models and all of them are done in LightWave 7. While it is not the easiest tool in the world, once you get over the learning curve, it is amazing what you can do. Also, while using it for this project I learned a lot of new things you can do in it.
The project weighed in at 7,000 lines of base code. When thinking about my idea and what I wanted to do fresh off of Microbian: Fighter, I knew I wanted to do an Ikaruga clone, and since I couldn’t get a hand on Unity at that time, I knew I had HUGE stockpile of already done code. Basing off the Microbian: Fighter engine gave me the following things:
Right from the start I didn’t have to worry about adding all those standard features needed in almost every game. I could focus on what needed to get done. Of course I was going from a universe type game to a vertical scroller. This allowed me to make many optimizations to speed things up. I also needed to get some solid texturing code in there, and that is where Holmes Futrell was a life saver. I borrowed his GLTexture class and this made it a cinch to load textures and apply them as needed. Overall, I got to work mostly on my content and less on just making it work.
Miyaka Cochrane is a wonderful musician. His most notable music comes from Raptor — Air Superiority Fighter and Argonaut 2149. He also created over 20 minutes of music for Microbian: Fighter. I appreciate him very much for donating his musical talent to Icarus. He is also planning on doing two more songs specifically for Icarus after the contest is over.
I don’t know how Lee did all the models for Microbian: Fighter. Somehow he managed to color all those models using his little text-based applications. That blows my mind. I personally couldn’t do it—I’m a much more visual person. I like my GUIs and mouse so I added a vertex painting ability to my standard model viewing application, and with the click of a button, I was able to color my model in bright vivid colors with little to no effort. While the painter isn’t perfect, it was possibly the only way I could get any models done. Let this be a note: custom built tools are unmatched in productivity.
I chose a lousy time to get addicted to a game. Roughly three days after I decided to enter uDevGames, my friend James introduced me to a new map/gameplay style in Warcraft 3 called Defense of the Ancient. This game ended up consuming 1-2 hours a night throughout the entire contest. In fact I was playing it right before I started writing this postmortem! Beware other developers: they will try to suck up your time with great games.
Not only was this newfound addiction taking up my time, I was also still in school. I was in a compiler class, which also required a good deal of programming. Writing multiple thousand line programs for different causes can really tear your brain in so many ways. There was much more stress than what is really healthy. Not only this, but I often fell into procrastination. I would postpone working on my compilers project until the last three days it was due, and this caused me to lose three solid days of work instead of only losing two hours a day over two weeks. Time management is something every developer needs to learn. All of this leads to the biggest thing that went wrong.
The thing can be beaten in about 65 seconds if you are good. My original plan was for about three minutes of solid gameplay. The main reason this fell through was because I hand painted the levels. Offloading that work to an artist could have significantly reduced the workload. But as it was, I was painting the level, especially the town area, and just did not have the time to do good work and have a lengthy level done in three months. Not only did it take a long time to do my background in the style that I chose, I also found out that many gamers found this new style strange and not common in traditional games, so the graphics were not well accepted. I feel if I had more time, I could have provided more details and thus make it more liked.
The final explosion was nearly impossible to tune. In my design document, Ikaruga, the final boss exploding was supposed to bring the framerate to about 10fps. I found this near impossible to precisely gauge. Being on a G5 is a blessing and a curse for game developers.
In my ReadMe I made a promise to my fans that I would complete this game if I won a spot in uDevGames. Things that I will be adding include the nuclear homing special weapon, as per my design document, and another level or two, each between 4-5 minutes in length. Also, I plan on adding at least two more bad guys, one more boss, and of course, more patterns and evil chaining schemes. I will not be making this game shareware, because I feel by winning in uDevGames, I have received enough payment to continue releasing this game as freeware.
Snowball had a dual purpose. First, it was meant to be a successful entry in uDevGames 2004 in order to win recognition in a wider arena than just my peers. Second, it was meant as a proof of concept for an isometric engine for future game development. The intended customer for Snowball was the average voter attracted to uDevGames.
h3. Details
h4. Schedule
The scheduled development timeline included having a basic foundational engine in place by September 10th. This was to take advantage of a two-week break from my teaching job. After that I planned to begin beta testing and add features and stages weekly until November 6th. In reality, the basic engine wasn’t in place until October 19th, more than a month late.
h4. Source Code
The source code consisted of 2,220 lines of code used from my previous projects and 10,138 new lines of code. In addition, the following libraries were utilized: SDL, SDL_mixer, OpenGL, libPNG, and zlib.
h4. Compatibility
The finished application bundle is roughly 3.3MB in size and should be compatible with Apple computers running Mac OS X 10.0. It requires a video card with at least 8MB VRAM (like an ATI Rage 128) and a G3 500 MHz processor or better. The only known compatibility issues are with the Windows version of the game and have to do with resolution switching.
h4. Tools
The primary development tool used was Apple’s Xcode 1.5. For the PC version, DevC++ 4.9.8 was used. Corel’s Painter 8.1 and Adobe’s Photoshop CS were used for creating content along with an Intuos 2 Wacom Tablet. Apple’s GarageBand was used for composing the music.
h4. Credits
The writer of this postmortem, Aaron Sullivan, designed and programmed the game. Amy Sullivan, his wife, constructed the in-game stages and recorded sound effects. Sean Sullivan, his brother, composed the music.
Of note were contributions from outside this team including Eric Wing and Josh Abernathy, who helped test and fix an important bug in SDL involving mouse coordinates.
Carlos Camacho and the staff at iDevGames provided the contest under much duress and Snowball would not have been created without the motivation of this particular contest. Feedback from several members of iDevGames’ forum was also of great benefit as was feedback from family and friends and voters that took the time to reply by email.
h3. What Went Right
h4. Origin
Before uDevGames 2004, I contemplated creating a computer role-playing game (CRPG) and I decided on an isometric view in order to capitalize on having rich illustrated artwork rather than stale jaggy 3D models. As the beginning of the contest approached, I realized that a CRPG was a far too ambitious project to complete in three months, but I could develop a part of the larger CRPG game with a smaller entry. The isometric graphics engine now became the focus.
I had used OpenGL to develop two 2D games: an unfinished uDevGames 2004 entry, Bugganauts, and Space Barrage, my first finished game in decades. I had never used OpenGL for its more common purpose, a 3D game. I had a quick tech demonstration that I worked on as a proof of concept, but now I needed an idea for a small game using the isometric view.
The choice was between a 3D version of Bugganauts, involving lots of alien shooting and hostage rescuing, or a cutesy puzzle game like an old favorite of mine, Adventures of Lolo. Well, I was really leaning towards Bugganauts, until I thought that I could maybe make the small game into a part of the larger CRPG. The setting for the CRPG was to be a snow covered world. I thought about snowballs and a puzzle game and how you could use the ball rolling up snow and enlarging. I had never seen this in a game before and that spark of originality sold me on it.
h4. Graphics
The basic premise for the game was simple, and I expected that most of the work would be in creating the graphics engine. This was okay, because that was one of the two primary goals. I despise aliasing (jagged edges rendered on the edges of objects, especially prevalent in 3D games) and after great success with using glAArg1 to polish Space Barrage, I became somewhat obsessed with removing as much aliasing as possible from this game. While this took time from other aspects of the game, I learned the most from this part of the development.
Spending so much time on the graphics delayed my beta testing by more than a month, however! I include this under “what went right” because I waited till very near the deadline (a day or two?) to reveal Space Barrage. Even a month late is a big improvement over my last attempt.
h4. Workflow
I had a reasonably efficient workflow that included posting updates for whoever would read my blogs at uDevGames and visit my personal web site about progress on Snowball. I made an effort to keep these updates from becoming a distraction.
I kept the web page very simple with an easy process for adding screen shots. I had a couple of long winded blogs, but I used them as a way to process what was going right and wrong and to think through what the next goal needed to be. It kept me accountable to a public audience (even if it was just an illusionary one) that would know if I was sticking to the goals rather than going off on a time consuming tangent.
h4. STL
I finally embraced the STL (C++’s Standard Template Library.) I made it a point in Space Barrage to simply avoid dynamic memory all together in order to sidestep time consuming memory leaks, because I knew I could easily derail in such a short time span. In this project, I dug into the STL. One investment I made was buying the book ‘Accelerated C++’ by Koenig and Moo. I highly recommend it to beginning programmers and anyone who isn’t acquainted with using the STL and likes to use sample code and tutorials.
At first I found using some of the STL conventions cumbersome, feeling a bit like wading through Java-type convolutions to perform simple actions. After working with it a bit, I learned to really enjoy the peace of mind that comes from avoiding the responsibility of plugging memory leaks. I didn’t get in too deep, really, just some vectors, strings, and maps, but I’ll never look back.
h4. Code Reuse
Reusing some code from Space Barrage and the unfinished Bugganauts gave me a boost at the start. I relied on SDL for window and graphics setup and a custom PNG texture loader that I think is mostly code by Keith Bauer (a.k.a. One Sad Cookie). I used code I had set up for music and sounds (though the sound effects never made it in) that relied on SDL_mixer.
h4. Cross Platform
Using these cross-platform libraries made the port to Windows very easy. I’ve found that developing on two platforms really helps refine your code. One platform catches some errors that the other might not.
h3. What Went Wrong
h4. Time
The obvious and probably most common problem in software development is difficulty predicting the length of time parts of a project require. This is especially true for inexperienced programmers. When one has never programmed a 3D game, how is one to estimate the length of time it will take to complete a 3D game engine? One guesses.
h4. Design Document
My work schedule was very full at the start of the contest, but I anticipated a two week break and worked on a design document and engine ideas in the spare moments in between teaching classes. I carried a growing stack of papers covered in cartoon sketches, schematics, and formulas. I never took the time to formally compile it into a design document and although you’d think that was a bad thing, it wasn’t that bad.
From working on Space Barrage for the 21 Day Later Contest I knew that a tight schedule meant I’d be keeping it mulling around in my brain at all times anyway. I did eventually keep a list of tasks to complete as I approached the end. So, for a longer term project, especially one with more than one programmer, I would say that not having a detailed design document was something that went very wrong. For this short term project, however, my stack of papers was enough for this single programmer to stay reasonably on track.
h4. Schedule
That said, my schedule went way off track. I was determined to get a playable out to the public as soon as possible to avoid the problems I had with Space Barrage, but I released it a month late.
I had time to clearly identify the areas that needed to be improved in order for the game to do well in the contest, but I ran out of time to implement the changes. Some of the problems identified were:
* The WASD keyboard controls were just right for some, but unnatural for others. Custom keyboard options were needed.
* One unexpected discovery is that some players found the learning curve too easy and gave up before it became challenging.
* Mouse control was something I didn’t plan until I realized there was a simple and effective way to implement it. The mouse control made it much easier for inexperienced gamers to play compared to the keyboard control, but led to some confusion as well.
* People were much more inclined to play through if they knew the total number of stages but the game never gives them a hint.
* Everyone wanted a way to continue if they stopped playing and came back to the game later.
* Snowball’s music soothed some and got on the nerves of others as it constantly repeated for hours with no interruption, if you played that long.
In fact, I was very pleased that just one element could be stretched so far and it helped me to accept that this project was worth continuing beyond the contest.
h3. Conclusions
h4. Fun
Overall, I’m satisfied with the state of the game that was completed during the voting period. Because I delegated stage design to my wife, there was plenty of content for players to explore even if the amount of variety was low. The team members had fun working on it and I know that many people had fun playing it.
h4. Some things that I learned
bq. a. A game’s difficulty curve is one of the most important ways to keep a player playing. If the target audience has a wide range of skill levels, there had better be options that allow them to play how they want right away. I had comments that there was no challenge to the game or that there were far too many “easy” stages. In smoothing out the difficulty curve and forcing people to play through the “learning” stages I had turned off the less casual gamers.
bq. b. Players want to know how far away the conclusion (or the next goal) is. Players who did not know the number of stages either gave up, or lost interest early on. As soon as I told players the number of stages, they would play to the end.
bq. c. I can’t stand aliasing. Many casual gamers have not learned to ignore aliasing and I’ve even heard one person say, “Did you see all the rats?” referring to the crawling pixels on an aliased line. The amount of work and time I had to invest to help remove “the rats,” however, seemed to be worth it. I still get a big reaction from many players when they rotate the stage for the first time. Many simply expect it to stay flat because of the style of the imagery.
bq. d. Sound effects make a big difference with people’s response to the music and the game overall. There are sound effects recorded for Snowball but getting them in the game was one of those tasks that kept sliding off the priority list. The impact of the player’s actions and the level of immersion felt by the player is greatly reduced in this soundless game compared to, say, Space Barrage. Also, there are comments from players about loving the music, but many could not stand the unbroken repetition of the single track during game play, no matter how good the music might be.
h4. Conclusion
Snowball was meant to be a contest winner and an engine test for another game. In part it has succeeded but I’ve really grown to believe that Rollo the Snowball has a much bigger exciting life ahead of him.
My plan is to bring this game to a commercial level of development. In the coming months, I’ll be using all the brilliant feedback from the participants in this contest and taking the time to add all the fun features that were so painful to cut from this abbreviated version. This time, the goal will be to finish a game worthy of a player’s hard earned cash.
1 Developed by arekkusu
Genre: Puzzle
Developer: Aaron Sullivan
Url: http://homepage.mac.com/aaronsullivan/projects/snowball.html
Team size: 3
Released date: October 19, 2004
Project length: 4 months
Development hardware: Powermac G4 Dual 1 Ghz, Wacom tablet
Critical applications: XCode, Adobe Photoshop, Garageband