iDevGames

I also thought hard about games which I found particularly inspiring. The classic arcade game Joust has always fascinated me, with its simple Newtonian physics and contact-based attacks. Bombjack and Defender also sprang to mind for similar reasons. Taking a little inspiration from each of those games, I wrote myself a short design document and set about my coding.

Only one question remained: what should this game be called? CodeWarrior wanted me to give the project a name before it would let me do anything else, so I typed the first thing that popped into my head—“Yoink.” It was meant to be a working title, but I have been unable to think of anything better and lots of people seem to like it as it is, so Yoink it shall be!

Programming and Game Asset Tools

Yoink was written in C++ and built with Metrowerks CodeWarrior 8, and I used Interface Builder to make the preferences dialog and the rest of the out-of-game interface. I also used CodeWarrior and BBEdit Lite to write most of the XML for the scene and object definitions.

The graphics were all drawn one pixel at a time in Adobe Photoshop 7 and the animation was worked out in the accompanying ImageReady application. Using this technique, it took a very long time to get the animation right—I must write a proper sprite editor and animator for future projects!

PlayerPro was used to prepare the sound effects and ResEdit was used to put the sounds into the game’s resource file (about the only use I have for old-style resource forks). I made good use of sound effects from the download section at iDevGames, as I was unable to create my own sounds.

What Went Right

Leveraging Past Code

Perhaps the most important decision I made was to build Yoink on top of the existing code base I had created for my previous (and still ongoing) game, Super Phoenix. I already had a maths and physics library I called M3, a simple application shell called CarbonApp and a lot of smaller pieces of code for handling things like DrawSprocket. I realized I could save myself a lot of time by reusing it. This decision wasn’t entirely clear-cut, however. By re-using M3, much of which was written several years ago when I first learned C++, I inherited all of the design flaws and bugs that it contained. Maybe I should have tried to learn something like SDL instead, but in the end I settled on reusing my own code—at least I knew what was wrong with it!

Graphical Look

With this fundamental decision made, I needed to consider carefully how to deal with the graphical aspects of the game. I intended to create all the graphics myself, so I had to make sure that there would be time to create the character and scenery graphics. With this in mind, I decided to have intentionally blocky low-resolution graphics, since I reasoned that making the sprites smaller would allow me to draw them more quickly. I then sat down and drew all the scenery graphics in about two hours! The character graphics took a lot longer, however. Even at the small size of 32×32 pixels, animation is still very difficult and I had to do a great deal of experimentation to discover the best way of animating certain sequences.

My decision to use blocky sprites and tiled scenery turned out to be surprisingly popular. I had originally been concerned that people would not accept a game with ‘primitive’ graphics, but in fact almost everyone who saw Yoink had very positive things to say about its “cute” and “retro” graphic style!

Programming Within My Abilities

Most of the programming was not particularly difficult. Like Super Phoenix, Yoink displayed almost all of its graphics using only texture mapped quads. Sprites were quads, bullets and explosions were quads, and the scenery was made out of grids of quads. There was no cleverness involved, no special optimization or usage of complicated OpenGL extensions, not even anything as simple as display lists, just the most basic form of rendering known to man. Even so, the game was very fast on all but the oldest graphics hardware, so I spent my time developing the game instead of worrying about efficiency.

XML-based Data Storage

I had some difficulty deciding whether to write a special level editor tool or whether to just manually write the level data into a text file. In the end, I decided to keep things simple and stick to hand-written data, but I created an XML-based format to store my data. I chose XML because I had just discovered a particularly good C++ XML library: TinyXML. Loading and parsing text data has never been my strong point, so by using this library to do all the hard work for me I saved a great deal of time. The downside of this decision was that creating the level data itself was time consuming and required a lot of trial and error. I will definitely make a graphical editor to build the rest of the levels!

Organization

I think I managed to remain fairly organized during the three month development period, although I didn’t manage to add all the features I wanted. I planned to release a preview of Yoink every two weeks or so, and for each new version I decided which features I should add and tried to concentrate only on those features. This helped me to focus on building the most vital parts first instead of spending time on irrelevant extras.

Game Design Tweak

I made one particularly important organizational decision: about halfway through the development period, I had a choice between adding more enemies and refining their behavior, or adding the boring things which make the game feel complete, such as the title screen, menu, and game over message. I went for the latter, and I think that was the right thing to do. I ended up with less game content, but the game felt much less like a tech demo and more like a real game.

What Went Wrong

Project Size

My biggest mistake was not so much underestimating the size of the project, but underestimating my ability to work on it continuously. Had I worked every evening and weekend for the entire three months’ duration, I would have been able to include every feature I had planned. However, as it turned out, I found it extremely difficult to keep my motivation up and my schedule suffered accordingly.

Design Document

I also had difficulty keeping my plan under control. The gameplay concept remained more or less the same throughout, but my programming methodology changed almost every week. One week I would rip out the animation system and replace it with a better designed version with more features, and the next I would completely discard object-oriented design principles and copy the entire class of each character instead of properly migrating shared code into the base class. I was very much aware that I was being inconsistent, but I was afraid that going back and fixing my mistakes would cost too much time, so much of the bad coding remained in place.

Confidence

Confidence almost failed me at one point. Towards the end of the development period I became concerned that Yoink was not of a high enough standard. I felt that the concept and the graphics were coming along well, but the game was lacking in content and gameplay, and I would not be able to fix those problems in time for the deadline. Thankfully, when I asked in the iDevGames forum whether I should withdraw from the contest, my fellow programmers managed to beat some sense into me and I was convinced to carry on regardless!

Summary

Yoink was my first attempt at completing an entire game within a fixed time limit, and with hindsight I am extremely pleased that I managed to get as far as I did. I may have failed in my self-imposed challenge, but I feel that it was a reasonably convincing effort, and the feedback I received from other developers and voters made me realize that I am doing something worthwhile.

I learned a couple of very important lessons from uDevGames 2003. Firstly, I now know exactly what I am capable of, both in terms of practical ability and motivation. Yoink is a small game, and that is all I can do in three months. Secondly, I know for sure something I have suspected for a long time: all of the ambitious ideas I have for magnificent plot-led RPGs and interstellar flight simulators are likely to be beyond my reach forever. I will certainly never be able to complete anything more substantial than a small arcade game unless I am prepared to team up with others and become a great deal more disciplined. Sadly, since my real work must take priority over my hobbies, I may never have enough time and energy to do these things.

Still, this isn’t the end of my developing days. I still intend to finish Yoink and give it the improved gameplay, extra characters and levels, and amusing plot that I failed to deliver for the contest. I will also continue working on Super Phoenix, as well as some other smaller projects such as the aforementioned sprite editor. These projects will probably all be open source and free of charge, in the hope that I’ll be able to contribute something useful to the Mac game development community.

I’d also like to enter next year’s contest. I have an idea in mind already—strangely enough, it has no cute characters, no tricky animation, no plot, nothing but gameplay! Maybe I’ll be able to finish that on time!

Joust,C++,CodeWarrior,BBEdit,XML,SDL,Carbon,retro

Inspiration

Around this time I had just picked up the book ‘Chris Crawford on Game Design’‘ by Chris Crawford. After reading it, I was totally stoked to get started, so I started looking around for inspiration. I had a feeling that if I was an inexperienced programmer and I was going to be using Flash, a tool not well known for its performance, I would need to lean heavily on my known strengths, art and music, to get a game that would fly. Also, my game could not be too large in scope, or I knew that I would not be able to finish it.

One day, I was having a phone conversation with an old friend and we started talking about the writings of H.P. Lovecraft when-bang!-it hit me that that would make a fun backdrop to the game that I wound up making. Now that I had my backdrop, I needed a fun but simple gameplay and objective, and for this I turned to the classics. I was looking at old games, and I hit on Pac-Man. What was Pac-Man really? Why he was a Lovecraftian adventurer running around a dungeon picking up lost magical stones, as he is being hunted by inter-demensional harbingers of evil. Right? Well, that’s what I saw.

The basic game would have a 3/4 view and consist of an adventurer running around a dungeon picking up precious stones and trying to avoid evil beings.

Just the Artifacts Ma’am

After doing some Lovecraft reading and some sketching out of basic ideas, I thought that it might be nice to add some elements to the game that were not in Pac-Man. The first thing that I added was gold. I thought it might be good to give the player something else to collect, thereby encouraging them to explore more of the game and set up more interesting risk/reward situations. Above and beyond this, I also added a hidden item on each level called an artifact; this was intended to increase replayability, the idea being that you would want to collect the artifact from each level.

I was talking to my friend on the phone again, and he said, “Wouldn’t it be cool if there was some sort of insanity thing in your game?” I thought he was right, so I added that as well. I made it a timer. The longer you stayed on each level, the more you started to go insane, until you were too mad to play any longer and the game ended.

Welcome to Flashville, Have a Nice Stay

I knew that Flash was not the fastest performer around, but I also knew that it did have some things going for it, like good asset management, good sound tools, built in cross-platform compatibility, and low file sizes. After some experimenting, I was confident I could pull it off with a little trickery.

Once I settled on a programming platform, I set to work writing the basic code. My first idea was to compartmentalize the code by parenting it to individual graphic level building blocks. Then all I would have to do would be to drag a tile, wall, item, enemy, or what have you, from the library onto the stage and I would have a visual level editor on my hands.

This basic approach worked pretty well, but for each tile, wall, item, enemy, and what have you that is in the level, that is one more thing that needs to be checked up on in the script. So, although I wound up using this basic idea, performance was better served by grouping together different lengths and combinations of elements. For walls, and anything that did collision checking, I made groups of objects that ran on the same axis.

The Graphics

My early tests were done in Photoshop, but I quickly abandoned this for doing the graphics in a 3D application called Lightwave 3D. Moving to 3D allowed me more flexibility when designing more complex pieces of architechtre such as columns and arches.

As I said earlier, I wanted to create a few good building blocks that could be used again and again to build the levels. With just a few objects, I was able to use them in layers, to add a sense of depth and space to the game. My goal was to give the user an immersive experience that was as seamless as possible. You really owe it to yourself and your audience to spend the extra time and effort to hide the seams. If you don’t it’s like going to see a movie and someone has thrown a Coke on the screen—it’s going to distract from the experience the whole time.

Taking it in The End

Tower of Tears took ‘2nd in Graphics’, ‘2nd in Audio’, and ‘4th Best Overall Game.’ Considering it was my first entry, and that it was done in Flash, I’m very happy with the way everything worked out. However, even though I was able to get a working game using Flash, I was constantly fighting it for every bit of performance that I could pull out of it. And in the end, it was still one of the slower performers in the competition. Next time I’ll have to use a faster platform.

• Critical applications: Flash 2004 Pro, Lightwave 3D, Photoshop

Chris Crawford,Flash,Lightwave 3D,cross-platform

A review of Sheri Graner Ray’s excellent book Gender Inclusive Design: Expanding The Market has been posted. For all too long, the computer game industry has closed out the female gamers, in the die-hard belief that “Girls don’t play games.” With the thundering success of The Sims, it’s time to rethink that. This book shows you how to potentially double your customer base, with tips that are applicable even on simple shareware games as well as Triple-A titles.

• Related Link: iDevGames Review Gender Inclusive Design

Back in the day — and that would be in the Dark Ages — girls didn’t play computer games. It doesn’t matter what logical deduction, common sense and sales figures said; they just didn’t. Then, in 1995, Patricia Flanagan started “Her Interactive” and in 1996 published McKenzie & Co., which eventually sold 80,000 units. This created somewhat of a genre of girl-oriented games, with companies like Purple Moon¹ churning out a few titles. In 1997, Mattel published Barbie Fashion Designer, and sold 600,000 units in its first year. However, by the end of that same year, Purple Moon closed down, with Mattel’s multimedia division following shortly thereafter. In 2003, Dead or Alive Xtreme Beach Volleyball hit the stores. What the heck happened?

If that little enigma didn’t spark your interest, then potentially doubling your sales might. Consider Myst, for a long time the best-selling game ever. It sold in enormous numbers, especially to women, despite not being especially tailored for a female audience. Then, consider The Sims, seen by many as one of the most female-oriented games ever. The Sims outsold Myst, Riven, and Exile in a snap, with a total of nine additional The Sims products (seven expansion packs, two special editions). As of the fifth expansion pack, The Sims had sold 24 million copies. Why? Well, it did, among other things, have a potentially doubled customer base. It is estimated that 60% of The Sims players are female — that’s over 14 million units.

Sheri Graner Ray has written the book many of us didn’t know we needed. Not only is it a sparkling sum over one of the darkest, save most stupid, corners of our industry, it is also a good game design book, and a brief summary of the latest in gender research. In a market where female customers are tended to either by The Sims or by making the cover art pink, any kind of change is welcome, and this book does look like the Holy Grail to me.

The book sets out with a brief history of our industry’s less than intelligent moves to capture female gamers, as well as its tendency not to appeal to them at all. It then moves on to explain women’s relationships to computers, another area where it is evident that the computer industry is… young. Finding a platform in the common view that early childhood sets up gender roles for the citizens in our community, Graner Ray builds a very plausible explanation as to why computers are seen as male objects. She then points out a few important points on which girls playing games differ from boys. This first part of the book is explosive enough to boost your sales, if you read it carefully. Now, there are twelve more chapters like this, so you might as well head over to Amazon and buy the book right away. It’ll pay back in no time.

See, the book is that relevant. I had already made a few plunges into this facet of game design, so I had an idea of what to expect. Still, I had an aha! experience on at least every other page. Chapter two, “Evolution of Female Characters in Computer Games”, is a discourse on what the computer game industry still finds fully acceptable in a female avatar (and to be honest, Monty Python couldn’t have done it better than we do). The chapter “Reward & Gameplay” outlines techniques to motivate female gamers and keep them coming back to your games, no pink bunnies required.

So, what does distinguish men from women — when it comes to the hard facts in a gaming context? Both a lot and little. A comforting summary of what this book is about would be to say that it is easy to appeal to both sexes, it’s just a matter of not making the same cave-man mistakes this industry is so fond of. Because, as Sheri Graner Ray re-iterates throughout the book, there’s no need to change games very much to appeal to the female gamer base — just stop driving them away (can anyone explain to me why the Tomb Raider: Angel of Darkness box has Lara’s bustline embossed in bas-relief?) And it is not about cutting the violence out; Diablo II has a stable female player base, and studies conducted by Her Interactive have shown that most female gamers aren’t repelled by violence at all.

The part on how men and women learn is also extremely rewarding, with easy-to-implement techniques on how to capture the non-hardcore gamers. For those of you who still aren’t interested into appealing to female gamers, the chapter is very useful nevertheless (why the heck you would want to close out half your customer base is your problem!). This just goes to show that behind the gender-based material, this is a genuine and very solid game design book.

‘Gender Inclusive’ is easily read, to the point, and equipped with a very nice paper quality. The reader misses out on pictures, though. In many places there are image references onto the Net, but since the book is at times very graphics-focused, its lack of images seems a little unconsidered (although I wouldn’t be the least bit surprised if this lack has to do with game companies feeling embarrassed…). Another thing that I always find impressive in a book like this is identification and adherence to a specific target group. There is very little technical talk, so it appeals to everyone within the industry. Still, it provides small nudges and aides for those who are standing on the brink of the industry. Good work there!

Take note of the title of this book — ‘Gender Inclusive’, not ‘Games for Girls’. Sheri Graner Ray goes to great lengths to help the reader make games appeal to women, but also sprinkles in quick fixes to common turn-offs that many games are riddled with. It is this facet of the book that is relevant for us here at iDevGames. While most of us won’t face the problems of hiring people for a few years to come, 90% of the book is directly applicable to the kind of games we build here (not to mention that the Mac platform is somewhat feminine in nature). Undoubtedly, though, some of us will make it to a point where sexual harassment on the job will be our problem, and by then you’ll thank Sheri for writing this book.

Quite a number of puzzling questions are answered in this work. For instance, why do women prefer bombing runs over dogfights in flight sims? If the violence isn’t a turn-off in beat-‘em-ups, what is? Why do guys feel OK about playing with female avatars, but seldom the other way around? I won’t give you the answers since I want you to go to your local bookstore and flip through this book. Then, I want you to chuck out the money for it. Among the books I’ve reviewed, I have often felt that the one at hand is important for many. This book is mandatory. I want you to buy it so much. Why? Because our industry is dead without it. Dead, I say. We need this book so badly — so badly.

Graner Ray’s book is, together with ‘Chris Crawford on Game Design’, and David Freeman’s ‘Creating Emotion in Games’ (review upcoming here on iDevGames), the absolutely essential game development book for the next ten years to come. Should ‘Gender Inclusive’ become required reading over at Full Sail and the other game development schools, the industry would change in a day. It is that irresistible and that interesting. The book is a freaking TNT charge!

• Theory of Fun for Game Design
• Rules of Play : Game Design Fundamentals’
• Chris Crawford on Game Design’
• Creating Emotion in Games’

193 pages 1st edition (September 2003)
Charles River Media
ISBN: 1584502398

¹ Now defunct game company backed by Paul Allen, dedicated to producing games targeted at girls. The company was shut down in early 1999.

PTK is a multi-platform 2D game library built around OpenGL-accelerated hardware however, it is also possible to create 3D multi-platform games with OpenGL. (Just use the PTK framework to handle the multi-platform work and concentrate on the game!) It has been designed to be as simple as possible; if you can program in Basic you can use it! It just requires a very basic knowledge of C++ and of course a C++ Compiler. Currently supported systems: Apple Mac OS X (Carbon), Microsoft Windows Linux coming soon.

• Related Link: Phelios, Inc.

TNT Basic 1.2 contains over 15 individual bug fixes and over 30 new commands. This version fixes many bugs, including source code printing not working, Genesis map editor windows not redrawing correctly and the ‘Pressed’ command not working under Mac OS X 10.2x. They’ve also added a host of new commands to this version, including keyboard access commands, which allow you to work with keyboard input very easily. In particular you can read text strings entered by the player making implementing high score tables easier than ever.

• Related Link: http://www.tntbasic.com/

iDevGames cordially invites the Macintosh community to take part in a public vote to select the winners for the third annual uDevGames Macintosh Game Development Contest. This year’s event features games in a wide range of genres such as sports, puzzles, RPGs, and 3D arcade, as well as offering over $24,000 in prizes for the winning developers.

• Related Link: uDevGames Official Site

The ‘Game Programming Gems’ series have become somewhat of a young classic—most people know of them, quite a few have chucked out the $70 to get their hands on one, and yet another few own the entire collection of three books (myself included..cough, cough).

The first book was published in 2000 with the others following in 2001 and 2002. Since ‘Game Programming Gems’‘ by Mark DeLoura, the series has evolved quite a bit, from being a little shaky to a rock-solid concept, which promises great things to come. (If the publisher decides to keep the flame alive, that is.)

Based on a somewhat unconventional form, the ‘Game Programming Gems’ offer short, extremely hands-on tips. Typically weighing in at around five to ten pages, each “gem” is a self-contained little featurette on a very narrow and specialized subject. The gems are organized into sections such as “General Programming”, “Mathematics” and “AI Programming.” As each gem is independent and written by developers themselves (often just one author per gem) there is a high amount of redundancy. This is, as usual, both a good and bad thing: you don’t have to read every gem to get the whole picture, but you get to read the same opening lines over and over. (And if I have to read another “current hardware allows the developer to create more realistic games,” I’m going thermal!)

The title contains the word “programming,” and that’s what the reader gets. There are no abstract game design principles, no “gameplay is more important than frame rate” nagging, no insight on balancing a learning curve, and just one GUI design gem in the entire series. No, instead we are treated to the gem “Quaternion Compression,” which reveals a way to store a quaternion into four bytes, and “More Trigonometric Approximations.” If abstract game design books are pillows, these books are granite slabs. Honestly, I read these books on the subway in the vain hope that someone will read over my shoulder and think I’m a clever person.

As every gem is written by a different developer, many voices come to speak, which makes each gem a little different. This is also one of the subtle strengths of the format: by seeing how various programmers write their code, attack their problems and present solutions, a lot of experience is communicated. Also, even if the primary subject of a gem doesn’t appeal to you, it is still interesting to see that process. Many of the gems communicate techniques that are easily portable to types of problems other than the one primarily handled in the gem. As the series is very thorough on cross-references to other articles in the series, the books tie in nicely with each other. Plus, with the many diverse voices, contradictions are inevitable, which is another subtle strength. While one programmer praises a technique, the next one will point out the performance problems it causes. That way, you get multiple views, and walk away a wiser developer.

The books are rich with diagrams, images, and screen shots, as well as a section with high-quality color plates of certain screen shots. Along with each book comes a CD containing code samples from the book, sample programs and hi-resolution versions of the color plates. The first book was a bit heavy on code embedded in the text, but in the latter two, the code in the book is kept to a minimum and most code samples are evicted to the CD instead, with great results.

The only drawback of the ‘Gems’ is that they are a bit dry, a little devoid of personality. But then again, they are written by programmers. (And what did you expect? The term “programmer art” exists for a reason!)

So, what do these books contain? Well, all three have sections on general programming, mathematics, artificial intelligence and graphics programming. The second book added audio programming, and the third added network programming. In the first book, graphics was split up on polygonal techniques and pixel techniques, so that might be the book to get if you’re primarily into visual programming. (Vertex shaders and pixel shaders didn’t hit the scene until ‘Game Programming Gems 2’, however, so that might be a little more up-to-date.) The first book also devotes four chapters to quaternions. It is impossible to tell which book to get by judging the quality of information—every gem might be invaluable to someone. Make sure to check the contents listing in each book before deciding upon one. They all carry the same validity.

It’s very welcome to see that game audio programming has been allowed to take up such a healthy amount of space. Hopefully, it’s a sign of a change to come. In the same way, the Artificial Intelligence department has matured significantly through the series, and in the third book it shines.

Another movement through the series is the quest for portability. Where the first book contained x86 assembler and Visual Studio-specific tricks, more and more generic solutions emerge with each new book. The third one even mentions the Mac platform, and while it will be a long time coming before anything Mac-specific makes it into print, it is a nice thing to do. (Actually, I don’t want Mac-specific material, platform-independent is always better.) It might be the work of the new editor, Dante Treglia, who took over from Mark deLoura, but of that I know nothing. The third book has two glitches with the color plates, but that’s nothing to worry about. All in all, the books have been gifted with a tremendous editing job, and they are virtually free from mistakes—a nice touch.

So, what’s the bottom line? Well, I intended to make this a review of the third book, with a bit about the old books tacked onto it, but I realized that the first two are still very valid and interesting, so there was no reason to leave them out. Which book you want depends heavily on what your interests are. Judging from polish and sheer “book quality,” the third is by far the best—it’s good to see something get better with each sequel. But make sure that you check them all out before deciding on which to get. Content is king, after all. (There, I said it myself. Graphics aren’t everything.) The ‘Gems’ will become something of a historical document, but so far they are rather timeless.

Make no mistake, though. These books are seriously hard-core, and many gems are heavy on the maths. Back-of-the-book texts imply that novices can have a use for the books: “If you are just getting started [with game programming], this book offers a true cross-section of the challenges you’ll face.” Yeah, and in doing so, it will scare the heck out of the newbie!

• The Game Programming Gems Series
  • Page 52 of 65
  • <
  • 1
  • ...
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • ...
  • 65
  • >