iDevGames

Macgamestore.com today announced Mac Games Arcade, an exciting new digital download application for Mac OS X. Mac Games Arcade allows users to download, purchase and manage their Mac games all through an innovative and easy—to—use Mac interface. With Mac Games Arcade, users will be able to browse through hundreds of digital download Mac titles from over 100 Mac developers, check out demos, write reviews, purchase games, and maintain their digital downloads. Built by Mac developers, Mac Games Arcade is the brain—child of Inside Mac Games/Macgametore.com founder and former Bungie Software project leader, Tuncer Deniz. “Mac Games Arcade makes digital downloads fast and easy.”, said Tuncer Deniz. “No more unzipping, installing, scrambling for your serial number, and worrying about losing your digital downloads. It’s the one-stop solution for Mac game digital downloads.”
Read the rest of this entry »

I began to produce Raptor to educate myself. I wanted to learn everything there was to know about TNT Basic, a new IDE I had purchased. As a result, I designed Raptor to take advantage of nearly every technical aspect of TNT, including the special sprite functions, music, sound effects with stereo panning, and more. Patrick Graham and Miyaka Cochrane joined the team when they realized how cool Raptor could be. As Raptor grew and reached many people, its final purpose has served to help us gain recognition and to entertain people.

The Team

The Raptor team, Constant Variable, was formed out of a group of friends. Patrick Graham, being a close friend of mine, has always been eager to help in anything I do. Patrick ended up designing the latter levels when I was too burnt out to continue on. Miyaka Cochrane, whom I met through Patrick, loves the genre of top-down scrollers so he was eager to volunteer his music skills. After the first few weeks of development, when things got more serious, we started having meetings over at my place.

The meetings were an interesting experience in cooperation. We sat at a circular table, each of us at our respective computer. I would work at my PowerBook G4 667MHz. Miyaka worked at his PowerBook G4 as well. Miyaka’s PowerBook is adorned with a bumper sticker that reads “Not all who wander are lost,” which reflects his personality well. He would work while a constant stream of music pumped out of his heavy duty headphones. Patrick would work on our old iMac, learning a bit about programming, making levels, and every so often checking out what I was doing. Being physically together helped with the motivation factor in getting things going. In a single meeting we might have been able to pump out one music track, one level, and one or two new types of enemies.

The Tools

During the process of developing Raptor we used a lot of software tools. For example, when producing an enemy, I might start by designing it in Macromedia Flash 4. I used this because I had no other vector drawing programs. Once I finished drawing, I would take a screenshot, open that in Adobe Photoshop and format the graphic, as well as add special effects like dodging and burning to give depth. I would also use Photoshop for the image mask. Map tiles were first made in Bryce 4, then formatted in Adobe Photoshop. Interfaces and backgrounds were done completely in Photoshop. Miyaka’s music was done in Ableton Live. All this, as well as the code, was then put together in TNT Basic.

TNT Basic is an excellent program for beginners as well as more advanced programmers who just want to create a game at a faster rate. For Raptor, it acted as the central hub, managing code, sounds, music, and map files. Its integrated map editor was a joy to use. Using it we could easily place map tiles, and map objects. Map objects could then be read through a simple bit of code which could then spawn enemies at the coordinates they would be on the map. In general, TNT Basic is very easy to use, and there are lots of well-documented examples on TNT Basic ‘s web site. This, combined with an easy to reference user manual, makes TNT Basic a formidable choice for rapid game development.

What Went Right

In the production of Raptor, we had all the right software. Using TNT Basic allowed for rapid development; its map editor suited our purposes perfectly. Adobe Photoshop also worked well, especially for compressing the graphics to comply with the contest’s 10MB imposed limit on file size. We also had access to the professional music software Ableton Live, which Miyaka was able to use very well to create music that fit the mood of the game.

Having someone besides me do the music was a real plus. Not only did it free me up to do what I really do, it also allowed for music much better than I could have found in some copyright free database. We’ve gotten a very positive reaction regarding the music.

Another positive reaction came from the fact that Raptor is freeware. I would suggest to anyone who isn’t going to make much money off of a shareware game to just avoid the whole hassle of setting up registration and release it for free. Keep in mind that people appreciate things that are free. People will rate things higher if they are free. People will send you fan e-mails if you give them a product for free.

Finally, distributing Raptor over the internet was a great experience. Submitting it to sites like Version Tracker, Mac Update, and Mac Game Files made it easy to put our game in the hands of tens of thousands of people. This instant and wide user base, which wouldn’t have been possible in the days of floppy disks, resulted in a ton of feedback. It also gave us our first fan mail. Of course for every fan e-mail we got, there were around two or three reporting bugs.

What Went Wrong

Not much went wrong with Raptor except that it suffered from an identity crisis. I had originally programmed Raptor just to teach myself TNT Basic. I didn’t know when I was just beginning the amount of time I would eventually spend on it. Therefore, I never took the time to create a design document for Raptor. In the beginning I never even asked myself what I set out to do. I just sat down and programmed.

My approach to making Raptor followed a pattern something like this: I would ask myself, “I wonder if I could program a scrolling landscape made from map tiles.” Then I’d do it. Then I’d say to myself, “That’s pretty cool, I wonder if I could add a plane that flies around.” Then, of course, I’d do that. Afterwards, being very proud, I’d ask myself if I could program a map object of a cloud and have it be read from the map file into the spawning code. The process would continue for a long time. Since I didn’t even know what what I was programming would become, there was no chance of me producing a design document.

Although it is true that sometimes games never get off the ground due to too much planning and not enough doing, Raptor suffered from the opposite. Raptor soared like an eagle unsure of its direction. I think that if I had planned by giving Raptor a plot-line, an original setting, or an original objective, it would have stood out more from the long line of scrolling games that had preceded it.

Conclusion

Raptor is my first entry to the uDevGames Contest, and my first contribution to the Macintosh gaming community. I value the uDevGames Contest because it offers incentive to develop in the form of prizes, and, more importantly for someone making shareware, it offers a deadline! A wise man once said that games are never finished, you just stop working on them. If not for the time frame set by the contest, Raptor’s development might have gone on indefinitely, and thus it would never be finished. Thankfully it’s done, and now I can look on to the future.

I’m currently learning OpenGL use that in the future to create state-of-the-art 3D games. With the prizes I’m getting out of the uDevGames Contest, I hope to be able to export the 3D models I create into a format in which a function in my future game could load. It’s going to be a long haul, but this isn’t the last you’ve heard from Constant Variable!

• Size: 9.7 MB
• Genre: 2D Shooter
• Developer: Constant Variable
• Url: http://solidmag.vze.com/raptor/
• Team size: 3
• Released date: November 17, 2002
• Project length: 3 months
• Development hardware: Two PowerBook G4s, iMac 333MHz
• Critical applications: TNT Basic, Adobe Photoshop, Bryce 5 Ableton Live

We kept our development pipeline simple. While I wrote the game code with CodeWarrior, our artists Genki and Sean created the game’s original graphics. Genki did most of the character animation, and his primary tool was the old Mac program, Aldus Superpaint. We utilized Superpaint over more complex editors like Photoshop mostly for its palette manipulation and painting tools. Sean, who created most of the level art, also used Superpaint almost exclusively. Andrew, our musician, built us several tracks using the PC programs CakewalkPro Audio 8 and CoolEdit, along with the arsenal of samplers and keyboards he keeps in his studio. Most of the game code was written on a PowerComputing PowerTower Pro 225, while the art was done using Apple’s 7600 range machines and Wacom art tablets. While we were familiar with various third-party sprite systems available on the market (e.g. SAT, SpriteWorld), we decided to build our own animation and map systems. We built the map editor into the application, and this unity allowed us to include the tool with the final version of the product. When we began development, Apple’s GameSprocket technology was still in its infancy, so we elected to write our input and drawing systems ourselves. This actually turned out to be a good solution in the long run, as we were able to tune our game to run as fast as possible.
h3. What Went Right
h4. Realistic Goals
From the beginning, we had our sights set on our desired features and their estimated development time. Though Bakudanjin ended taking almost two years to complete, this was mostly because of school and other interruptions. Looking back on the work we put into the project, I think we could have realistically finished in under six months if we had been able to devote more time to development. Our focus on design saved us several times from feature creep. We did add a few extra game modes and game play devices along the way, but we quickly discarded many ideas that seemed too difficult or time-consuming.
h4. First Playable Finished Early
When we began developing Bakudanjin, we concentrated on the core game engine features first. As a result, we had a first playable build after only two weeks of development! In this time, not only had the animation engine come together, but two character sprites, some basic level tiles, and an enemy were completed as well. Being able to test our game out this early in the development cycle was invaluable; we were able to identify design problems and control issues almost immediately. Building an early prototype also forced us to build a level editor, which turned out to be extremely beneficial.
h4. Level Design as a Puzzle
Though Bakudanjin is all about blowing up the enemies, we built each world such that puzzles could be constructed out of the levels themselves. We also added three different playable characters, each with his own attributes. We tried very hard to design levels that would be easy for some characters and hard for others, thus creating a different experience for each playable character. For example, the Soldier character, who is the fastest character in the game, has the ability to avoid quicksand. However, this ability is only useful in the first game world, making later levels more difficult.
h4. Targeting Low-end Machines
When we began Bakudanjin in 1997, we decided that our game should run on even the lowest of low-end Macs. We used my old Centris 660AV, a 25MHz 68040 machine, as the most basic system that needed to be able to run our game at 30fps. Though this required a lot of optimization of the drawing code late in development, we were able to attain our goal. As a result, our game can be enjoyed by a much larger audience than many other titles, and it drove us to write clean and efficient code. Though 68k support is much less of an issue today, I am still quite glad we made the decision to support lower-end machines. Bakudanjin was developed before Apple released CarbonLib and the Carbon Dater program, and is consequently not Mac OS X compliant. However, converting the code base to Carbon would be fairly easy, and we are considering a patch to make Bakudanjin Mac OS X native.
h4. Multilingual Support
Though it was rather last minute, we decided to include support for Japanese as well as English for the Bakudanjin user interface. Our goal was to make our game as accessible as possible, and we knew that a lot of gamers in Japan might be interested in our title. While support for Japanese did not extend past a few translated menus and dialog boxes, we did translate the entire manual, and saw several Japanese registrations as a direct result. Surprisingly, more than half of all our registrations to date have been from Europe, and in our next title we will definitely include some kind of support for European languages.
h3. What Went Wrong
h4. Part-time Game Development
Bakudanjin was developed while we were all in school, and as a result took an incredibly long time to finish. This was particularly frustrating because we had a playable game from the very start of the project. However, we realized that if we did not meet our design goals the game would not be nearly as fun, so we continued to work in our spare time. Hobby programming is quite a challenge when free time is scarce, and in our case our development time suffered immensely.
h4. Unclear Distribution Goals
We originally decided to press Bakudanjin on CD and sell it via our web site, and some of our initial design decisions were based on this plan. Our musician built five awesome tracks for our game from scratch, and delivered them to us as 40~50MB WAV files. I wrote audio CD player code with the full intention of burning CDs with the music as audio tracks. However, it became clear towards the end of development that a CD would not be feasible. As a result, we were stuck with five high quality musical tracks that took up one hundred times more disk space than the actual game. We considered compression techniques such as MP3, but our low-end target platform was too slow to decode and play such formats on the fly. In the end, we decided to distribute via the web and were forced to use only 10 seconds from the main theme.
h4. Being a Clone
Though we learned a lot and produced a great game, Bakudanjin will forever be thought of as a Bomberman clone. Borrowing a simple mechanic has been done before, and we were hardly the first to be inspired by Hudson’s great game. However, many doors were closed to us because our game too closely resembled other titles out there. One magazine even refused to run a short segment about us, citing recent problems providing software that had “similarities to programs currently available on the market.” Though we believe that Bakudanjin is an original work, we found that Bakudanjin’s concept was not unique enough to break out of clone status.

If you are a developer thinking of building a game based on an established game play mechanic or look, be aware that your game’s sales may suffer because customers will not consider your product original enough. On the other hand, it is much harder to create a fun game design from scratch than it is to borrow features from established titles, and there is a market for new versions of old games. Witness “Ambrosia”:http://www.ambrosiasw.com/; the majority of their titles are not based on original game play designs. Nevertheless, they continue to produce high quality games and generate lots of revenue. In Bakudanjin, we attempted to balance classic Bomberman game play with original characters and game play modes we added. I think that we were fairly successful, though in hindsight there are several things we could have done better.
h3. Conclusion
All in all, developing Bakudanjin was a great experience. Though not everything worked out as we had planned, we all learned an incredible amount by building the game from scratch. We have been selling Bakudanjin for almost two years now, and have been successful with a wide audience of men and women of all ages. One customer’s comment in particular made the entire experience worth all the time and effort we put into it, and reminded me why I got into game programming to begin with: “_My boys will be very excited! They love the game and we are constantly greeting one another with the noises that are derived from the game._” In our next project, an as-yet-unannounced adventure RPG, we hope to avoid some of the challenges we faced with Bakudanjin by focusing on design and the strengths of our previous projects. Our next game uses a top scrolling tile engine and a highly customizable sprite interaction system, and we hope to release our tools with the game. It is our goal to continue to produce games that are fun and appealing to people from all walks of life.

Bakudanjin

* Developer: Dream Dawn
* Genre: Arcade
* Site: http://www.dreamdawn.com
* Team size: 4
* Released date: October 1999
* Project length: Two Years
* Development hardware:
* Critical applications: CodeWarrior 9 Gold, Aldus Superpaint, Photoshop, Cakewalk 8, SoundEdit 16

Download

* Demo

bakudanjin,dreamdawn

image1.jpg
alt=”AirBurst”

Originally, Airburst was going to be a simple Warlords type game (with flying cities/castles that move about when hit) that we would write over a couple of weekends under the same Strangeware license ($3 released fully featured) as Bushfire was. This was the point where Adam had a vision of cute and colorful characters with balloons rather than bricks and the design jumped up a level into a full Strange Flavour project.

The new plan would involve Airburst being written over a period of three months. Because we wanted to write a good, solid single-machine multi-player game first, and I knew that network code would add a lot of time to the project, we decided to write the single machine game initially and then write a standard network module that would give Airburst network capability and could also be reused for future network games later.
h3. The Team and the Tools
Adam and I work in a simple team set-up: Adam handles the graphics, visual design, sound effects and music, while I deal with the coding and game design. As resident egomaniac I also handle the project management. We were fortunate with Airburst in that the normal team was boosted by some excellent volunteer testers—Thomas “Hero” Bedeau, who helped us solve a particularly tricky bug in Bushfire, and an old friend, James Rhodes, who we knew from the days when we were writing Amiga games. James’ fiance Sophia also volunteered her testing skills, which proved invaluable. One thing my years of writing games have taught me is that having testers who know what they are doing and what they should and should not bother reporting can double the effectiveness of your team.

image2.jpg
alt=”AirBurst”

Our set-up is not particularly spectacular. I do my coding on a G4 Cube with CodeWarrior and test (and sometimes code when I am feeling like a change of scenery) on my iBook 300. This is actually my main development machine for my day job as well. Adam’s G4 500 MP is dual purpose, handling graphics and sound tasks.
h3. The Creative Process
When I wrote the engine for Bushfire, it was planned from day one to be the basis for future projects, so we were able to start with the basic sprites, sound and movie engine that were already done from that game. Having started and abandoned a couple of Mac shareware games in the past due to lack of time, and struggling to bend an otherwise excellent Mac game library to work the way I wanted, I gave in and decided that I’d have to write my own. The main work on the library was completed over a period of about two weeks, by which time it was ready to handle the basics of Bushfire. Apart from a faster blit function I added in later, the engine mostly uses CopyBits for the sprites; my scrolling tutorial on iDevGames actually uses the declassified version of it. The main theory behind the engine, though, was to give me a basic set of functions around which I could write a game, without having to re-work the game to suit the engine too much. Once I have a working game, I always copy the project and strip it to a skeleton to use as the basis for the next title. With a working engine and the shell from the previous game Bushfire, I was able to get the basic concept of Airburst up and playable over a weekend. It’s really important to be able to prototype and test a game idea this way, as it gives you confidence in the design and immediate feedback as to what does and doesn’t work. I used my normal method of working on both my Mac and an ordinary hard backed notebook. I also used AppleWorks (the world’s most useful application!) to write a small bug database/completion list, although I normally do these on paper as it’s more visual.

Click to Enlarge
Notebook1.jpg
Notebook1p.jpg

BCM1.jpg
BCM1p.jpga

Maya1.jpg
Maya1p.jpg
Characters1.jpg
Characters1p.jpg

Adam had the hard job on Airburst, as his idea of writing the game as a full project with full character designs and maximum eye candy meant that he’d be doing a lot of graphics, not to mention the sound and music. We have a major advantage here in that (a) we’ve worked together as a team now for nearly 15 years, so there is less time wasted due to miscommunication of ideas, and (b) I’m pretty good at coder art, so I can do any rough artwork needed to get the game running and give Adam an idea of what we need for a particular sprite, while he gets on with the proper version. This approach also works as an incentive for Adam to replace the coder art with real graphics as fast as possible. For most of the sprites, Adam models and renders them in Cinema 4D. They are then rendered down to individual sprites that contain 64 rotations for each of the player characters and their heads. Adam also renders out Alpha masks for each sprite. These sprites are then munged together to create a screen for each group, plus a matching mask screen. Post-design work is done in Adobe Photoshop before the screens are saved out as PICT Resource files and copied into the Airburst resource file.

Knowing that Adam would be spending a lot of time on graphics for Airburst, we planned to use a more minimalist system for this game. So the music was written as 13 different 2-bar loops, varying in intensity from very calm to manic. The game would then work out how manic things were and pick the next loop accordingly. For example, the number of balls and what power-ups are in play. A couple of menu introduction and Win/Lose sequences were also required. Adam’s production method varies depending upon the project, but basically it involves writing the tracks initially using Logic Audio, with the ProTools Digi001 rig to output the final mix (which is then converted to MP3 for the game). The sound effects for Airburst made use of Adam’s Virus KB synth as well as various sample library sounds. Again, these were processed through Logic Audio and ProTools before being converted to sound resources by exporting them from QuickTime Pro.

image3.jpg
alt=”AirBurst”
h3. What Went Right
Thanks to the engine being written around the way I work, it was incorporated flawlessly into Airburst and we had the basic game running in the first weekend with coder art (a very unfairly maligned school of art). By sticking to very simple formats and utilizing a fairly rigid initial design, the art and sound slotted quickly into the game. The game logic was built up in a similar fashion and did not create too many hitches. Thanks to effective testing, the majority of bugs were squashed before release.

The main thing that did go right, and I’d attribute it mainly to being able to get the idea working as fast as possible, was the game design itself. Having originally planned to take the basic idea of Warlords (four players trying to destroy each other with a fireball) and adding our twist to it (being able to rotate the bat all the way around and making the players move around the screen as they get hit), we were able to get the basic game running in a weekend. This gave us plenty of time to work on a bonus system, which was set in stone quite early on. We’ve had great fun in designing different game types and we plan to release more in the future. Thomas suggested a “Story” mode, however this would have taken a great deal of time to implement due to the required game assets. Our testers were also a major component in the success of the project. New versions of the game would be emailed out to them on Saturday and Sunday and we’d have feedback either immediately or the next day (one in France and two in the US). The testers weren’t afraid of suggesting ideas too. Fortunately, with Thomas being a budding games journalist and James and Sophia writing games themselves, the suggestions were usually realistic and practical.

image4.jpg
alt=”AirBurst”
h3. What Went Wrong
We had a few problems with the in-game music. As with Bushfire, we were using MP3 tracks but this time we planned to use short loops and generate the music on the fly by triggering different loops depending upon the level of gameplay “manic-ness” at a given time. We had quite a few problems with the callback routines that were required and this caused the project to slip by a couple of weekends. One of the initial design decisions was to make the game 800×600 to use the full resolution of the iBook (this was just before the iBook 500 came out with its 1024×768 native resolution). Unfortunately, it was only well into development (i.e. too late to change all the graphics) that we realized that Mac OS X was just not sufficiently fast at 2D to handle 800×600 quickly enough. In theory, Mac OS X 10.1 should cure this and, since our main market is still Mac OS 9, we decided to stick with it. Having received feedback from players, it has also come to light that there are a few monitors out there that don’t have a 800×600 mode. So for the first update of Airburst we added a “compatibility mode” that lets the game be played at a higher screen resolution (for future game designs, we will probably avoid using 800×600 as a primary mode).

One area that I plan to revisit on Airburst and that has been the subject of much discussion in iDevGames’ forum is the Options/Key setup screen. This was a bit too hurried in its design, and with Mouse Control (added after requests from users who have difficulty using the keyboard) and Bat speed added to it it is definitely too cluttered and awkward to use. So I’ll be doing a new page (or two) here in the next update of the game.
h3. Wrap Up
Fortunately, the careful planning at the start of the project paid off and we were able to concentrate on the game itself rather than solving basic design and code problems. The game was released on the same day as Steve Jobs’ keynote at MacWorld New York (to catch the large number of web viewers anxiously scanning websites for news), although because of the slippage we were not able to get all of the extra bits and pieces (player skins, extra backgrounds, desktop pics, etc.) onto the website for the launch. So far, user and press reviews have been very good and registration is going according to plan.

* Genre: Arcade
* Developer: Strange Flavor
* Site: www.strangeflavour.com
* Team size: 2
* Released date: July 18, 2001
* Project length: 3 months
* Development hardware: G4 Cube, iBook 300, G4 500MP
* Critical applications: CodeWarrior, Cinema 4D, Logic Platinum with ProTools Digi001 studio

airburst,strange,flavour