Silly Balls

The Tools

I used CodeWarrior 5 and ResEdit for all the programming and development. On the graphic front, Photoshop 3 and GraphicConverter were utilized to create and edit textures for the game. The sound samples came from various freeware sound libraries. As the 3D models didn’t contain complex geometry, they were coded in directly.

image2.jpg

alt=“Silly Balls”

What Went Right

One of the best decisions I made was to create an editor for Silly Balls. Although this took some time, the amount of time saved in creating all the levels was enormous. The editor is far from perfect and still requires the use of ResEdit for complete level creation. However, having the editor allowed me to submit the game on time. I’d like to advise new game programmers that a good level editor will not only save time, as in my case, but also contribute to the game’s development process.

The format for the levels was flexible in that I was able to add in extra features without the game engine breaking. This is another tip for new programmers: when creating your format to contain your game’s level, plan ahead so that new features can be added without the need to create major modifications to your game code. I hope to continue development on the level editor so that I can release it to the public in the future.

What Went Wrong

As you play your own game continually from concept to finish, your own view of how easy and how good a game it is tends to change. Hence the importance of outside play testing is crucial. This is something I didn’t do until a little too late. Silly Balls is far too hard in my view, although I can complete it without losing a life. The other major problem with Silly Balls was the lack of a design document for the uDevGames 2001 version. My plan was to release the game for uDevGames and continue work on the game even after the contest was over. However, knowing which features should make it to be included in the contest version became a challenge. Looking back, I should have made a concrete decision on what features would make it into the submitted game, and which features would be added at a later time. The music was also a weak point in the game. It was added at the last moment so I wasn’t able to test it thoroughly. (Note to self: never add features on the day of final submission.)

image3.jpg

alt=“Silly Balls”

Conclusion

As for the future, my next project is to Carbonize (and debug) Silly Balls. Then I will continue to work on that and a 3D tank game. I’m also looking to enter the Independent Games Festival ‘student competition’ after Christmas. Looking further ahead, I plan to move away from Carbon and concentrate completely on Cocoa and Mac OS X. Like many developers, I have always wanted to write an adventure game, so perhaps I might go in that direction when the time is right.

I found that it was great to work against a deadline, and it made me concentrate on finishing what may have taken years otherwise! My advice for uDevGames 2002 developers would be to get your game out as soon as possible. This allows for more play testing and polishing of the game before the voting period begins.

My last comment concerns public feedback. It is a vital process for fine-tuning a game so that it is fun and runs well on a variety of machines. However, I recommend that you find some committed beta testers early on and don’t count on the public for 100% of your testing. The reason is that some players may not be eager to re-download a large game due to limited connection speed or interest. I think that setting up a home page specifically for your game entry that allows gamers to easily add their comments or to download small patches before the voting begins would be a smart move.

Overall, the competition was a great success and the benefit to the community in terms of working code is enormous. I look forward to browsing the code from the other games and hope that uDevGames 2002 will be an even bigger event.

  • Developer: William Thimbleby
  • Genre: Arcade Puzzle
  • Site: http://www.www.tribar.dabsol.co.uk
  • Team size: 1
  • Released date: September 12, 2001
  • Project length: 1 month
  • Development hardware: G4 400MHz MP
  • Critical applications: CodeWarrior, ResEdit, Photoshop 3

3D,puzzle,RedEdit,Cocoa,Carbon,CodeWarrior

Bakudanjin by dreamdawn

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

REAL Software Sponsors uDevGames 2001

FOR IMMEDIATE RELEASE:

CONTACT:

Carlos Camacho
iDevGames.com
+81-087-869-7357
http://www.idevgames.com

REAL Software joins uDevGames 2001 as an official sponsor

Takamatsu City, Japan — August 30, 2001 — iDevGames is proud to announce REAL Software’s support for uDevGames 2001 — the Macintosh game programming contest. REAL Software announced today that it would become an official sponsor of uDevGames 2001, the Macintosh game programing contest created by iDevGames. With the addition of the powerful new 3D engine, RbScript, and the many other enhancements and improvements to REALbasic in version 3.5, it’s an even better tool for creating fantastic games for the Macintosh, Mac OS X, and Windows.”, said Geoff Perlman, President and CEO of REAL Software. “We’re very excited to be supporting the Mac game development community through sponsorship of the uDevGames 2001 contest. We all love games and look forward to seeing the results!”

uDevGames 2001 was organized to help highlight the talents and abilities of the Macintosh game development community. “REALbasic has enabled many Macintosh users to enter the field of game development. We are extremely excited to have REAL Software on board as an official sponsor of uDevGames 2001 and look forward to seeing more entries utilizing REALbasic.” said Carlos Camacho, Editor-in-Chief of iDevGames. “Support by the Macintosh community for uDevGames 2001 has been wonderful and new game entries are being added every week. In addition, REAL Software’s prizes have helped push the total prize pool to over $4,200 (US)!”

Additional Information about the contest can be found on iDevGames’ website:
http://www.udevgames.com

iDevGames would also like to thank and acknowledge the generous support provided by uDevGames 2001’s sponsors: Aladdin Systems, Inc., Digital Technology International, Eovia, IK Multimedia, Metrowerks, Onyx Technology, Inc., REAL Software, Replica Technology, STAZ Software, Strata Software

About REAL Software
REAL Software’s products make the process of developing powerful applications fast and efficient. REALbasic is easy enough for beginners and powerful enough for professionals to use. Independent software companies, corporate MIS programmers, researchers, and hobbyists all use REALbasicto build applications faster and easier than ever before. Founded in 1996, REAL Software, Inc. is based in Austin, Texas.

About iDevGames
Established in 1998, iDevGames’ mission is to educate, support, and enhance the Macintosh Game Developer community. We also hope to facilitate the exchange between developers and designers so that the Macintosh game market can expand and improve. iDevGames features articles, the latest industry news, tutorials, an active forum, downloads, and much more for Macintosh Game Developers.

  1. # #

Airburst by Strange Flavour

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

The Return of Marathon

A Game with a Story

Marathon is one of the most memorable Mac games of all time. In 1994 Bungie Software introduced fast-paced 3D action to the Mac platform, while retaining the eerie atmosphere of its adventure-oriented predecessor, Pathways Into Darkness. Although its gameplay was reminiscent of Doom, Marathon remained true to the spirit of the Mac with its intelligent storyline and user-friendly interface. After three years and two sequels, the series arrived at Marathon Infinity, and with it came a sense of closure. By that time most of the missing pieces of the game’s convoluted storyline had been put into place and the Marathon engine had aged to the extent that it was no longer commercially viable. The three commercial games to license the Marathon engine suffered from the technology’s pseudo-3D architecture and lack of support for emerging hardware acceleration standards. However, at the same time, independent scenario designers were perfecting their Marathon level editing skills through the Mac’s only comprehensive set of mod-making utilities.

Marathon for the Masses

For most developers, releasing the source code to their game is like giving away the crown jewels. However, with id Software releasing the source code to their hit first-person shooters, some developers are slowly realizing the benefits that this can bring to the industry as a whole. On the Macintosh platform, Bungie was one of the first AAA title developers to release their source code. When Bungie released the Marathon source code to the public I immediately realized that this was a potentially great thing for Mac gaming. As one of the few Mac-first 3D action games, Marathon has always held a special place in the minds of Macintosh gamers. Unlike most AAA title games that started on the PC and were later ported to the Mac, Marathon was a game that Mac users could point to and say “Mac first.” On top of this, Bungie always provided comprehensive scenario creation tools. I was not sure what developers and game fans would do with Bungie’s gift but I crossed my fingers that support for hardware acceleration, better monster AI, and multiplayer internet play would be added by Mac programming gurus. My love of Marathon, however, was not the only reason I wanted to see this old 2.5-D game engine catch up to the likes of Quake and Unreal. For as long as the Marathon map editing tools had been available, I had been plugging away on my own scenario and I was motivated by the knowledge that any enhancements made to the Marathon engine would automatically enhance my own efforts.

Marathon Open Source is Born

The good folks at Bungie.org were easily convinced that the Marathon community needed a web site to coordinate the development and distribution of an improved Marathon. I set up shop at http://source.bungie.org and collected news for the site from the frenetic discussions held at alt.games.marathon. It took a few days to get the released code into a compilable form but from that point onward, Loren Petrich and others began adding new features and compiling builds on a regular basis.

In the beginning, the Marathon code was quite a challenge to decipher. In fact, I did not know if the code could even be modernized to allow for new features! I decided to be conservative in creating the group’s mission statement:

  • Track the development process
  • Promote an organized team approach to help prevent duplication of effort
  • Provide the latest source code and executables

The first objective was easily done. I keep a close eye on various projects and networked with many groups so that new Marathon developments were posted shortly after they are announced. The second objective was a challenge during the early days. In a couple of cases, programmers who were unaware of the collective of programmers affiliated with source.bungie.org put in some long hours implementing features that had already been accomplished. However, I am happy to report that things are going much more smoothly now. Coverage at Inside Mac Games and MacAddict helped us to reach a wider audience and when Slashdot ran a story on the project many Linux users took notice and increased our total hits by 20 percent in a single day!

With the project well organized, redundant development is now a thing of the past. The organized team effort has been key to the project’s success. A large to-do list was assembled very early on, with many of the ideas coming from Marathon fans themselves rather than the programmers. The creation of a mailing list for the project became very popular and proved to be more beneficial than the to-do list and even the news group alt.games.marathon’s. My efforts to make the development process more efficient also involved assembling a collection of programming resources, including lessons on how to compile the source, archiving important developer rants, and reference information on the specifications of Marathon’s data files.

To the disappointment of some scenario designers, the features that were requested were not always the ones that were implemented. Some ideas have lingered on the Suggested Features page at the Marathon Open Source site for months without being addressed, and occasionally a feature is added to the game without ever having appeared on the Suggested Features page. The programmers’ detractors point out that if the scenario designers’ requests are not added to the engine then programmers will have themselves to blame for the lack of interest from the mod-making community. The programmers’ defenders counter that since open source programmers are unpaid volunteers they have the right to add whatever features they want. In actuality, programmers devote their limited time and energy to implementing what they are capable of adding to the game rather than enslaving themselves to the whims of the non-programmers. Suggested features like multiplayer gaming over the internet and support for 3D model characters have often taken a backseat to more modest, attainable goals. Fortunately, during the nineteen months that have progressed since the release of the Marathon source code, the programmers’ skills have improved and with it their willingness to take on ever larger challenges.

Enhancing Marathon

Surprise! A more powerful Marathon engine has emerged, and with it comes a potential renaissance of scenario design. It is fitting that in taking the game beyond Marathon Infinity, open source developers branded their builds Aleph One, a mathematical term for the infinite set of real numbers. Having acquired a name that no commercial software publisher’s marketing department would ever have put forth, one might wonder what other unexpected changes Marathon has undergone. Since January 2000 Marathon has gained a wide assortment of graphical and functional improvements and yet has retained its compatibility with the countless scenarios that have been developed over the years by the fan community.

Some of the modifications to the engine, such as a scripting language, new level creation tool and support for true 3D polygonal structures, have been aimed at increasing the creative possibilities for scenario designers. Others, like support for hardware acceleration and an optional third person perspective, enhance the perceived quality of existing content. Some have worked at increasing Marathon‘s audience by offering builds for Windows, Mac OS X, Linux, and BeOS. Those with design experience have opted to provide new icons and splash screens for the game. For my own part, I have helped maintain the Marathon Open Source Web site at source.bungie.org, which is my attempt to promote the game to an audience that normally shies away from anything as esoteric as open source software.

Our efforts are resulting in a game engine that is slowly becoming more cohesive and robust. With features like OpenGL texture smoothing and improved mouse control having been implemented, there is little left to add to the engine that could make Bungie’s original levels much more enjoyable. So recently programmers have made life easier for scenario designers, which should be welcome news to mapmakers who are interested in making sophisticated 3D game environments.

From Scenario Designer to Developer

Any potential scenario designer should assess the long-term viability of the Marathon engine alongside that of the Mac platform’s other mod making options. Will there be a place for the engine five years from now, or will superior systems take root? Well, for the last five years, Marathon has provided Mac gamers with their only comprehensive tool set for creating first-person 3D action games. In the unlikely event that this remains the case, then further development of the Marathon engine could be the only thing standing in the way of a complete exodus of creative gamers to the PC platform, where mod making tools abound. One way or another it should be possible to create, on the Mac platform, enjoyable games with graphical sophistication rivaling that of PC game mods.

Companies that port PC games to the Mac, like Westlake, are sometimes held responsible for the lack of Mac ports of level design tools for the games they port, but it is really a financial decision made by the publisher. Programmers at id Software, on the other hand, seem to be ensuring that the design tools for their new cross-platform games are themselves cross-platform, increasing the audience which can author mods for their game and increasing the game’s worth to the customer. Meanwhile Garage Games V12 engine (used for Tribes 2) and the Dim3 engine from little-known Klink Software, are being readied as inexpensive stand-alone Mac game design platforms. These two products are essentially content-free games bundled with mapmaking software, scripting languages and tools for importing data from common 3D model formats. Those who aspire to make a 3D first-person shooter without writing thousands of lines of C++ code should consider what Marathon offers but be aware of the more advanced but less understood V12 and Dimension 3 engines. I would like to finish with an overview of what Aleph One has to offer scenario designers and developers.

  • The Marathon Markup Language (MML) allows scenario designers to override Marathon‘s default behavior. New features such as a wider cone of vision or animated textures must be “turned on” through an MML script. If an MML script is not present then the Marathon engine behaves as it would normally. MML scripts may be embedded into the resource fork of a map file or stored as independent text files.
  • The Pfhortran scripting language moves characters, modifies the contents of the player’s inventory, adjusts the color and density of fog, controls the camera, manages variables and tags, inflicts damage on characters and even changes the background music—all dynamically.
  • Aleph One takes advantage of hardware acceleration on all platforms through OpenGL. Both textures and sprites benefit from smoothing, MIP mapping, and any other features that may be offered by the user’s hardware, such as full screen anti-aliasing. Support for 24-bit textures of all resolutions has gone a long way towards modernizing Marathon‘s appearance.
  • Scenario designers will soon be able to insert true 3D architecture into levels through MML. The designer of this “Bridges and Balconies” technology has come close to perfecting his creation, but builds with support for 3D inserts are not yet publicly available. Future map editors are expected to allow for the easy addition of such inserts.
  • The basic level design and physics editing tools have been around for years and are very useful as long as you’re properly schooled in the art of bug avoidance. Fortunately, much effort has been put into the development of new tools to replace the old ones.
  • Since Marathon has been released under the GPL, the source code is free to anyone who wants it. No million-dollar licensing fees apply! On the other hand, you cannot sell any products you create using the Marathon engine. Those who hope to sell their creations might consider programming a game in REALbasic or investigating the inexpensive licensing policies of The Tribes 2 or Dim3 engines.
  • The Marathon engine has become very robust. Its fault tolerance is evident in its perfect compatibility with my own levels, which have been teetering on the brink of corruption—my levels have long since become too complex for the original Marathon engine to handle.

Final Thoughts

Clearly Aleph One has some impressive strengths and is getting better all the time. Nevertheless, developing for Aleph One has its difficulties. I will leave you with the best and worst experiences I have had developing for this engine:

Worst Aleph One Experience

An undocumented memory leak in Aleph One’s scripting language Pfhortran resulted in crashes in levels that utilized moving cameras. I was left with no option but to strip my cut screens of all their moving cameras. I then focused on adding 3D inserts to my levels, a process that went pretty smoothly. Months later when the Pfhortran camera bug was fixed, my moving cameras instantly regained their functionality. However, the enhanced Pfhortran code has yet to be integrated with the 3D inserts technology. I am left with three options: use 3D inserts, use Pfhortran, or use both, and hope for the future release of a build that supports the combined features.

Best Aleph One Experience

On several occasions I have received new builds of Aleph One that made my existing levels look and play better. It has been my experience that programmers can sometimes read minds—features that I had been hoping for have at times magically appeared in the engine.

return,of,marathon

Vortex NG by Feline Entertainment

Student Development
First, a little background material. I’ve been interested in making games since I taught myself HyperTalk when I was twelve. I later learned C/C++ in my freshman year of college. As all of you who are in or have gone through college know, intro level Computer Science courses do not offer enough to begin game development right away. This is where those who have a great desire to make games strike out on their own. A copy of the book ‘Tricks of the Mac Game Programming Gurus’ was a good start for me. I would have loved to have taken a course in college using it as the textbook! Two 2D shareware games and nearly four years later I began Vortex Next Generation. Over the next year and a half I learned OpenGL, Open Transport (a nasty and bloated API IMHO), InputSprockets, and several other APIs needed to make a product of commercial quality.

Of course, there are hurdles a student developer must overcome other than simply learning how to program. Although time and determination are certainly factors, a student developer also needs to acquire the tools to handle artwork, sound and 3D model generation. For 2D image processing, I would suggest Adobe Photoshop (if you’re lucky enough to be able to afford it), or use GIMP. There are several freeware and shareware alternatives, but I have not used any so I cannot comment on them. For sounds, I used an older shareware program named SoundEffects, which still works quite well today.

In the beginning, I defined simple OpenGL models by hand. However, anything complicated required the services of a good modeling program. Finding the right program turned out to be tricky, since unlike paint and sound programs there is no standard OpenGL model file format. This means that you need to write custom code to read in the output of whatever modeler you choose. I already owned a copy of Ray Dream Studio, and its full feature set is wonderful for creating pre-rendered graphics. However, it was a little too bloated and under-documented for my purposes (especially on its file format). What I really needed was a simple model editor that exported to an easily readable format. My answer was Joe Strout’s Meshwork! This deceptively simple trimesh modeling program has a slew of handy features, but even better it exports to many different file formats. And although I didn’t use it, there is sample code on the Codenautics website that converts 3DMF files to an OpenGL compatible file.

With the right tools and the programming knowledge, the student developer now has everything they need to create a great game. So, that’s it? Not quite—students also have the unique opportunity to meet and interact with the game development community and to display their game to hundreds of viewers at the Game Developer’s Conference for free! How is this possible?
h3. Independent Games Festival’s Student Showcase
Perhaps the best thing to happen to small-time developers since open source has been the Independent Games Festival. It is a unique opportunity to get out and interact with others in the game development community. While it is a neat chance for all independent developers, in my opinion students stand to gain the most from the experience. For more info on the regular IGF, please refer to www.indiegames.com.

Vortex Next Generation was one of the top five finalists in the First Annual IGF Student Showcase, and this was by far the best thing to come out of developing Vortex NG. For winning the Showcase, myself and up to five others were given free passes to go to the 2001 Game Developers Conference in San Jose, California (for the overly curious, this amounted to nearly $3000 in prizes of itself). They also gave the winners $500 in travel expenses—a huge benefit for me since my wife and I flew cross country to get there. At the Conference I was supplied with a display pod near the front of the main Expo doors to show off Vortex NG to any and all who wished to see it! The advice and opinions I got from this alone were worth the trip, not to mention the Conference itself and all the developer parties you get to attend.

So, what are the rules? Simply have a working game by January 10 of next year and submit it on three separate CD-ROMs. No submission fee required! Of course, you are not allowed to have any in-depth help from development professionals, you cannot have signed on with a publisher, and you must be a full-time high school or college student (please refer to the web site for complete official rules).

Was it hard to get into? Not really, I just got in touch with the person in charge to make sure a Mac only game was OK to enter. I encourage more Mac OS student developers to submit their best work, and perhaps you’ll be there next year! This year they are going to have ten Student Showcase winners, instead of just five as in 2001. It would be a shame if my next game is the only Mac OS one there next year.
h3. What Went Wrong
h4. Supporting Mac OS X
From my own experience, supporting Mac OS X this soon was probably my worst mistake in developing Vortex NG. The game is still having trouble just getting a full screen OpenGL context on many systems! There were also major performance problems with glTexSubImage2D() and glDrawPixels(), dropping Vortex’s 40-50 fps down to a terrible 8-10 fps. The lack of InputSprockets was also harsh, and left the keyboard as the only available input device. Getting mouse deltas proved impossible to do with Carbon and CodeWarrior without gutting the entire event messaging system and replacing it with Carbon Events. I even had trouble getting the sample source code to compile! I will admit that many of these problems magically disappeared in my recent efforts using Cocoa. The Cocoa development environment is very powerful and simple to use and I have had nothing but joy in my experiences using it, except for the fact that there is still no easy way to get a full screen OpenGL context in Cocoa!
h4. Vector-based Font
A design mistake on my part was implementing a generic vector-based font to use with OpenGL (as opposed to creating a sprite-based alphabet). My main reason for doing this is that I wanted a scalable solution that would impose the least performance hit possible. However, many people felt that it was hard to read and distracted greatly from the nice graphics around it. This is a mistake I will not make twice!
h3. What Went Right
h4. Protective Memory in Mac OS X
Yes, believe it or not I did find many good things about Mac OS X. One cool thing was the side effect of running on Mac OS X’s protective memory. Quite a few bugs were flushed out when trying to get Vortex NG running on Mac OS X, bugs which Mac OS 9 would happily ignore till it finally crashed.
h4. Industry Networking
Getting in touch with the folks from Macally was also very rewarding. They sent me a couple of developer seeds of their new iShock II controllers, and I was able to add support for them before going to the IGF Student Showcase. Based on my experiences with them, the folk at Macally are super people who are dedicated to releasing new and different products for the Mac. Who else is pushing to bring us Force Feedback? No one—not even our beloved Apple!

Of course, no one should write a postmortem for a Mac game without mentioning the warm and welcoming community that Mac developers share. There are so many knowledgeable people out there, and it seems that many of them do nothing but answer questions posted to the various newsgroups and mailing lists. If you get stuck, there is almost always someone who has solved the same problem, and they’re more than willing to help you through it.
h3. Wrap Up
Despite the mistakes and trials from Vortex Next Generation, I am already working on my entry to next year’s IGF. I won’t say too much about it here, but due to the nature of the game, it will require a huge open beta to help work out issues that I could never hope to solve alone. Stay tuned to Feline Entertainment’s website for further news!

* Developer: Feline Entertainment
* Notable: Student Showcase Winner – Independent Games Festival
* Genre: Arcade
* Site: homepage.mac.com/felinegames
* Team size: 1
* Released date: May 2001
* Project length: 1.5 years
* Development hardware: PowerBook G3
* Critical applications: Photoshop, CodeWarrior, Meshwork

vortex,ng,feline,entertainment

uDevGames 2001 – Macintosh Game Programming Contest Opens

FOR IMMEDIATE RELEASE:

CONTACT:

Carlos Camacho

iDevGames.com

+81-087-869-7357

http://www.idevgames.com

uDevGames 2001 — Macintosh Game Programming Contest Opens

Takamatsu City, Japan — July 16, 2001 — iDevGames is proud to announce the official opening of uDevGames 2001, a new Macintosh game creation competition!

Since its inception, iDevGames has been a stalwart supporter of game developers who write for the Apple Macintosh platform by providing news, articles, tutorials and a forum where advice and ideas can be freely exchanged. To help highlight the talents and abilities of our readership and the wider Macintosh game development community we have organized a new competition: uDevGames 2001.

Simply write a game that runs on an Apple Macintosh computer and you could win prizes from a prize pool that retails at over $3700! Any game genre is welcomed and entries are permissible from anywhere in the world. The contest closes on September 16, 2001 and winners will be announced on October 1, 2001. “With the release of Mac OS X and new machines on the horizon, this is an exciting time to be a Macintosh game developer. We hope this contest will energize developers and enhance the state of gaming on our platform,” said Carlos Camacho, Editor-in-Chief of iDevGames.

More information about the contest and how to enter can be found at the uDevGames home page:

http://www.udevgames.com/

iDevGames would also like to thank and acknowledge the generous support provided by uDevGames 2001’s sponsors: Aladdin Systems, Inc., Eovia, FaceSpan, IK Multimedia, Metrowerks, Onyx Technology, Inc., Replica Technology, STAZ Software, and Strata Software.

iDevGames was established on December 3, 1998 to educate, support and enhance the community of programmers and designers that produce games for the Apple Macintosh platform. iDevGames aims to cover the needs of the professional and novice alike, as well as providing an interactive forum to help disperse the technical knowledge and experience of our readers to the whole community.

  1. # #

Introduction to 3D in REALbasic with Rb3D

by Joseph Nastasi

rb3d01.jpg

alt=“A-OK! The Wings of Mercury

Introduction

In this article, I will be previewing REALbasic3D (Rb3D), a real-time 3D graphic engine to be included in REALbasic release 3.5. First, I’ll present a quick overview of the engine, then go into more detail and finally, provide a simple demo program to demonstrate Rb3D. I have been using Rb3D as the 3D engine on the new version of my spacecraft simulator, A-OK! The Wings of Mercury and have almost a year’s worth of extensive experience with it.

REALbasic has taken the Mac OS development world by storm. Widely recognized as a breakthrough product, it continues to evolve and improve rapidly. Developed by Real Software, REALbasic has always been targeted as a development platform for games. The very first release included a 2D sprite surface that allowed fairly complex 2D and pseudo-3D games to be created. But what if you wanted true 3D? There were several choices, including OpenGL wrapper classes and a full-featured, but not-yet-released, commercial plug-in. Last year, REALbasic software engineer, Joe Strout created a 3D plug-in for REALbasic, called Rb3D. Unlike wrapper classes, which forced you to think like a C++ programmer instead of a REALbasic programmer, Rb3D followed REALbasic’s syntax and object-oriented approach principles.

At the suggestion and request of its customers, including yours truly, Real Software has decided to bundle Rb3D as an internal feature of REALbasic. This has huge implications for programmers looking for a rapid 3D development environment. It also means that 3D programming in REALbasic will be supported on both Mac OS and Windows.

A Quick Look

Rb3D contains four classes and one control. That’s it! We’ll get into some detail below, but basically, there’s a control for defining the view and the camera that’s creating that view, and four classes that define 3D points, orientations, objects and groups of objects. As stated above, if you are familiar with REALbasic, you’ll feel right at home with the syntax.

Rb3D allows you to control all the basic properties of a 3D entity: position, orientation, size and visibility. It also provides basic camera, light and environment controls. Rb3D runs on top of Apple’s now defunct QuickDraw 3D or the open source, multi-platform replacement, Quesa. Quesa runs on top of OpenGL. The good news is that having it built upon two open source graphic platforms allows Real Software to add enhancements that are incorporated into Quesa by other programmers.

alt=“Software Layer”

rb3d02.gif

Rb3D is not in the same league, feature-wise as large, commercial 3D engines. However, the engine does have a few neat tricks up its sleeve that are especially useful for those trying to create a program that doesn’t require a PowerMac G4 600MHz or a 1GHz Pentium III. Its initial simplicity can be an asset to developers for several reasons: First, REALbasicis a great entry-level approach to programming. If Rb3D sported a huge feature set, it would no doubt be too daunting for a beginning programmer. Secondly, Real Software has consistently sought the advice and ideas of its core customer community, so this represents an opportunity for the REALbasic development community to participate in the design of this new 3D engine. But it does provide a very good platform for 3D applications-not just games-with minimal complexity and cost.

Since REALbasic is a compiled language and Rb3D is just a compiled library that is linked in, your 3D programs run fairly quickly. Programming in 3D can be daunting to the beginner. Having sweated out the transition to real time 3D by various methods, I can safely say that, unless you need advanced visual effects or need 30 complicated models moving at 60 frames per second, REALbasic’s Rb3D will suit you just fine.

What You Need

Now that I have you dreaming of making your next game a 3d hit, let’s take a look at what will be needed. First, you should visit Real Software and download (better yet buy) REALbasic 3.2. along with a copy of the Rb3D plug-in. You can also use the current developer release of REALbasic 3.5. Next, you will need a copy of the latest OpenGL SDK, and the latest Mac OS build of Quesa. Alternatively you could use QuickDraw3D instead of Quesa. If you’re using QD3D, you don’t need OpenGL. QD3D does its rendering via RAVE. Most users of classic MacOS already have QD3D 1.6 installed, unless they’ve run the QuickTime 5 installer, which actually removes it. (You can put it back by running the installer again and choosing Full or Custom install.)

The Rb3D Control

The basic control of Rb3D is named, appropriately enough, Rb3DSpace. It exists on the REALbasic control bar and is dragged on to the window of your choice, as you would the canvas control. In fact, Rb3DSpace’s basic properties are the same as the RectControl class as far as Position and Appearance go: width, height, visible, etc. New for the 3.5a2 release is that Rb3DSpace can handle all the usual events directly (MouseUp, MouseDrag, MouseDown, MouseEnter, MouseExit, Open, Close and DropObject). With the plug-in you had to handle mouse clicks in the window that Rb3DSpace was in.

There are a set of Initial Properties that can be set in the IDE. In fact, that is our first limitation. With two exceptions, these properties must be set in the IDE, you cannot adjust them while the program is running. This limitation will be removed for the final 3.5 release, though.

  • Hither and Yon — These properties define how close and how far away and object can be from the “camera” inside Rb3DSpace and still be visible. You can save lots of processing time by making this range as small as possible for your application. More importantly, Hither and Yon affect rendering quality; if the yon/hither ratio is too large, you get visual artifacts such as “scissoring” and other unwanted effects.
  • FieldOfView — This property defines the “camera” lens. A lower value will narrow the viewable field, acting like a telephoto lens. Conversely, a larger value will create a larger viewable field, simulating a wide-angle lens.
  • SkyColor — This property allows you to set background color for this particular Rb3DSpace. This is sufficient for simple games and object editor applications.
  • AmbientLight — This property sets the non-directional lighting source. A larger value means more light. Generally, you set this to a value about 30% of the next property, FloodLight for average contrast. A very low value would result in a more dramatic lighting effect and a high value would result in a “washed out” look.
  • FloodLight — This property sets a directional light source. As with AmbientLight, a larger number means more light. Another limitation: you cannot change the position and direction of this light. The position is fixed at an infinite point at -X,+Y,-Z, and is pointing to the center of the coordinate system, 0,0,0. This is a good general “portrait” position: up, to one side and behind the camera. At some point (not 3.5 though) this will be made variable, indeed a separate light object will probably be included to allow complete flexibility.
  • Wireframe — This is a boolean property that allows you to toggle how the models get rendered by Rb3DSpace: shaded or wireframe. Wireframe is sometimes useful for a 3D object editor or to create a “Sci Fi” 3D look. This property can be changed during run-time.
  • DebugCube — This property is boolean, a new addition for Rb3DSpace and very useful. It basically creates a background with all the axes marked. When you move objects or rotate your Rb3DSpace camera around, you can see exactly what section of the coordinate grid you are pointing at. This can be enabled or disabled at run-time which is handy for debugging and super for 3D editors.

alt=“Properties”

rb3d03.gif”

There two methods associated with Rb3DSpace, typically accessed in a MouseUp or MouseDown event. FindObject takes an X,Y coordinate within Rb3DSpace and returns any Object3D (more below) that lies on that point. In a shooting game this method can be used to verify if a target has been hit. FindPoint is similar: pass it an X,Y coordinate and it will return the equivalent 3D point. Very useful for 3D editors as you can know the 3D position the user is pointing to.

Rb3DSpace has a Camera, Background and Object property associated with it. These three items are specialized version of Rb3DSpace’s core classes, Object3D and Group3D. The Camera object can be positioned and rotated. The Object property is basically an array (Group3D) that you can add objects to. Every Object3D that you append to Rb3DSpace’s Object property will be visible in that Rb3DSpace, provided that the Object3D’s visible flag is true and the Object3D is in the Rb3DSpace’s field of view.

Background works exactly like the Object property except for one major difference: The Ambient and FloodLights do not affect any Object3D in the Background group. This is useful for things like a sky box; you don’t want shading on air! The Background’s position relative to the camera is fixed. This means that when the camera moves, the background moves as well. This is an important characteristic, because it makes the background appear to be infinitely far away; no matter how you move, you don’t get any closer to it.

Vectors

How does one know where an object is in a 3D world? The Vector3D class contains that information. You can assign it any 3D location by setting its X,Y and Z properties. There are methods to find the point’s distance from the 3D origin (Length(), LenSquared(), to find the angle between two 3D points (dot()), and to find a 3D point that is perpendicular to the plane defined by two 3D points (cross()) and to scale a 3D points distance from the origin to one (normalize()). Other Rb3D classes inherit the Vector3D class to define their position in 3D space or vector. I’ll explain this point in a bit.

Quaternions

Which way is an object facing? Welcome to the wonderful world of quaternions. The concept for these little gems came to a math whiz Sir William Rowan Hamilton in 1843 while walking to the Royal Irish Academy where he was the Astronomer Royal. As he passed the Brougham Bridge, he carved the basic equations into the stone of the bridge. Usually when I’m crossing a bridge, I’m wondering why it just cost me $7 US to cross the Hudson River. Oh well, I’ll never be knighted!

Quaternions are a very handy and stable way of representing an object’s orientation. If you’ve dabbled in 3D before, you may know that there are other ways of representing orientation, matrix, Euler angles, etc. All have limitations that can cause major visual problems. I won’t go too deeply into what the Quaternion object can do, but here’s the basics. The properties are W, X, Y and Z, but you’ll rarely set them directly. You can set an object’s orientation, one axis at time by using SetRotateAboutAxis. You pick an axis and give it the angle you want to set it to (in radians). It’s important to remember that this is an absolute orientation, not relative. To rotate an object by ‘X,’ you’ll need some other methods defined below. As with Vector3D, other Rb3D classes inherit the Quaternion class.

Objects

Now we get to the big kahuna, Object3D. As stated before, an Object3D has a Vector3D, the Position property, and a Quaternion, the Orientation property, associated with it. Another new property for the 3.5 version of Rb3D is the Scale property. For example, an object can be made twice as large or twice as small by setting this value to 2.0 and 0.5, respectively. The Visible property is a boolean value that allows you to instantly hide or show an object. The neat thing with this is that you can load all your Object3D’s at the beginning of your program and selectively make them appear. Objects that are not visible take very little computation time. They do take up memory though, so you need to be aware of this and set your application’s memory requirements (Classic Mac OS) appropriately, if you have many complicated models.

Shape is a very powerful property. When you first set up an Object3D, you load a 3DMF file into it (see below). You can load multiple 3DMF objects into it and then change the Shape instantly under program control. If you were displaying a cloud, for example, you could model several subtle variations, load them into Object3D and then change the Shape for a dynamically changing cloud!

Object3D has many powerful methods. When we discussed Quaternions, we mentioned the ability to rotate an object in a relative manner: turn left 45 degrees, for example. The Pitch, Yaw and Roll methods take an angle (in radians) and rotate along the particular axis by that amount. Important point: yes, these are Euler angles, BUT they are being converted to Quaternions by this method; you still get all the benefits of Quaternion’s mathematical stability. You can move an Object3D by changing its Position. In some applications, like a first-person maze exploration game, there is a much simpler method: MoveForward(). Let’s say you make the Rb3DSpace Camera (remember, it’s just another Object3D) rotate to look up, down, left and right. Passing the MoveForward method a positive value will move the Camera that many units; an negative value moves it backward.

How do you get a 3DMF model into an Object3D anyway? Currently a 3D model must be a 3DMF file. 3DMF was the meta file standard for Apple’s QuickDraw 3D and while QD3D has gone the way of the dinosaur, 3DMF is a fairly well supported format, even in the Windows world. It came in two flavors, binary and text. Although Rb3D can handle both, I prefer text for two reasons: text is much more robust and allows for modification of a model after it is exported. So you set up a typical REALbasic text stream read procedure that passes the entire file into a string. You then declare a new Object3D and use the AddShapeFromString method to convert the 3DMF string into a REAL (pun intended) Object3D.

In some applications, you may want dozens of the same object. Let say you’re creating a 3D Space Invader game and each row has 10 aliens that are the same. No need to load ten individual objects. Once an Object3D is created and a 3DMF model loaded, you can use the Clone() method to assign the same Object3D to another Object3D. What’s the point? Cloning simply refers to all the geometry and textures of the initial Object3D. This is faster because you don’t have to have ten separate file loads, and takes up less memory because only one set of geometrical attributes are stored.

Sometimes you don’t need a 3D object. Sometimes a simple 2D image will do. AddShapePicture() takes a REALbasic Picture class and a Scale value as parameters and loads them into a previously created Object3D. You then treat it as any other 3D object. A typical example might be a backdrop of a skyline that will be so far from the camera that a 3D version is not required. The only trick to this technique is that the image is visible from one side only. If the Rb3DSpace Camera moves behind it, the image will disappear. In cases where this might happen, you only need rotate the Object3D that contains the image so it’s always facing the Camera. AddShapePictureWithMask takes an additional REALbasic Picture class and uses it as a mask.

Groups

The final Rb3D class is Group3D. As the name suggests, this class allows you to treat a whole bunch of Object3D classes as one. Since it is a sub class of Object3D, you can do all the same things to an entire Group3D as you can to one individual Object3D. You can load parts of a car (wheels—remember to clone three of them, body, etc.) separately, then load them all into a Group3D that represents the entire car. You can then move or rotate the entire car by moving or rotating the Group3D. Note: this takes more processing time to do than manipulating each part separately. If you have a complicated model or have a lot of other things going on, this is not always the best approach.

The Append() method adds an Object3D to the Group3D. Remove() does just that and you can pass either the Object3D name or its index into the Group3D. Forget how many objects you shoved into a Group3D? Just call Count() which returns the number of objects. By keeping track of and passing an Object3D’s index into a Group3D, you can access it using the Item() method. This allows you to, let’s say make a part of larger model visible or not.

In our discussion of the Rb3DSpace class we mentioned that the Object property is really a Group3D class. Finally, if you’ve changed the Group position or orientation, and want this change to be applied to all of the group contents, just call Update(). This is only needed to update a Group3D that is not visible and therefore being drawn by Rb3DSpace.

Creating a Demo

I’m going to build a very simple demo program and go through it section by section. I will use two of the models included in the demo that comes with the latest alpha release of REALbasic 3.5, but you can download the finished program and models from here as well.

Open a new REALbasic project and drag the Rb3DSpace control on to the default window. Let’s leave all the properties at their default values, with the possible exception of the SkyColor. That blue makes me gag!

Now let’s create a new method, loadModel. We’ll make it flexible so we can use it in other programs later:

<br />
Function loadModel(filename as string) as Object3D<br />
Dim obj as Object3D<br />
Dim f as FolderItem<br />
Dim input as TextInputStream<br />
Dim data as String<br />
// load the 3DMF model<br />
f = GetFolderItem(filename) // assume it's in the same folder<br />
if f &lt;&gt; nil then<br />
input = f.OpenAsTextFile // has to be text files<br />
data = input.ReadAll // get 3DMF data as one big string<br />
obj = New Object3D // create new Object3D<br />
obj.AddShapeFromString data // load model data into new Object3D<br />
end if<br />
return obj // calling code should make sure this isn't nil.<br />
End Function<br />

Now we need to put the call to loadModel someplace. In simple programs, the easiest is in the open event of the Rb3DSpace control itself. So, in Rb3DSpace1 (the default control name), lets put the following code:

<br />
Sub Open()<br />
Dim obj as Object3D // storage for one model<br />
obj = loadModel("Penguin.3DMF")// load the model an assign it to obj<br />
obj.position.z = -300.0 // move the model in front of the camera<br />
me.objects.Append obj // append obj to Rb3D's Objects group<br />
End Sub<br />

That’s it. Just hit run. There is our little flippered friend in all his tuxedo glory. Kill the application and change the FieldOfView from its default of 50 degrees to 20. Nice close up. Okay, let’s go the other way and change FieldOfView to 100 degrees and run. Looks a little lonely!

alt=“Field of View

rb3d04.jpg

Remember that we put the penguin 300 units from the camera (which is at 0,0,0 by default)? Let’s change the Hither from its default of 5 to 260. We’re telling the Rb3DSpace Camera to ignore the first 260 units in front of it. If all has gone right, our friend should be without a bill and hole in his pot belly. Now change Hither back to 5 and change Yon to 260. Now we’re telling the Camera to ignore everything after 260 units. We should see one penguin bill and belly! Set the Yon property to 10000.

alt=“Hither and Yon”

rb3d05.jpg

Now let’s play with the lights. If you set the AmbientLight value to 0, then our penguin will look like he belongs in a Batman movie, nice and sinister looking. (A dark skycolor works best for this.)

alt=“Sky Color

rb3d06.jpg

Checking the Wireframe option will expose the model’s framework. Finally, try checking the Debug Cube option. You’ll see that left is -X and up is +Y. What about the Z direction? Add this line to the end of the Open event method:

obj.visible=false

Hit run and the penguin will be gone and we can see that we’re facing the -Z axis.

Remove the last line and add the following:

me.background = loadModel("Background.3DMF")<br />
// load the background model into the Rb3D background object

Make sure the Yon value is set to 10000 and run. Now you’ll see a simple land/sky background. Go back and play around with the light settings and you’ll see that they do not effect the background.

alt=“Background”

rb3d07.jpg

Camera Movement

Let’s add the ability to move the Rb3DSpace Camera. In the main window’s KeyDown event method, place the following code:

<br />
Function KeyDown(Key as string) as boolean<br />
select case asc(Key)<br />
case 28 // left arrow<br />
Rb3DSpace1.Camera.Yaw 0.1 // rotate left 5.625 degrees<br />
case 29 // right arrow<br />
Rb3DSpace1.Camera.Yaw -0.1 // rotate right 5.625 degrees<br />
case 30 // up arrow<br />
Rb3DSpace1.Camera.Pitch -0.1 // pitch up 5.625 degrees<br />
case 31 // down arrow<br />
Rb3DSpace1.Camera.Pitch 0.1 // pitch down 5.625 degrees<br />
case 11 // page up<br />
Rb3DSpace1.Camera.Roll -0.1 // roll left 5.625 degrees<br />
case 12 // page down<br />
Rb3DSpace1.Camera.Roll 0.1 // roll right 5.625 degrees<br />
case 43 // keypad +<br />
Rb3DSpace1.Camera.MoveForward 10.0 // move forward 10 units<br />
case 45 // keypad -<br />
Rb3DSpace1.Camera.MoveForward -10.0 // move backward 10 units<br />
else<br />
return true<br />
end select<br />
Rb3DSpace1.Refresh // IMPORTANT must refresh the Rb3D control<br />
return true<br />
End Function<br />

Now the you can move the camera around (and therefore the first person viewpoint) using the arrow, page up/down and the keypad +/- keys. Note that 0.1 used in the Pitch, Yaw and Roll methods is one tenth of a radian.

Making Models

A fair number of 3D modeling programs output 3DMF files. Some don’t do a very good job of it or they produce very detailed models that result in huge, complex files. Rb3D’s creator, Joe Strout is also the author of a very cool modeling program, Meshwork. This program was designed from the ground up to produce low polygon count models, especially tuned for real-time 3D. In addition to 3DMF files, Meshwork can import and export 3DS, DXF, POV-Ray, VRML and other formats. The cost is a paltry $30 (there’s a demo available) and there’s an active user email list as well.

Conclusion

The Rb3D is an incredible addition to REALbasic’s repertoire. Now even beginners can create fairly sophisticated 3D applications simply and quickly. I’ve only touched on Rb3D’s capability. The normal and developer release REALbasic lists are already discussing Rb3D, so you’ll pick up ideas there as well as general REALbasic knowledge. As a taste of what you can do with Rb3D here is a development screen shot of a Mercury/Atlas launch from my product A-OK! The Wings of Mercury. The flames are animated, as is the smoke and there are over 40 parts that move, get ejected or spew flame or smoke in that one model. This is a straight screen shot with no image editing.

alt=“Rocket Launch”

rb3d08.jpg

Acknowledgments

Thanks to Joseph Strout for creating this fabulous addition to the REALbasic feature list and for his support and mentoring me on 3D over the last 2.5 years. Additional thanks to Geoff Perlman for having the wisdom to listen to his customers and for adding Rb3D as soon as it made sense to do so. Finally, I need to thank my incredible wife, Sheila, and my wonderful children, Nick, Julian and Sierra, for putting up with the impossibly long hours spent in development of A-OK! WoM. We’re rounding the final bend, guys! All my love!

Bio: Joseph Nastasi is a free lance multimedia programmer and producer. Living in New Jersey with his wife and three children, he is a contractor for Flash, Director and REALbasic projects. A life-long space enthusiast, he has been a consultant for many space-related projects, including movies, NASA history projects and web events

introduction,3d,realbasic,rb3d

Dee Brown of Beenox on Coldstone Engine

Sounds like a great ad for REALbasic. Do you have a close working relationship with REAL Software?

Not really. I do submit bug reports and occasionally post to the developer mailing list but that’s all. I used to be more active in the REALbasic early years.

Let’s talk about Coldstone. Is it written in C/C++ with CodeWarrior?

Coldstone Engine IDEColdstone is divided into two parts: the editor and the compiler. The editor lets you manage the different parts of your game and put them together to create the story and gameplay. The compiler then takes all this stuff and creates a stand-alone application on either Mac Classic, Mac OS X or Windows. The editor is almost 100% REALbasic code but the compiler and the resulting applications are 100% C++. This allows for fast and professional games. We used Metrowerks CodeWarrior to develop the engine core.

Which graphic tools are your artists using?

Photoshop, 3D Studio Max and Graphic Converter.

Can you give us a brief overview of the use of sprites?

First, the sprite engine supports multiple layers and sprites of any size. This lets you create any type of world you want by placing several different pictures here and there, or you can use one big picture for a whole map (like in Baldur’s Gate). The sprite engine (and editor) doesn’t make any distinction between an animation and a still picture (with little exceptions). This means that you can use the very cool (yet powerful) animation editor to create an animation and just add it in the map, in any layer you want. Second, the engine is true 32-bit color, which means that translucency effects are possible with picture formats that support alpha masks such as PNG. Also, all the game “windows,” like the shop interface for example, are rendered by the sprite engine to make them platform independent.

What is the max size that a sprite (character/monster) can be and how many frames per character does it allow for?

There is no limit. You can have an 800×800 character but it may be hard to control on screen. As for frames, it’s unlimited and really up to you. You could let your game take 200MB RAM if you wanted to.

How large can the game world be and how many objects can it contain?

Coldstone Engine IDEOnce again, RAM requirements are your only true world limitation in Coldstone. However, if you want to be able to edit a 1000×1000 map in the Coldstone Map Editor, you may have to give some more memory to the application. RAM really is the only limit you have. Give it more RAM and it will give you the power you need to create that 5000×5000 map you always dreamed of!

Is the screen size set, or can the developer adjust it?

The developer can decide at which resolution and color depth the game will run.

Does Coldstone allow for enhancement through plug-ins?

Coldstone allows enhancement to the game but not to the engine itself. A Coldstone developer has the option to enable plug-in support for their game. So hopefully a good community of plug-in developers will also grow. Things like creating a new renderer or new battle engine through a C++ plug-in aren’t possible though.

Can a saved game file be used in a different game besides the one it was created with (i.e. a sequel)?

When you create a Coldstone game, you have to specify a creator code. If a developer creates a sequel to their game and gives it the same creator code, the saved game would be compatible between the two games.

Are physics used in the game?

There is no real physics engine in Coldstone. You could easily fake physics with the animation editor and its keyframe animation abilities though.

Is the combat system flexible or hard-coded to a fixed game system rule?

Coldstone Engine IDEThe combat system core is hard-coded but the gameplay isn’t. While you can’t recreate the AD&D combat system, you can be very creative in your opponents’ look and behavior. PoG, the game we are developing with Coldstone, is a good example of this. We have standard rush-at-the-enemy monsters, but we also have original ones like earth elementals that summon earth columns from down under you (and that hurts!). The spell system is also very open and opens a wide range of new possibilities to the game designer.

Could you tell us about the magic system?

Theoretically, the magic system in Coldstone works with spell points. You could, however, use the event system to script yourself a new kind of magic system. Who said that it must be called “magic” anyway? You could create a futuristic game and call those “Bionic super powers” or something neat like that. The nature of these spells or bionic powers is all yours to create! Coldstone is bundled with a user-friendly spell editor.

Can the developer add custom key commands for their games? (E.g. use the spacebar or W key to change weapons.)

Coldstone offers the developer the ability to create “global keydown events,” which are basically events that are fired when the player presses a certain key. At this point, the only limitation is the event system.

Will Coldstone support networking or online play?

No.

Does Coldstone create a double-clickable application or does it require a run-time engine?

It creates a stand-alone application for Mac OS Classic, Mac OS X, Windows 95/98, and Windows ME/2000.

Coldstone will be released for classic Mac OS and Mac OS X simultaneously. How much work was it to Carbonize Coldstone?

REALbasic seamlessly did most of the work for the editor. REALbasic has some nasty Mac OS X bugs so I had to code a couple of workarounds, as well as modifying the interface and the help system to fit Mac OS X standards. The compiler of Coldstone is, however, pure C++. Again, it wasn’t that much work since it has been designed from the start to compile on Mac OS, Mac OS X and Windows.

What made you decide to approach Ambrosia Software to publish Coldstone?

Coldstone Engine RPG GameAmbrosia has the online infrastructure required to support such a product. They have a very good web board system that will let the Coldstone developers exchange tips and tricks, as well as a good archiving system so that the Coldstone community will have a place to download up-to-date add-on files for Coldstone and upload their creations. This will also let people of various professions (musicians, 3D artists, etc.) meet and create cool new games. Beside this, Ambrosia has a cool and helpful staff, not to mention their marketing potential in the Macintosh gaming market.

Will developers be required to pay a license fee for commercial titles released?

Such details are unsure at the moment.

Do the Beenox, Ambrosia, or ColdStone logos appear in the finished game through ABOUT screens, required readmes, etc. (in other words, will players know they are playing a Coldstone game)?

Again, this is not set in stone but the developer will probably be required to display the (very nice) Coldstone badge somewhere in their product.

coldstone06.jpg

Can you compare RPG Maker and Coldstone Engine?

They both let you create RPGs but the difference lies on the creation freedom level. RPG Maker lets you create an RPG within a fixed frame. That makes it easy to use because the creator can concentrate on the content rather than the packaging. While Coldstone offers very good tools to let the user shape their own worlds, it also provides them with the ability to modify the container: game interface, menus, even a plug-in system that you can enable to let other developers write add-ons to your game. To make things simple for beginners, Coldstone comes with a game wizard that creates a fully working game frame for you to modify. Coldstone comes up with a default medieval set but allows you to modify it at will or start from scratch and create your very own style. You can have your very first game up in minutes.

How did you decide on how difficult it was going to be for someone to create a game using Coldstone? For example, making it simpler to encourage beginners, or making it more difficult to discourage less motivated users from producing low-quality games.

Coldstone Engine RPG GameThe goal was to make an engine that is appealing for both the wannabe game developers and professionals that want to quickly create outstanding cross-platform games. Coldstone is like Mac OS X — a powerful core wrapped in a beautiful user-friendly interface. Coldstone also comes with more than 10,000 graphics and animation files to help beginners create professional-looking games. There will be some low-quality games produced with it of course, but those will help the Coldstone community by providing game examples rather than hurt it, I think.

  • Position: President/CEO
  • Developer: Beenox Inc.
  • Url: http://www.beenox.com
  • Bio: Dee worked on Bugs Bunny: Lost in time — a PlayStation title — as a logic developer and tool programmer. He also worked on three upcoming PlaStation games: 3-2-1 Smurfs! as a PlayStation programmer and project lead, Bugs & Taz: Time Busters, and The Grinch who stole Christmas as a tool programmer.

How to Get More Sales for Less Work

Introduction

One of the best ways to increase your shareware sales is obvious: release a new product. Of course, this is much easier said than done. But what if there were a way to develop and release a new product in just a small fraction of your normal development time, perhaps just a couple weeks or maybe only a few days? And what if you could launch this new product simply by listing it on your existing order form without having to create a shareware version or doing any uploading at all? You can do all of this simply by releasing an add-on for one of your existing products.

Adding On

An add-on is a product that piggybacks onto one of your existing products. Typically, it requires installation of the original product to function. Examples include new levels for a game, new images for a screen saver, a set of templates for an HTML editor, and new filters for an image editing program. There are three main ways to increase your shareware sales: acquire more customers, get customers to spend more money, or get customers to buy more frequently. Releasing an add-on can actually help you achieve all three of these simultaneously.

Getting More Customers

First, add-ons can help you acquire more customers. Listing add-ons on your order form sets you apart from other developers by showing a strong commitment to supporting the original product. Potential customers may also figure that your original product must be a winner if you’ve decided to release an add-on for it. Add-ons can also increase the amount of time a customer spends using your product, thus increasing the chance for word-of-mouth sales.

Making More

Secondly, add-ons can get customers to spend more money when they buy from you. Many customers will buy an add-on when they purchase the original product, especially if the add-on has an attractive impulse price, so you gain an immediate and permanent sales increase just by listing it on your order form. Some customers who think the price of your original product is a steal will purchase the add-on simply because they expected to spend more. Other customers will purchase the add-on with the original product because they don’t want to have to come back and buy it later. If you don’t sell add-ons, you are probably leaving extra money on the table that your customers are willing to give you.

Something New

Thirdly, add-ons can get your existing customers to buy from you more frequently. Add-ons allow you to offer something new between major releases. People who have already bought from you in the past are likely to be comfortable buying from you again. For a quick boost in sales, announce a new add-on prominently on your web site, in your newsletter, and through any other mediums you may have to reach previous customers.

Less Effort

An add-on can be very quick and easy to develop and requires no shareware version or distribution. Designing an add-on is simpler than creating a whole new product because you are building on an existing framework, and often little programming is required. Best of all, you can release an add-on with little risk, and if it succeeds, you can release additional add-ons for the same product. It is possible to eventually be earning more income from add-ons than from the original product.

Even if you sell upgrades to your existing products, there are compelling reasons to release add-ons as well. First, with minor modifications, you may be able to sell the same add-on for every version, especially if it’s just a data file. Also, it gives you a whole separate product to sell in addition to upgrades. Since an add-on doesn’t require a separate shareware version or uploading to shareware sites, you can release many add-ons in the time it takes to develop a full version upgrade.

Target Marketing

Additionally, you can release multiple add-ons to target specific segments of your market. Split your market into pros vs. beginners, male vs. female, seniors vs. youth, etc., and target specific add-ons at those groups. If you find that one of your products is being used heavily by a certain demographic, consider releasing an add-on for their specific needs. For instance, for a game, you can release an add-on of insanely difficult levels for experts plus another one of super easy levels for young children. You may also find that many parents will impulse buy a child-oriented add-on for their kids.

The Payoff

Take some time to think of creative ways you could develop a simple add-on for your best product. If you can think of something that might only take a week to create, but you imagine that only one in ten previous customers would likely buy it, would it be worthwhile? I released an add-on for my best-selling product earlier this year. The add-on took only 5% of the time it took to develop the original product, but it is earning 25% as much money as the original and is outselling all of my older products by itself. Sales of the original product increased significantly after releasing the add-on. Because of this I plan to release several more add-ons for the same product, and I’m designing future products with expandability in mind. So if you’re looking for a fast and easy way to increase your sales without taking the time to develop a whole new product, consider expanding one of your existing products. The risk is minimal, but the payoff can be significant.

Copyright 2002 by Steve Pavlina

Bio

Steve Pavlina is President of the ASP and CEO of Dexterity Software, an on-line game publisher dedicated to releasing retail-quality games through shareware channels. You can find Steve interacting with Dweep addicts at his website, Dexterity.com.

how,to,get,more,sales,for,less,work

iDevGames Forum

iDevApps Forum