Slashdot Mirror

The next MTV Music Awards show will feature a Best Video Game Based on a Movie award, reports Gamasutra.com. Titles up for the award this year include "Spider-Man 2 (Activision) and Chronicles of Riddick: Escape from Butcher Bay (Vivendi Universal Games), and also titles such as Harry Potter and the Prisoner of Azkaban (EA), Van Helsing (Vivendi Universal Games), and The Incredibles (THQ)".

Gamasutra has a feature up entitled Making a Case for Short Games, in which the author argues that a good short game is far and away preferable to attempt than an epicly long game. From the article: "Which would you rather play, a computer game that takes forty hours to complete or one that lasts just a few minutes? Don't be too quick to answer. The former asks for a serious time commitment. The latter says come and go as you please. One is a ball and chain. The other is a 'Get Out of Jail Free' card. Well, it's not exactly that bad but considering all of the things you have to do today, which type of game do you really have time for? Also, isn't it peculiar that when you complete a complex or lengthy game you rarely want to replay it, yet short games are often endlessly replayable? "

Gamasutra has a lengthy article discussing many aspects of The Psychology of Video Games. The article discusses why we play, why games are made the way they are, and tips for designing for members of our species. From the article: "We are all familiar with the feeling we have when we are completely caught up in a great game. The state where we are completely focused on playing, and all other things become irrelevant. This article is about that feeling - why we get it when we play games, and how we can design games that give us more of it."

According to Gamespot Asheron's Call 2 players don't have long to wait before the "Legions" expansion will find its way to store shelves. The content expansion for the graphics intensive game went gold this week. Players of the original Asheron's Call will have to wait until this summer to enjoy their new content, as the expansion has been pushed back for further testing and refinement. Additionally, MMOG industry veteran Jessica Mulligan used the expansion announcements as an opportunity to mention her departure from Turbine. She hasn't publicly stated a reason for her departure, saying only that the decision is unrelated to the expansion titles. Gamasutra has an interview with Ms. Mulligan about the state of the industry up from last week. From the Gamespot article: "Legions will include a new continent, called Knorr, which will increase the size of the Asheron's Call 2 world by 30 percent. Also included in this expansion pack are new playable races (one of which is the much maligned Drudge), three new prestige classes, more than 100 new quests, and 10 new monster types."

Gamasutra.com is hosting an analysis of Myst IV: Revelation. The author explores the good and bad points of the game's production, and reveals interesting moments from the development process. From the article: "Less than a year before the end of the project, things were not going well on the Myst IV: Revelation team: no single zone was in a finished state, communication was difficult between team members and puzzles were taking too long to prototype. We looked at the quantity of work remaining and started brainstorming on how to close this project before the end of September."

Gamasutra has up responses from its frequent feature, the question of the Week. This week's question was a call for the best of the best. "For any genre of your choice, what is the game that defines that genre for you?" From the article: "For the RPG, simply Final Fantasy 6. It has the best story, greatest variety of characters, tons of different music, and added many secret areas. It was the first game to truly to define a real experience of an RPG to the player. -Anonymous" What games would you refer to as Genre Defining?

John Callaham writes "The film industry trade publication Variety announced today that Showtime plans to make a bio-pic movie based on Masters of Doom, the 2003 released non-fiction book on the formation of Doom developer id Software." More coverage available on Gamasutra. Now there is a Doom movie that I'd like to watch.

krf writes "Gamasutra reports that researchers in West Virgina are doing a study on using DDR to fight childhood obesity." From the article: "The study, which is currently budgeted at $60,000, provides each of the selected 85 child participants with a game system, copy of the game, and dance pad."

Gamasutra has word that there are already several Japanese game development studios and designers lining up to create titles for the Xbox 2 system. Yoshiki Okamoto, a former producer at Capcom, is quoted in the article as being surprised at the response the new console is getting. From the article: "I've been hearing that some other designers will also be joining. There are a lot of surprises. I find myself saying: 'What, this development studio!? This game!? These people!?'" Commentary on the upcoming console's Japanese future also available at GamesIndustry.biz. Update: 04/07 03:18 GMT by Z : The translations from the original source came from Gamespot.com.

Nintendo President Iwata has reaffirmed details already released about the upcoming Revolution console. Gamsutra has details from his talk, where Iwata touches on the wireless capability of the Revolution, the designer friendly attitude of the console, and the secretive nature of the console's controllers. From the article: "For the next-generation console, we plan to introduce a friendly user interface so that, for example, a mother who's watching her child playing a game might say, 'Oh, I'd like to try that too.' However, user interfaces are devices that can be easily imitated by other companies, so I can't reveal any details right now." GamesIndustry.biz also has coverage on this topic.

yakitori writes "Today, the law firm of Schatz & Nobel, P.C. filed a class action lawsuit against Electronic Arts on behalf of shareholders. The complaint basically alleges that EA issued false financial projections to shareholders. Shares have dropped from $66 on March 21 to $53 on March 29." Gamasutra has commentary on the suit as well.

Gamasutra's Question of the Week has been asked and answered, and from around the game industry there were brought forth opinions on The Highlights of GDC 2005. Overwhelmingly, people saw the "Burning Down the House" and "Spore" presentations as the most interestng, with a few other folks digging other parts of the conference more. From the article: "I think Nintendo's keynote speech was the most interesting moment for me. Coming a day after Microsoft's keynote, it highlighted the clear divergence between these company's platform strategies moving forward. If you're a gamer at heart (and have the heart of a gamer) root for Nintendo, as they seem to be more interested in gameplay innovation than making an uber-media-micropayment device. (HD-gaming be damned!) - Anonymous" The Puzzle Pirates and Game Atoms talks were probably my most amused moments during the conference. After all, Raph's talk had little monsters and the pirates brought rum.

Gamasutra.com has a look at the reasons, both pro and con, for unionization of the folks behind the entertainment software industry. From the article: "Many industry observers see close parallels between the gripes of today's game developers and those of workers in the movie industry in the 1930s and '40s, particularly in the animation segment. The difference is that Hollywood unionized, and the game industry is still only talking about it."

The ongoing trend of legislating the sale of video games moves forward. Gamasutra has news on the Illinois law currently moving through the legislature, which apparently has "overwhelming support". From the Illinois debate: "An industry that is making so much money selling these things to your children is dealing with things like decapitation, defecation on people. There's vivid pictures of nudity. It's an industry that needs help being policed..."

1up.com has a look at Will Wright's newest game, revealed today at the Game Developer's conference. Entitled Spore, the game promises to be (in a word) unique. From the article: "Wright's latest creation spans the rise of a space-faring civilization from its humble beginnings in the primordial soup. 'It's actually a lot like WarioWare...It features a wide variety of game types as a sort of homage to my favorite games.'" PC Magazine has details as well, as does Gamasutra.

Months after EA: The Human Story was released to the web, Gamasutra.com has word that EA will begin paying out overtime to some of its employees. Which is not to say they don't give it any spin. From the article: "The employment environment at EA was built to allow you flexibility as professionals, with the expectation that time on the job could be managed without watching the clock. Unfortunately, labor laws have not kept pace with this spirit of entrepreneurialism, innovation and creativity." Additionally, taking overtime makes you ineligible for bonuses and this largely has nothing to do with the coders and artists who have filed suit against the company.

Gamasutra's coverage of GDC this year is top notch, and they have several excellent pieces on the Serious Games Summit and GDC Mobile '05. Machine Learning details how game AI developers are turning to real life academic studies on decision making trees to make their work more realistic. A rundown on the Serious Games Summit Panel reveals answers from people who are making games for non-entertainment purposes. Finally, Final Fantasy for Mobile is an analysis of how the Square-Enix folks are planning to take the best-selling franchise to mobile devices. Meanwhile Alice's Wonderland blog continues to be the most immersive coverage here this year, with run-downs on Cory Ondrejka's Building Serious Games with Second Life talk and THQ's Tips from a Mobile Publisher session.

Gamasutra's coverage of GDC this year is top notch, and they have several excellent pieces on the Serious Games Summit and GDC Mobile '05. Machine Learning details how game AI developers are turning to real life academic studies on decision making trees to make their work more realistic. A rundown on the Serious Games Summit Panel reveals answers from people who are making games for non-entertainment purposes. Finally, Final Fantasy for Mobile is an analysis of how the Square-Enix folks are planning to take the best-selling franchise to mobile devices. Meanwhile Alice's Wonderland blog continues to be the most immersive coverage here this year, with run-downs on Cory Ondrejka's Building Serious Games with Second Life talk and THQ's Tips from a Mobile Publisher session.

Gamasutra's coverage of GDC this year is top notch, and they have several excellent pieces on the Serious Games Summit and GDC Mobile '05. Machine Learning details how game AI developers are turning to real life academic studies on decision making trees to make their work more realistic. A rundown on the Serious Games Summit Panel reveals answers from people who are making games for non-entertainment purposes. Finally, Final Fantasy for Mobile is an analysis of how the Square-Enix folks are planning to take the best-selling franchise to mobile devices. Meanwhile Alice's Wonderland blog continues to be the most immersive coverage here this year, with run-downs on Cory Ondrejka's Building Serious Games with Second Life talk and THQ's Tips from a Mobile Publisher session.

simoniker writes "Microsoft has announced XNA Studio at the Game Developers Conference in San Francisco. Based on Visual Studio 2005 Team System, XNA Studio is an integrated, team-based development environment tailored specifically for video game development, and will likely launch as a PC retail product early in 2006. Gamasutra has an interview with XNA's Chris Satchell with more details on what Microsoft sees as a solution for ever-expanding cost and complexity in game development."

Gamasutra.com has the news that UK retailers are beginning to be suspicious of the continued shortages of Xbox console supplies. From the article: "So prolonged, and apparently unexplained, have the problems become that conspiracy theories have begun to circulate regarding ulterior motives for the shortages. Many retailers are now openly speculating whether Microsoft has in fact ceased production of the console, in favour of the next generation machine, or is at least limiting its support to larger retail chains." Maybe you should have hung on to the GameCube, huh guys?

Gamasutra.com has reactions from another provocative question of the week. The topic this time was "Do game creators have any moral responsibilities in teaching values to their audience?" There were many responses on both sides of the issue. From the article: "A resounding NO. Do writers have that same responsibility? Actors? What other limitations would we put on them and our freedom of expression, in order to accomplish that lofty goal? Just ask Jerry Falwell, or the embittered ghost of Senator McCarthy for your answer... NO. Leave the morality lessons to the parents and the priests. They are quite good at their jobs. -Anonymous"

Game technology developers Havok and Epic both plan to introduce the newest iterations of their systems at this year's GDC. Havok will be revealing the newest version of their middleware, while Epic Systems will be showing the Unreal Engine version 3 along with their new scripting tools and AI behaviors. From the article: "...seamless world support allows the creation of virtually unending environments through background management of game levels and assets. Even titles not requiring open world support will benefit from these memory management techniques on next-generation console platforms."

Gamasutra.com (news now registration free) has word that MMOG developer Webzen has received a friendly letter from Nintendo discussing the similarities screenshots of their upcoming game have with The Legend of Zelda: Wind Waker. The developer states that this is a coincidence resulting from the cell shades style of their game, and the particular hair and clothes show in published media. From the article: "a spokesperson from developer Webzen claims that the hero of the game does not have any fixed image, and is created by the player to be their avatar in the game world." Heads up courtesy your friendly neighborhood simoniker.

Gamasutra.com has the first in a new series of opinion gathering articles, where individuals can pipe up with their responses to a question of the week. The first query was "What was the most creative game of 2004?" From the article: "Katamari Damacy, hands down. Unique concept. Unique gameplay. Solid execution. And most important of all, it was _fun_."

An anonymous reader writes "Gamasutra is running a post-mortem on an interactive love story that was written by students. They were attempting a solution to the game designer's challenge from the GDC 2004. From the article: Interaction with video games is currently done at an almost entirely rational level. The player may react to a game emotionally, but the game will never know about it, and thus, never respond to it. We wanted to change this, and have the player interact with the game solely through his own emotions."

Gamasutra.com is running an article entitled Shaping Ty the Tasmanian Tiger 2 for the Younger Market. Beyond the interesting dilmmas associated with designing for a younger audience, the article is a good examiniation of following up on a successful franchise without alienating your fanbase. From the article: "Aiming towards a young market with family friendly content doesn't mean you have to make a game without all the exciting features adult gamers come to expect in a premium title. This time around, we were determined to include some of the ideas that didn't make it into the first game (like more giant robots and vehicle based missions), and concentrate more on the "action" elements of platformer games. "

Gamasutra.com is running an article entitled Back to the Classics (no reg. required), discussing the perfection of the emulation used in the recent Atari Anthology. From the article: "In a port, it's easiest to consider a game written in a high-level language like C (though that wasn't at all common in the first half of the '80s or earlier). As the person porting the game, you'd separate the program into two parts. There's the C code that represents the game logic itself, which you try to leave intact, and there's the platform-specific code (for example, a video driver might be considered part of the platform-specific code). Early computers, arcade games and home consoles had video chipsets that bore no resemblance at all to what we have now. So, you'd have to rip out that code and replace it with something that hopefully works the same way on the new platform."

Gamasutra has the news that electronics giant Sony has had their credit rating downgraded from A+ to A by credit ratings firm Standard and Poor's. The move is seen primarily as a result of the PSP's impending launch. From the article: "Although Sony's PlayStation Portable (PSP) was not mentioned by name, many consider the unexpectedly low Japanese launch price of the console, 19,800 yen (USD$186), to be one of the major causes for concern. With some suggesting that Sony will lose significant amounts of money on every PSP sold, the company will be looking at a loss of tens of millions of dollars in the first year of the format."

Gamasutra (registration required) has begun running an excellent column called "Soapbox". The first article up on the site is penned by Richard Bartle, one of the gents who created MUD1. Why Virtual Worlds are Designed by Newbies [non-reg alternate] is a great look at the lessons of past games and the foibles of designing a new one. From the article: "Virtual worlds are being designed by know-nothing newbies, and there's not a damned thing anyone can do about it. I don't mean newbie designers, I mean newbie players - first timers. They're dictating design through a twisted "survival of the not-quite-fittest" form of natural selection that will lead to a long-term decay in quality, guaranteed."

Gamasutra (registration required) has begun running an excellent column called "Soapbox". The first article up on the site is penned by Richard Bartle, one of the gents who created MUD1. Why Virtual Worlds are Designed by Newbies [non-reg alternate] is a great look at the lessons of past games and the foibles of designing a new one. From the article: "Virtual worlds are being designed by know-nothing newbies, and there's not a damned thing anyone can do about it. I don't mean newbie designers, I mean newbie players - first timers. They're dictating design through a twisted "survival of the not-quite-fittest" form of natural selection that will lead to a long-term decay in quality, guaranteed."

Thanks to Gamasutra for the heads up about a political music video starring video game characters that is to start airing on MTV today. The newest "Choose or Lose" video will feature characters from popular video games such as The Sims and BloodRayne and is intended to encourage youth voters to show up at the polls. The video will air for the first time on MTV today on TRL, and afterwards can be seen on the MTV Choose or Lose site. This follows closely on the heels of MTV2's Video Mods series, which uses video game footage for the visuals in music videos.

Thanks to the numerous readers who alerted us to the Gamespot article mentioning that the PSP may be delayed until next year. This analysis comes from games industry analysts and is the result of Sony's game title weakness and battery issues. David Jenkins at Gamasutra has additional analysis as well.

Thanks to Slamdance for its submission. Coming up at The Slamdance Film festival in Park City, Utah - Jan. 21 to 28 2005, programmers can compete in The Big C Independent Game Competition. "The Big C is calling for entries of all new games from emerging talent. Selected games will compete and be judged by festival attendees, with a Jury Award and Audience Award that include cash and prizes presented at the end of the festival. Game submissions should have an early-postmarked deadline of Oct. 1, 2004 and a final postmarked deadline of Nov. 14, 2004. Entrants may submit games on disk or provide a URL for judges to download." The event has an entry on the Gamasutra Calendar, for additional info.

Martin Ecker writes "With the advent of powerful, programmable GPUs in consumer graphics hardware, an increasing number of shading languages to program these GPUs has become available. One quite interesting language that - in many ways - has a very different approach than other mainstream shading languages (such as Cg or the OpenGL Shading Language) is Sh. The recently released book "Metaprogramming GPUs with Sh" by Michael McCool and Stefanus Du Toit, both major contributors to the Sh project, explains the basics of the Sh high-level shading language and the corresponding API and also goes into some of the details of the implementation. The book is intended for an audience that is already familiar with traditional shader development for programmable GPUs. Also, a firm background in 3D graphics programming and C++ is a must for the interested reader." Read on for the rest. Metaprogramming GPUs with Sh author Michael McCool, Stefanus Du Toit pages 308 publisher A K Peters rating 7/10 reviewer Martin Ecker ISBN 0321197895 summary A book that describes an interesting shading language and accompanying API to program GPUs.

Before discussing the book in more detail, I will try to give a basic overview of Sh, since most readers will not be familiar with it. For a more in-depth look at Sh, I recommend taking a look at a recently posted Gamasutra article by Michael McCool (http://www.gamasutra.com/features/20040716/mccool _01.shtml), the paper on Sh from the authors presented at the recently held SIGGRAPH 2004 conference (http://www.cgl.uwaterloo.ca/Projects/rendering/Pa pers/#algebra), and of course the Sh homepage at http://www.libsh.org.

Sh started out as a research project at the University of Waterloo (http://www.cgl.uwaterloo.ca), and it is both a shading language and a runtime API to use the Sh shaders. As a shading language Sh is embedded into C++ as a domain-specific language, which is made possible by using C++ operator overloading and by defining special tuple and matrix types that are used extensively in shader code. So instead of defining its own language that requires a full compiler, like other shading languages do, Sh uses regular C++ syntax to describe shader code, which is then dynamically (at runtime) compiled to a specific backend, such as a GPU or possibly even the CPU. In addition to compiling to a specific GPU or CPU target, Sh can also be used in a special stream mode where a shader is applied to a stream of input tuples. This is very useful for general purpose GPU programming where the GPU is basically used as an additional processor to the host CPU (see http://www.gpgpu.org for more information on the subject). Finally, Sh code can also be executed in an immediate mode where every Sh statement is directly executed on the host CPU (without being compiled into a shader program), which makes it very easy to debug shaders with any host debugger running on the CPU.

Due to the way Sh is embedded into C++, the full range of abstraction mechanisms offered by C++ can be used to structure and modularize shader code. Abstract base classes, regular functions, templates, and any other features offered by C++ can be used to develop shaders. This is an interesting consequence of the metaprogramming approach of Sh that also allows the use of software engineering principles in shader development, such as object orientation, that other shading languages currently cannot offer.
This kind of metaprogramming in C++ is used by an increasing number of libraries. For example, the Spirit parser framework (see http://spirit.sourceforge.net) uses a similar approach to describe and generate parsers directly in C++ instead of using traditional external tools, such as yacc or bison.

One of the most fascinating features of the Sh toolkit is the possibility to combine and connect shader programs to form new shader programs, which allows one to easily build complex shaders out of simple shader fragments. In a more general sense, Sh provides what can be called a shader algebra (see also the aforementioned SIGGRAPH 2004 paper), where shader programs are the objects on which special operators to combine and connect them are defined. An interesting application of this shader algebra is to specifically bind certain varying shader inputs to uniform variables and the other way around (this is what functional programming languages usually call currying). Also combining a matrix palette skinning shader with any light model shader (or any shaders that perform specific tasks, for that matter) is easily possible.

After this short introduction to the Sh toolkit, we shall now take a closer look at the book "Metaprogramming GPUs with Sh".
The book is split into three parts, an introduction, a reference, and an engineering overview.

The introduction consists of the first five chapters and discusses the basics of the Sh shading language and the API. In particular, the tuple and matrix types and the operators defined on them are presented. The way shader programs are defined and how parameters and attributes are handled is discussed, followed by the way textures are represented. Finally, the stream and channel concept used to feed data into shader programs is discussed. These introductory chapters contain a number of examples that demonstrate the presented concepts. Chapter three contains a quite interesting sample shader that uses constructive solid geometry techniques and metaprogramming in Sh to render text. While not the most useful use case, the shader shows some interesting capabilities of Sh, in particular the shader algebra operators. Chapter four on textures has some more nice sample shaders for doing shiny bump mapping, rendering wood and marble, and using Worley noise.

The second part of the book is a reference on Sh. Unlike references in many other computer books, this is not just a technical listing of the available features of Sh but is written in regular prose (with the occasional reference-like table here and there). The six chapters of the reference section describe how to setup and use the Sh library, and then discuss the available types, operators, and standard library functions more thoroughly than in the introduction. Additionally, the available backends are mentioned in the last chapter of this part of the book. A draft of the reference manual can also be found online at http://www.libsh.org/ref/online.

The final part of the book deals with engineering aspects of Sh. These final five chapters of the book discuss the details of the current implementation. The intermediate representation for shaders that is used by Sh is presented as well as how streams and textures are managed and stored internally. The interface between the Sh frontend and the various specific backends is discussed, as well as the current state of the optimizer including some further improvements that are planned in the future.

The images in the book are all in black and white except for 14 color plates in the middle of the book. The color plates and other images usually show teapots or animals, so they aren't all that exciting, but do demonstrate what the sample shaders presented in the book look like.

The book does not come with a CD-ROM, but with such a young library that is still under heavy development, putting a snapshot of the library's source code base on a CD-ROM would be a waste of resources. Sh itself as well as all sample shaders presented in the book can be downloaded from the Sh homepage at http://www.libsh.org. This website also has additional documentation, including some papers and the API reference documentation generated with Doxygen from the sources. Sh is distributed under a very liberal open source license (based on the zlib/libpng license) that also allows commercial use.

For the reader with enough expertise in 3D and shader programming, this book provides a concise and well-written introduction to Sh. The book will definitely contribute to enlarging the currently relative small user base of Sh and hopefully help the library grow and get more refined in the near future. Everyone familiar with "regular" high-level shading languages, such as Cg or the OpenGL Shading Language, should take a look at this book to see a new and interesting way of programming GPUs that the aforementioned languages do not offer.

About the review author:
The author has been involved in real-time graphics programming for more than 9 years and works as a games developer for arcade games. In his rare spare time he works on a graphics-related open source project called XEngine http://xengine.sourceforge.net.

You can purchase Metaprogramming GPUs with Sh from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Thanks to DIY Games for its column discussing the state of freely downloadable independent PC adventure games for July. The author raves: "I don't think I'm exaggerating if I say that July was by far the best month for independent adventure gaming this year", and goes on to profile titles such as A Very Special Dog ("You play a German shepherd with the task to save a life and find the culprit... you'll sniff objects, bark at people or lick them, all in order to successfully complete the game") and Apprentice II: The Knight's Move ("top quality independent gaming... [with] a very deep story and great character development.") Talking of character development, I'm afraid this is my (simoniker's) last ever Slashdot story post. Read on for details... Firstly, thanks to everyone who's helped make Slashdot Games (as well as my work on the Slashdot main page) a pleasure to edit over the past 18 months (and 3000+ posts) or so. It's been a wonderful experience, and I'm really going to miss it. Unfortunately, this is the final story I'll be posting, since I'm off to videogame trade site Gamasutra.com, which I've written for fairly extensively in the past, to take up a managing editor position.

I believe there will be an announcement about a new Slashdot Games editor reasonably soon. However, I'm sure the other editors will pick up some of the slack in the interim, so hang in there, everyone. In the meantime, please inundate the submission bin with stories about obscure Japanese console re-issues, why the Infinium Phantom is going to trounce the Megaton, and why the Reggielution is absolutely, positively going to be televised. Later, all.

Thanks to DIY Games for its column discussing the state of freely downloadable independent PC adventure games for July. The author raves: "I don't think I'm exaggerating if I say that July was by far the best month for independent adventure gaming this year", and goes on to profile titles such as A Very Special Dog ("You play a German shepherd with the task to save a life and find the culprit... you'll sniff objects, bark at people or lick them, all in order to successfully complete the game") and Apprentice II: The Knight's Move ("top quality independent gaming... [with] a very deep story and great character development.") Talking of character development, I'm afraid this is my (simoniker's) last ever Slashdot story post. Read on for details... Firstly, thanks to everyone who's helped make Slashdot Games (as well as my work on the Slashdot main page) a pleasure to edit over the past 18 months (and 3000+ posts) or so. It's been a wonderful experience, and I'm really going to miss it. Unfortunately, this is the final story I'll be posting, since I'm off to videogame trade site Gamasutra.com, which I've written for fairly extensively in the past, to take up a managing editor position.

I believe there will be an announcement about a new Slashdot Games editor reasonably soon. However, I'm sure the other editors will pick up some of the slack in the interim, so hang in there, everyone. In the meantime, please inundate the submission bin with stories about obscure Japanese console re-issues, why the Infinium Phantom is going to trounce the Megaton, and why the Reggielution is absolutely, positively going to be televised. Later, all.

scishop writes "While most of the gaming world has been focused on the dazzling smoke and mirrors special effects of E3, Gamasutra has published an interesting article on a different game convention: Indie Game Jam '04 where two dozen game developers spent four days creating a variety of games built around the same engine in an effort to encourage innovation. The results included apps centered around boxing, yoga and flaming hamsters." Our earlier story over at Slashdot Games has more links and information.

Thanks to Globe News for their interview discussing game design pitfalls with Ernest Adams, columnist at industry site Gamasutra, in relation to a recent Toronto game design lecture. Adams' talk, called 'Bad Game Designer, No Twinkie', has the premise that "whenever game designers add an annoying, sloppy, illogical or cliché game design element, they are denied the junkfood they love so much", and in the interview, Adams also laments the inherent difficulties in making games: "If you imagine what it would be like if you had to invent a new projector for every movie, that's what it is for game development", as well as gaming award shows, which he says "...tend to confuse the difference between technological achievement and aesthetic achievement."

Thanks to Gamasutra.com for their news report (registration required) indicating that Graeme Devine has left id Software for Microsoft-owned Ensemble, the developers of the Age Of Empires series. The article elaborates: "Devine's career covers a substantial swath of videogame history, starting with porting games such as Pole Position for Atari while still in high school in the U.K. in the early 1980s. He later co-founded Trilobyte, where he was central to the development of the seminal CD-ROM title The 7th Guest and its follow-up, The 11th Hour. Most recently Devine was working on Doom 3 for id, in roles ranging from project manager to designer to programmer." Further details are as yet unavailable, but the piece suggests "..in his new role at Ensemble, Devine will be focusing primarily on game design."

rjnagle writes "When Marc Prensky asked a colleague who had just returned from a training course how it was, she replied, 'AFTRB.' (Another #$#$^&# Three Ring Binder) . In his book, Digital Game-Based Learning , Prensky, an instructional game designer and founder of games2train, argues that computer games are more effective learning tools because they sustain interest and attention in settings where people are normally bored." To follow that train of thought (or if you just liked Ender's Game), read on below for Nagle's lengthy review of the book. Digital Game Based Learning author Marc Prensky pages 442 publisher McGraw-Hill Trade rating 5/5 reviewer Robert Nagle (aka Idiotprogrammer) ISBN 0071363440 summary Visionary book on instructional design and game design.

Digital Game-Based Learning (DGBL) consists of two parts. In the first part, Prensky argues that the prevalence of video games has actually rewired our brains and made traditional learning methods less effective. In the second part, Prensky makes the case that DGBL can be used successfully by corporations to train people and offers practical advice (based on vast experience) about how to deploy game-based training methods. Throughout the book, Prensky examines aesthetic, cognitive and pedagogical questions surrounding such games and provides dozens of case studies to illustrate his points.

Prensky argues that current learning methods for young learners fail to engage learners used to interactive media. Learners now expect interactivity. Prensky writes:

Games Generation workers rarely even think of reading a manual. They'll just play with the software, hitting every key if necessary, until they figure it out. If they can't, they assume the problem is with the software, not with them--software is supposed to teach you how to use it. This attitude is almost certainly a direct result of growing up with Sega, Sony, Nintendo, and other video games where each level and monster had to be figured out by trial and error, and each trial click could lead to a hidden surprise. Games are almost all designed to teach as you go.

Prensky believes that the instructor-led classroom and the teach-test method are actually historical artifacts no more than 200 or 300 years old. The teach-test instructor-led class and its instructional methods arose partially from the rise of the printing press and the widespread availability of reading material.

Why then does the teach-test method still prevail? One reason may be the generation gap and technology gap between learners and teachers. Even technologically savvy educators have biases towards methods that worked while they were learners themselves. The way we learn is to some extent a byproduct of the cultural and technological milieu we mature in. Twenty years ago educators were extolling the virtues of reading books while youngsters (including me) were "wasting" their time before the boob tube. Nowadays, undoubtedly, there is a tension between educators pushing "media literacy" (media, in this case, often equaling conventional TV broadcasting) and students too busy making additions to their online Sims house or watching webcams of friends to care. No matter how much you may try to keep up, I once told a group of middle-aged Ukrainian teachers, your students will always be more hip to the technology than you.

This is not merely a matter of age but of comfort level. Growing up with a technology (especially at an early ago) makes using it second nature. According to the neurology and psychology research that Prensky cites, the brain reorganizes and rewires itself in response to cultural stimuli, so a child who plays videogames at night is bored at class not because of "short attention span" or bad study habits but because the child's brain has programmed itself to respond better to "twitchspeed" interactivity. Prensky cites John Bruer's statement that achieving this kind of brain reorganization requires students to spend "100 minutes a day, 5 days a week, for 5 to 10 weeks to create desired changes because "it takes sharply focused attention to rewire a brain." Then Prensky adds, "Several hours a day, five days a week, sharply focused attention--does that remind you of anything? Oh yes -video games!" (p 43) . Interestingly, Prensky cites research about how children with attention deficit disorder are using video games to retrain their brain and help them to concentrate. For the game-playing child, going to school means having to "power down" and endure teaching methods ill-suited to him. (p44).

After Sesame Street showed that you could educate children by entertaining them (and sustaining their interest), games (and sometimes even instructional technology) have focused on how to sustain this interest. In an age where pop-ups, 15-second promos and CNN updates are everywhere, it is no wonder that "gaining attention share" is the central concern. Children have learned the art of selectively being able to tune out media. How then to keep their attention? Interestingly, this concern parallels that of game developers looking for better ways to sustain gameplay.

A child once described playing educational games as "hard fun." When people are "playing," they forget inhibitions and self-consciousness to concentrate on the game's mission (i.e, "learning objectives"). When I taught English to college students overseas, I was surprised to find that one of my weakest and least confident student interacted adeptly to an immersive role-playing game with a strong English language component. From my viewpoint, she was quickly comprehending spoken dialogue and responding appropriately. From her viewpoint, she had just crossed the bridge and now could start digging for gold. Cognitive breakthroughs often require distracting activity to allow the mind to refocus (visionary Alan Kay wrote, "people have more brainstorms on the jogging path than at their desks."). Educators typically view educational gaming as useful mainly for drill and practice, but as gaming environments become more complex, edugames may be more useful in providing roundabout paths towards concepts hard to reach by traditional methods. To use just one example, computer aids allow students to manipulate data and geometric figures as a way to experiment with mathematical principles. Indeed, one of Prensky's most successful game projects, the Monkey Wrench Conspiracy, taught young learners/players how to do 3D computer design by setting them in a spaceship with a mission to make repairs before the spaceship blows up.

The most fascinating section for me was Prensky's juxtaposition of game design principles alongside instructional design principles. Even if one doesn't accept Prensky's historical analysis (and thoughtful detractors like Kurt Squier have pointed out shortcomings) or his argument that games should be more widely used for training, Prensky's theoretical overview of game design should interest people in both the education and game camps. Both game designers and instructional designers are obsessed with epistemology: how to reveal information to the player/learner in a way that sustains interest; how to use conflict to change the player/learner's behavior or attitudes; how to provide enough feedback for the player/learner to change behavior; how to present a simplified view of the world without distorting it; and how to permit freedom of exploration within the constraints of an object-oriented world or of a lesson plan. These are concerns, by the way, that also interest writers of plays and fiction, except that the "player" is split into two roles: that of character (who is controlled by the playwright/writer controls) and audience (who can emphasize and anticipate, but can't change outcomes).

Prensky's grid that maps learning content to game styles (p156) indicates that sufficient varieties of games exist to tackle any training challenge. Electronic Jeopardy style games can drill employees about company policies (and these templates are commercially available and widely used). Realistic simulation games, although probably more costly to produce, may actually reduce training costs whenever the actual equipment or training environment is expensive to begin with. Better that the potential pilot crash-land a few Flight Simulator planes, or that the combat soldier accidentally kill a few civilians within a simulation environment than for real. Prensky offers good questions for evaluating the educational value of computer games: do people using it think of themselves as players rather than students? Is the experience addictive? Does it encourage reflection? Would the game be considered "fun" by someone outside the target audience? Despite the similarities, there are important differences, Prensky would argue, between games that entertain and those that educate. For one thing, successful games require visual external action to sustain attention. But this is not needed for certain domains of learning. Games may be good for learning the process of putting together a Burger King hamburger (p264), but would a game be practical for learning Java programming? Or Freud's theory of the unconscious? It's probably not impossible to design such a game; both Java and psychoanalysis involve understanding low-level mechanisms of causation, recognizing aberrant patterns and being able to select the correct algorithm from the available repertory of solutions. Role-playing and collaborative simulations would help. But what the learner needs most is FEEDBACK, game or no game. The assumption behind Prensky's advocacy of game-based learning is that content needs "livening up" or that external motivators (like video games) are needed to drive the students toward learning. I am not questioning the value of these "external motivators." But I have to wonder whether Prensky's pedagogical approach implies that certain kinds of learning activities cannot be self-motivating. Sure, a game about Java programming might amuse the CS student, but the more crucial question (I would argue) is whether this student finds the very activity of programming in java to be "hard fun."

To Prensky's credit, he does not insist that game-based learning is the best strategy for every learning situation. Perhaps the most compelling part of the book is a discussion of more than 40 case studies where computer games have been cost-effective at training. They range from an animated courtroom game (Objection) to a customer service game (where in the world is Carmen Sandiego's Luggage?) to a Sexual Harassment gameshow and many fine examples from Prensky's own company (which can be sampled online for free). He offers helpful advice (undoubtedly gained from experience) about how trainers can launch and even manage such a project. Among his suggestions: befriend IT as soon as possible; choose urgent learning needs that are "boring, complex or difficult," and offer game-based learning in conjunction with more traditional methods and give learners the option NOT to learn via the game method. Prensky offers practical suggestions to companies with training budgets ranging from the hundreds of thousands of dollars to nothing. Although the book is two years old, it still gives a good sense of what your money can get you these days.

Critics usually argue that "e-learning" doesn't compare favorably to live teachers. That is missing the point; the real question is whether e-learning (and game-based learning) provides comparable learning at a lower cost. As e-learning and game-based learning becomes more cost-effective, Prensky predicts a fairly radical transformation of the teacher/trainer's role. To some extent, this has already occurred with the advent of collaborative and student-based learning. But trainers may spend more time choosing the best learning tool for students (or creating new ones!) than actually teaching in a classroom. Is this bad? Prensky mentions that "any teacher who can be replaced by a computer, should be." In this world of game-based learning, Prensky argues, teachers can play a vital role in ensuring that students adequately reflect on the problems or conflicts that arose during the game/learning activity. Games are good at interactivity but bad at reflection. They offer ample opportunities for learning by doing, Prensky says, but minimal opportunities for reflection. One student, asked what he learned from playing SimCity, said, "I learned that if I don't feed the people, they will starve and die." That is clearly insufficient. A good instructor can help the student explore issues more deeply: how do politicians decide about allocating resources? Does the feedback offered to politicians give an accurate reflection of society's needs and problems? What strategies worked or did not work within the context of the game? Would these strategies also work in real life? Reflection is not necessary for every learning context, but today's trainers can make sure students have enough reflection to reap the benefits of game-based learning.

Prensky's book is an excellent introduction to this exciting field. He writes superbly and has a good grasp on learning theory and software design. Although clearly an enthusiast, he never implies that DGBL is the only or best teaching method. Many of Prensky's successes involve computer games as a primary component, but computer games don't need to play a central part in a lesson to be useful for learners. For example, a student can attend a traditional foreign language class and practice at home using a computer game. Ultimately computer games may have more value as supplemental material than as primary material.

Prensky's critique of the traditional trainer is sometimes unfair, especially the "generation gap" thing. Technology is not essential for reaching younger learners (and some experts have decried its overuse). Resourcefulness, a well-designed curriculum and motivational ability trumps game-based learning every time (even Prensky would agree with that, I think).

If we accept Prensky's premise that instructional methods are somehow determined by the prevailing state of technology, one starts down the path of saying that instructional methods are subject to obsolescence. New teaching methods may be more cost-effective or more motivating, but they don't necessary repudiate the value of "old-fashioned" methods (indeed, there will come a time when DGBL will be regarded as old-fashioned, so Prensky better watch out what he says). Using teaching methods so dependent on a technology, I would argue, has the unfortunate effect of rendering teachers helpless in the wake of massive technological breakdown. If a trainer/facilitator skilled in DGBL suddenly found his classroom without Internet access, could he still train employees effectively? One of my most edifying experiences as a teacher came at a Albanian university in Vlore lacking not only computers, but also copy machines and yes, sometimes even electricity. Every day I walked to class, mentally having to plan for contingencies (no electricity, inability to obtain photocopies from a nearby shop) for the day's lessons. While I still managed to pull off some funky lessons (with battery-powered cassette players, magic markers, magazine pictures and large posterboards), I couldn't help wondering if my "innovative teaching methods" merely burdened me with more things that could go wrong. The flip side of Prensky's magnificent vision is the nightmare scenario of teachers so overwhelmed with newfangled technological aids that they opt for the tried-and-true (but technologically primitive) methods rather than risk losing a class to downtime.

Although the spectacular successes mentioned in the book were informative, it also might have been helpful to examine cases where DGBL have failed or turned out to be not particularly remarkable. Every so often, a new theory or learning method hits the world, and suddenly educators use this method whether it is appropriate or not. When is DGBL not appropriate?

When making the business case for DGBL, Prensky overlooked two important things. First, the obsolescence of technology and technological standards (and the perception of obsolescence) diminishes the value of custom-built games for corporations. This seems to be an argument for using cheaper mass-market games rather than convincing the CEO to fund an ambitious game project. Also, I'm surprised that the book didn't spend more time on one obvious advantage to DGBL: digital assessments. Computer games make it easier to verify that learners performed required tasks and to keep the performance data in digital form to demonstrate compliance. That would be a big selling point for human resources.

I've written elsewhere that as immersive games become more sophisticated and develop their own society and values, real life will start to resemble a video game and videogame prowess may become an end worth pursuing for its own sake. Now that weapons and radar systems look more like computer games, for example, military recruiters might be happy with legions of game addicts manning their battalions. As it becomes easier to gain knowledge and experience completely from computer games, the notion of having to learn things from real life will start to seem very strange.

Other Resources

Marc Prensky has put generous excerpts from the book online for free. His company website contain a lot of fun free/demo games, including (my favorite) "The Challenge." Expect it to be slashdotted for a while. You can also buy the book here.

Kurt Squire of MIT's Games-to-Teach project , has written a preceptive article, Reframing the Cultural Space of Computer and Video Games and many other things on game-based learning , including an excellent critique of Prensky's book.

Dr. Sivasailam "Thiagi" Thiagarajan writes frequently on using games for training. His Thiagi website contains lots of freebies as well as a free monthly newsletter with lots of game/training ideas.

Gamasutra has a separate section on writings about educational games. Free registration is required.

Although not explicitly about game-based learning, Steven Poole's book, Trigger Happy offers a sophisticated aesthetic analysis of videogame narratives and engagement.

Robert Nagle (aka Idiotprogrammer) is a linux nut, technical writer and trainer with a background in instructional design and game design. He works for Texas Instruments in Houston. You can purchase Digital Game Based Learning from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Long-suffering Slashdot reader WrinkledShirt contributes this review of John Hall's Programming Linux Games, and lays out the good and the bad in a book that's one of the few of its kind. More games are always good -- hopefully books like this one will spark some inspiration.

Programming Linux Games author John Hall pages 415 publisher No Starch Press rating 7.5 reviewer WrinkledShirt ISBN 1-886411-49-2 summary Well-written guide to a wide range of game-writing tools for Linux, but not a definitive reference work for any single task.

Introduction

The potential for linux gaming has really exploded in the last couple of years. In many cases, the potential has been realized -- Unreal Tournament, SimCity 3000, Tribes 2, Quake 3, Alpha Centauri, and many other successful Windows titles, have all been brought to Linux, with Loki leading the charge. Judging by the bottom line, there's a definite shortage of true cash-cow success stories in this enigmatic part of the industry, and hence, a shortage of good reference material for naive people hoping to produce that next cash cow.

However, we've reached such a point of critical mass of knowledge and technology that books had to start appearing sometime. So, despite the fact that there's no overwhelming market demand for Linux games and a high ratio of hobbyists to dedicated game developers for the OS, here we have a book aiming at taking amateur Linux game development to the next level.

However, much of the technology out there for game programming in Linux is still heavily in development, with many of the APIs and libraries still a long way away from a 1.0 release. Allegro and Clanlib are a couple of exceptions to this trend -- both are popular APIs that sadly don't get much more than a passing mention in the book. Their sexier counterpart, Sam Lantinga's SDL, gets a fair amount of treatment (no surprise there, considering John Hall was the lead author for a team based within Loki) -- but even this fairly feature-complete library, which Loki uses to port its games over from Windows, isn't explored in its entirety.

Instead, there are also crash courses in BSD sockets, package management, TCL, the framebuffer and various sound APIs, and what we end up with here is the consummate cookbook, a jack-of-all-trades-and-master-of-none tome that introduces us to a wide variety of Linux gaming topics while stopping short of being a definitive reference for any of them. Such is John Hall's work, an interesting, wide-ranging introduction to game programming for an operating system that few believed was capable of it not too long ago.

John Hall, an experienced game developer, participated in Loki's Civilization, Call to Power game hack, and is currently working for Treyarch developing that company's Spider-Man title for the PS2.

The Good

As far as cookbooks go, this is a good one, and there isn't much concerning Linux game API programming that isn't touched on. There's an ongoing case study (Penguin Warrior) that is developed over the course of the book. Each chapter introduces a fairly deep concept, gives a decent function reference related to the concept, then incorporates the knowledge into proof-of-concept code, and then uses the new-found knowledge to enrich the case study. The tone is straightforward and the execution is solid. The final game works well enough to give confidence that the reader could take the knowledge in this book and apply it to his or her own project, either to add new features or re-think old ones.

The book is also well-written -- the sample code is extremely well-commented and good error-handling is in place. He makes no assumptions about the knowledge of the reader, dealing with such introductory topics in Linux programming as vi vs Emacs, the FSH and make, although he never gets annoying or patronizing. *cough cough* LaMothe *cough*

Individual chapters stand out as being great introductory resources for material that doesn't have much in the way of documentation. The important aspects of SDL get good treatment in one complete and comprehensive unit. There's also a thorough chapter on audio programming, comparing and contrasting OpenAL, OSS, ALSA, Ogg Vorbis, and ESD (among others), and all this after showing off SDL's sound capabilities one chapter earlier. Many of the pitfalls associated with each of the different technologies, as well as the pitfalls of sound programming in general, are covered here. It's a great jumping-off point for those who don't know much about the audio end of things.

There's even a really neat chapter on incorporating TCL script interpretation within a program written in C. For anyone who's had trouble throwing together their own text parser for initialization scripts, or who's fed up with the constant recompiles needed when tweaking for the most arbitrary of changes of the game's AI, the information in this chapter is a godsend. In the Penguin Warrior case study, it's almost spooky how effective TCL turns out to be in making the computer ship chase and evade the human player.

Finally, I want to reiterate the effective use of the case study, Penguin Warrior. Having seen the way other game programming texts handle using samples to illustrate game programming concepts -- which is often a mish-mash, to say the least -- the way this book approached the issue is refreshing: there's one major project, and each chapter brings us closer to that project's completion. The code works as intended and goes a long way to convince the reader that the libraries and techniques explored in this book are near-commercial-level quality. (Networked games turned out to be choppy on my machine, but that was the only real black mark I could find in the program's execution.) If nothing else, John Hall deserves a good deal of thanks for proving that game development on Linux is a realistic and rewarding endeavor.

The Not So Good

At times, the generalist nature of the book left me wondering if Hall couldn't have gone just a little bit further in some of the topics. There's a decent enough synopsis about deployment using Loki's install tool, as well as packaging in general, although nothing related to the Penguin Warrior game itself, so we don't get to see the theory in practice as much as it could have been. Also, he teases us by early on by starting with the compiler, moving to the make utility, talking a bit about package management, and then mentions automake, but he stops short of really explaining how to bring that into an existing project. Considering all the fun little dependencies needed for multimedia programming in Linux, this would have been a valuable bit of information for anyone not used to deploying on the platform.

Another instance of this so-close-yet-so-far approach occurs when he talks about incorporating Mesa into an SDL program. He tantalizes us with a code sample illustrating how to use the SDL as a replacement for glut, but that's all -- the material doesn't really get deep enough to convince readers that a 3D neophyte really can abandon glut for the SDL, particularly when many OpenGL reference materials out there rely heavily on glut as a teaching aid for windowing and other utility functions. Loki primarily used SDL to handle its 3D utility programming, so at least we know it's possible, but given the exploding popularity of 3D games it's too bad this wasn't covered more.

It's sometimes hard to tell exactly who the book is intended for. The introductory chapters include discussions on topics such as the different gaming genres out there, despite the fact that game programming hopefuls who don't know that Quake is a first-person shooter must make up a really narrow audience. Also, it's almost enough to give one whiplash to see how quickly he dives into using ioctl() when only a couple of chapters earlier he was explaining the basics of using gcc. Next up soon after that? Strap yourself in, we'll be writing straight to /dev/fb0! It's almost comical to think about how much dangerous knowledge a newbie's been given over the course of the book. Still, like I said earlier, he never talks down to the reader, who because of this might feel compelled against better judgement to be whisked along into subject matter that really needs other support material to be of any real use.

Hall's a humble enough guy, which is great insofar as writing style is concerned, but in one of the last chapters, he starts questioning some of the choices he made while coding Penguin Warrior throughout the book. Specifically, he says he probably should have used C++ instead of C, Scheme instead of TCL, and UDP instead of TCP for the networking, and this is cold comfort for people who would have hoped that the author would have picked the best plan of attack from the beginning. That said, C, TCL, and TCP are appropriate choices due to the simplicity of execution and the fact that they introduce useful techniques from a design point of view. Still, there's no point giving readers a sense of wistful "What if?" if you don't have to. It also highlights that this book is more a beginner's API reference than a game programming book per se.

To take that point further, there also really isn't much in the way of abstract game programming theory. This book could have really distinguished itself as special if some content related strictly to game development was here. There's a mention of Gamasutra here, a method of quick division there, the equation of a distance from a point to a line thrown into the mix, and that's pretty much all there is. Topics not really covered include optimization, pathfinding, and cracker-proofing your code, and what is talked about on the subjects of artificial intelligence design, collision detection, and physics is all rudimentary ... For coverage on these sorts of topics, you'll have to look elsewhere.

Finally, and this is really not the fault of the author or the book, but one wonders if the time was right for much of this material -- or, at the very least, its highly generalist approach. DRI is making its presence felt, the various audio APIs out there are improving all the time, and the LSB is coming along nicely, but until there's a proven and stable multimedia base to work from, no definitive guide can be written, and this sort of organized dogpile is really the best we can hope for with so much stuff to cover. The SDL is a top-notch library for graphics programming, and it's likely an entire book could have been spent strictly on graphics programming using it, and the depth that such a book could have attained far surpasses what we're given here. Plus, in a year from now, who knows where any of these sound APIs will be? Of course, these might prove to be just esoteric issues in the grand scheme of this book.

Conclusion

Despite the criticisms I have of this book, I really don't want the message that is conveyed here to be anything but positive. There's a lot working for this book -- the chapters on SDL, sound programming and incorporating TCL and C are excellent, and will be especially helpful for people who are novices in these areas. Considering the alternatives (hitting dryly-written online docs or constantly shaking your Google to see what falls out), this book is a very attractive option. Programming a fully-functional multiplayer game would probably require more effort than might be suggested by the brevity of the chapter on socket programming, but that chapter is a solid introduction as well. The book as a whole is well-written and succeeds for the most part in its endeavor to make the best of a chaotic situation. I'd recommend this book to anybody who appreciates the messy-kitchen style of learning, or to anyone with decent hacking skills who just needs to break the ice when it comes to the Linux game APIs. And even though it gets slightly schizophrenic in its attempt to be both an introductory text and a definitive reference, this is the sort of book that could kickstart a new movement in Linux game development.

Table of Contents (exploded version here)

1. The Anatomy of a Game
2. Linux Development Tools
3. Linux Gaming APIs
4. Mastering SDL
5. Linux Audio Programming
6. Game Scripting Under Linux
7. Networked Gaming with Linux
8. Gaming with the Linux Console
9. Finishing Penguin Warrior
10. To Every Man a Linux Distribution

• Glossary of Terms
• Bibliography

Related Links

Sample Code
No Starch Press
Loki
SDL (List of SDL games)
OpenAL
DRI
Mesa
libsndfile
Gamasutra

You can purchase this book from Fatbrain.

Long-suffering Slashdot reader WrinkledShirt contributes this review of John Hall's Programming Linux Games, and lays out the good and the bad in a book that's one of the few of its kind. More games are always good -- hopefully books like this one will spark some inspiration.

Programming Linux Games author John Hall pages 415 publisher No Starch Press rating 7.5 reviewer WrinkledShirt ISBN 1-886411-49-2 summary Well-written guide to a wide range of game-writing tools for Linux, but not a definitive reference work for any single task.

Introduction

The potential for linux gaming has really exploded in the last couple of years. In many cases, the potential has been realized -- Unreal Tournament, SimCity 3000, Tribes 2, Quake 3, Alpha Centauri, and many other successful Windows titles, have all been brought to Linux, with Loki leading the charge. Judging by the bottom line, there's a definite shortage of true cash-cow success stories in this enigmatic part of the industry, and hence, a shortage of good reference material for naive people hoping to produce that next cash cow.

However, we've reached such a point of critical mass of knowledge and technology that books had to start appearing sometime. So, despite the fact that there's no overwhelming market demand for Linux games and a high ratio of hobbyists to dedicated game developers for the OS, here we have a book aiming at taking amateur Linux game development to the next level.

However, much of the technology out there for game programming in Linux is still heavily in development, with many of the APIs and libraries still a long way away from a 1.0 release. Allegro and Clanlib are a couple of exceptions to this trend -- both are popular APIs that sadly don't get much more than a passing mention in the book. Their sexier counterpart, Sam Lantinga's SDL, gets a fair amount of treatment (no surprise there, considering John Hall was the lead author for a team based within Loki) -- but even this fairly feature-complete library, which Loki uses to port its games over from Windows, isn't explored in its entirety.

Instead, there are also crash courses in BSD sockets, package management, TCL, the framebuffer and various sound APIs, and what we end up with here is the consummate cookbook, a jack-of-all-trades-and-master-of-none tome that introduces us to a wide variety of Linux gaming topics while stopping short of being a definitive reference for any of them. Such is John Hall's work, an interesting, wide-ranging introduction to game programming for an operating system that few believed was capable of it not too long ago.

John Hall, an experienced game developer, participated in Loki's Civilization, Call to Power game hack, and is currently working for Treyarch developing that company's Spider-Man title for the PS2.

The Good

As far as cookbooks go, this is a good one, and there isn't much concerning Linux game API programming that isn't touched on. There's an ongoing case study (Penguin Warrior) that is developed over the course of the book. Each chapter introduces a fairly deep concept, gives a decent function reference related to the concept, then incorporates the knowledge into proof-of-concept code, and then uses the new-found knowledge to enrich the case study. The tone is straightforward and the execution is solid. The final game works well enough to give confidence that the reader could take the knowledge in this book and apply it to his or her own project, either to add new features or re-think old ones.

The book is also well-written -- the sample code is extremely well-commented and good error-handling is in place. He makes no assumptions about the knowledge of the reader, dealing with such introductory topics in Linux programming as vi vs Emacs, the FSH and make, although he never gets annoying or patronizing. *cough cough* LaMothe *cough*

Individual chapters stand out as being great introductory resources for material that doesn't have much in the way of documentation. The important aspects of SDL get good treatment in one complete and comprehensive unit. There's also a thorough chapter on audio programming, comparing and contrasting OpenAL, OSS, ALSA, Ogg Vorbis, and ESD (among others), and all this after showing off SDL's sound capabilities one chapter earlier. Many of the pitfalls associated with each of the different technologies, as well as the pitfalls of sound programming in general, are covered here. It's a great jumping-off point for those who don't know much about the audio end of things.

There's even a really neat chapter on incorporating TCL script interpretation within a program written in C. For anyone who's had trouble throwing together their own text parser for initialization scripts, or who's fed up with the constant recompiles needed when tweaking for the most arbitrary of changes of the game's AI, the information in this chapter is a godsend. In the Penguin Warrior case study, it's almost spooky how effective TCL turns out to be in making the computer ship chase and evade the human player.

Finally, I want to reiterate the effective use of the case study, Penguin Warrior. Having seen the way other game programming texts handle using samples to illustrate game programming concepts -- which is often a mish-mash, to say the least -- the way this book approached the issue is refreshing: there's one major project, and each chapter brings us closer to that project's completion. The code works as intended and goes a long way to convince the reader that the libraries and techniques explored in this book are near-commercial-level quality. (Networked games turned out to be choppy on my machine, but that was the only real black mark I could find in the program's execution.) If nothing else, John Hall deserves a good deal of thanks for proving that game development on Linux is a realistic and rewarding endeavor.

The Not So Good

At times, the generalist nature of the book left me wondering if Hall couldn't have gone just a little bit further in some of the topics. There's a decent enough synopsis about deployment using Loki's install tool, as well as packaging in general, although nothing related to the Penguin Warrior game itself, so we don't get to see the theory in practice as much as it could have been. Also, he teases us by early on by starting with the compiler, moving to the make utility, talking a bit about package management, and then mentions automake, but he stops short of really explaining how to bring that into an existing project. Considering all the fun little dependencies needed for multimedia programming in Linux, this would have been a valuable bit of information for anyone not used to deploying on the platform.

Another instance of this so-close-yet-so-far approach occurs when he talks about incorporating Mesa into an SDL program. He tantalizes us with a code sample illustrating how to use the SDL as a replacement for glut, but that's all -- the material doesn't really get deep enough to convince readers that a 3D neophyte really can abandon glut for the SDL, particularly when many OpenGL reference materials out there rely heavily on glut as a teaching aid for windowing and other utility functions. Loki primarily used SDL to handle its 3D utility programming, so at least we know it's possible, but given the exploding popularity of 3D games it's too bad this wasn't covered more.

It's sometimes hard to tell exactly who the book is intended for. The introductory chapters include discussions on topics such as the different gaming genres out there, despite the fact that game programming hopefuls who don't know that Quake is a first-person shooter must make up a really narrow audience. Also, it's almost enough to give one whiplash to see how quickly he dives into using ioctl() when only a couple of chapters earlier he was explaining the basics of using gcc. Next up soon after that? Strap yourself in, we'll be writing straight to /dev/fb0! It's almost comical to think about how much dangerous knowledge a newbie's been given over the course of the book. Still, like I said earlier, he never talks down to the reader, who because of this might feel compelled against better judgement to be whisked along into subject matter that really needs other support material to be of any real use.

Hall's a humble enough guy, which is great insofar as writing style is concerned, but in one of the last chapters, he starts questioning some of the choices he made while coding Penguin Warrior throughout the book. Specifically, he says he probably should have used C++ instead of C, Scheme instead of TCL, and UDP instead of TCP for the networking, and this is cold comfort for people who would have hoped that the author would have picked the best plan of attack from the beginning. That said, C, TCL, and TCP are appropriate choices due to the simplicity of execution and the fact that they introduce useful techniques from a design point of view. Still, there's no point giving readers a sense of wistful "What if?" if you don't have to. It also highlights that this book is more a beginner's API reference than a game programming book per se.

To take that point further, there also really isn't much in the way of abstract game programming theory. This book could have really distinguished itself as special if some content related strictly to game development was here. There's a mention of Gamasutra here, a method of quick division there, the equation of a distance from a point to a line thrown into the mix, and that's pretty much all there is. Topics not really covered include optimization, pathfinding, and cracker-proofing your code, and what is talked about on the subjects of artificial intelligence design, collision detection, and physics is all rudimentary ... For coverage on these sorts of topics, you'll have to look elsewhere.

Finally, and this is really not the fault of the author or the book, but one wonders if the time was right for much of this material -- or, at the very least, its highly generalist approach. DRI is making its presence felt, the various audio APIs out there are improving all the time, and the LSB is coming along nicely, but until there's a proven and stable multimedia base to work from, no definitive guide can be written, and this sort of organized dogpile is really the best we can hope for with so much stuff to cover. The SDL is a top-notch library for graphics programming, and it's likely an entire book could have been spent strictly on graphics programming using it, and the depth that such a book could have attained far surpasses what we're given here. Plus, in a year from now, who knows where any of these sound APIs will be? Of course, these might prove to be just esoteric issues in the grand scheme of this book.

Conclusion

Despite the criticisms I have of this book, I really don't want the message that is conveyed here to be anything but positive. There's a lot working for this book -- the chapters on SDL, sound programming and incorporating TCL and C are excellent, and will be especially helpful for people who are novices in these areas. Considering the alternatives (hitting dryly-written online docs or constantly shaking your Google to see what falls out), this book is a very attractive option. Programming a fully-functional multiplayer game would probably require more effort than might be suggested by the brevity of the chapter on socket programming, but that chapter is a solid introduction as well. The book as a whole is well-written and succeeds for the most part in its endeavor to make the best of a chaotic situation. I'd recommend this book to anybody who appreciates the messy-kitchen style of learning, or to anyone with decent hacking skills who just needs to break the ice when it comes to the Linux game APIs. And even though it gets slightly schizophrenic in its attempt to be both an introductory text and a definitive reference, this is the sort of book that could kickstart a new movement in Linux game development.

Table of Contents (exploded version here)

1. The Anatomy of a Game
2. Linux Development Tools
3. Linux Gaming APIs
4. Mastering SDL
5. Linux Audio Programming
6. Game Scripting Under Linux
7. Networked Gaming with Linux
8. Gaming with the Linux Console
9. Finishing Penguin Warrior
10. To Every Man a Linux Distribution

• Glossary of Terms
• Bibliography

Related Links

Sample Code
No Starch Press
Loki
SDL (List of SDL games)
OpenAL
DRI
Mesa
libsndfile
Gamasutra

You can purchase this book from Fatbrain.

Eddie Edwards writes "This story over at Gamasutra details how Worlds.com have been awarded US patent 6,219,045 for - well, for more-or-less exactly the client-server architecture used in Quake. As the article says, "the company believes the patent may apply to currently in-use multi-user games" (!) and Worlds.com "will also review other 3D sites who may be using [their] technology to ensure [they] are fully compensated". " Of course, Worlds.com will prolly get squashed on the prior art issue - but wow. From what I can see, IANAL, it's not so much Quake-like games, but more like 3D chat-game-type environment.

Decado writes "I found out from gamasutra that Michael Abrash and Dr.Dobbs Journal have made Abrash's now out of print "Graphics Programming Black Book" available for free download here. Written at about the time he was finished on Quake it was one of the most readable and informative books on graphics programming. Abrash begins each chapter with a real life anecdote to the problem he is solving and you can't help but think he is a cool guy. Though fairly dated now it is still a great read and his approach to optimisation still holds true today."

This is Slashback for the evening. Please be advised, through the following items, about ... how to turn that extra Pentium into a firewall running iptables; the state of the Symantec patent on software updates (uughh!); more on can satellites, and more.

a filtration system for your 2.4 goldfish Jay Beale points to this followup to his "Why iptables rocks" article of a few weeks ago: "It fulfills my promise to show how to actually build a home/SOHO firewall with Linux 2.4's iptables aka Netfilter. It contains the full code, explained piece by piece, to build a working firewall with 2.4, including all kinds of cool packet mangling for load balancing, redirecting stuff to transparent proxies, or avoiding nmap stealth scans ..."

Out of embarrassment, perhaps? An unnamed correspondent points out this bit of news regarding Symantec's patent on software updates. The upshot is, without pointing out that updating software incrementally is not a patent likely to win them a lot of favor from the industry they have simply decided not to enforce it. Smart move.

Not yet in the can, or the cube either Casey Ho of San Jose's Leland High wrote with some interesting information for those interested in tiny amateur satellites; Leland is one of the handful of schools whose students are designing experimental payloads for inclusion on an upcoming launch.

[We] are focusing on making a CubeSat. Leland High school officially has one satellite to launch, and there are four teams now competing to make a design that will be approved by CalPoly technicians. My own group will attempt to broadcast a powerful long term signal using only a small satellite. The project is not easy since there are a lot of scientific guidelines we must meet. We are discussing how to create a reliable circuit and transmitter that will function in extreme temperatures, vacuum, radiation, and most importantly, after an extra powerful rocket launch. The requirements are available here.

For some of you posters out there, sorry, no living organisms or explosives are allowed on the satellites. ;)"

Machinima makes the grade ILL Robinson writes: "Wanted you guys to know that our Quake II-based machinima film, Hardly Workin', received top honors at Showtime Networks' Alternative Media Festival - alt.sho.com. In an awards ceremony on February 8th at MTV Studios, Showtime awarded The ILL Clan with awards in both Best Experimental Short as well as Best of SHO for the festival. Using Machinima (films created with a PC game that can be modified with users' assets), The ILL Clan's film gained notice from the festival's judges - citing Hardly Workin' as a short with a high degree of innovation, design & creativity. We're pretty excited to receive the recognition, all the way from fans of ours who had been following us from the beginning and now, from a top-tier cable TV network. Cruise on over to our site for the official announcement, or to Machinima.com for more machinima works. And thanks also to the Slashdot readers, as they helped spread the word of what Machinima is all about."

Congatulations!

Enoch Root writes: "Nowadays, it seems like the gaming industry is bogged down by an obsession for technological innovation at the price of true creativity in gaming. Ernest Adams of Gamasutra proposes game designers remedy this by pledging to a sort of designer's Vow of Chastity, in the spirit of Von Trier and Vinterberg's DOGME 95. Down with 3D acceleration, it's time for innovation!" I've seen a couple of the movies that the DOGME crowd produced -- both were really good. But the medium of movies is a little different than gaming, so I wonder how will this can carry over.

Enoch Root writes: "Nowadays, it seems like the gaming industry is bogged down by an obsession for technological innovation at the price of true creativity in gaming. Ernest Adams of Gamasutra proposes game designers remedy this by pledging to a sort of designer's Vow of Chastity, in the spirit of Von Trier and Vinterberg's DOGME 95. Down with 3D acceleration, it's time for innovation!" I've seen a couple of the movies that the DOGME crowd produced -- both were really good. But the medium of movies is a little different than gaming, so I wonder how will this can carry over.

That much software sucks -- perhaps most of it -- is hard to dispute. Except for the simplest programs, it seems like the price of complexity is a tendency to failure. Commands don't work, user interfaces are neglected to the point of ruin, and components of even the same piece of software often clash with each other. And once you start combining them and try to use more than one application at once, sometimes the best you can hope for is an operating system that neatly segregates the problems so that your word processor doesn't take down your web browser, your IDE or your e-mail client. At least those are desktop applications for individual users, though -- the trouble compounds briskly when the common faults of software manifest in multiuser environments, where one machine going down means a wasted time and frustration for a lot of people at once. In an effort to outline the ways that software could suck less is coding, reading and writing dervish chromatic.

Making Software Suck Less - Processes Once upon a time, a prominent writer and programmer rose to declare "I want software that doesn't suck!" He then explained that certain successful free software projects have similar development features that contribute to software quality. Most of us aren't gifted with the organizational clarity of a Linus, or the brilliant non-orthogonal design of a Larry.

There's hope, though. Improving the ways in which we produce software can dramatically improve the software itself. Extreme Programming suggests that simple habits, acting in concert, produce extremely powerful results. By adapting these techniques to the unique world of free software, we can improve the quality of our programs. We start by restating some common truths about free software development.

Distributed Development Open development, of course, means that anyone with the time and the inclination can look at the code. Developers and dabblers have the opportunity to modify it to their needs. This by no means guarantees that anyone will do so. Making source code available is no silver bullet. Many qualified eyes actively looking for bugs make bugs shallow.

To harness the power of additional developers, you must attract them to the project. A simple design and clear documentation reduce the amount of work needed to come to grips with the system. XP suggests an overall metaphor to describe the system as a whole and to provide good names for the components and subsystems.

Test First The most powerful weapon in your toolbox is comprehensive unit testing. (Unit tests are automated, independent procedures that exercise the smallest possible pieces of functionality individually.) Extreme Programming recommends a test-first approach. Before adding a new feature, the programmer writes a test for the feature and runs all the unit tests. The new test fails, so he writes code to pass the test. When all tests pass, the feature can be checked in. Tests cover everything that could possibly break.

When a bug appears, the programmer writes tests to demonstrate it. After fixing the bug in the code, he runs all tests again. This not only proves that the fix corrects the defect, but it proves that the correction did not break any other features. Besides that, it can prompt the programmer to write additional tests he had not previously considered.

Test-first programming ensures that all features have unit tests. Coders receive immediate feedback -- it's almost like a game. It produces a different mindset, freeing the programmer to concentrate solely on the task at hand. Code becomes easier to write, in the same way that finding the correct piece for a jigsaw puzzle is easier with its neighbors in place. Finally, it gives programmers the confidence to refactor, modifying existing code, by identifying the effects of a change.

Consider providing your test suite with the project. Add a 'test' or 'check' target to the Makefile. Projects designed to run on multiple platforms and distributions can generate better bug reports by including test results. Make it easy for users to report failures.

Simple Solutions First After writing a test, write the simplest possible code that could pass it. Resist the tendency to make things more flexible than you need at the moment. Concentrate only on the task at hand, programming only what you need to pass the test. Don't sacrifice current elegance and simplicity for a feature months down the road.

"It's true that 'simple and tested code means less bugs'.... Good and clear interfaces reduce bugs. Avoiding complexity reduces bugs. Using your brain before you code something up reduces bugs."
-- Linus Torvalds

Good tests free you to change things in the future by identifying the effects of a change. Simple code localizes changes, reducing interconnections. Besides that, your design will change. Adding a feature will take the same amount of time whether you do it now or in the future. Don't spend time and energy overgeneralizing for something six months away when no one will use it in the meantime. Reduce the need for costly and time-consuming rewrites by avoiding extraneous complexity. Have a Plan, Code For Your Users Write a plan for the software. Describe each feature in a paragraph or less, with sufficient detail that people will know when it is complete. Arrange the stories by importance, then tackle them in that order. This allows you to identify the work that will provide the most value to the customer. (In a free software project, the lead developers may be the customers.)

Dividing the project into stories allows delegation, especially in free software projects. Some tasks require an experienced hacker, while others serve as a gentle introduction to the program. Writing stories also provides sane goals and a project roadmap. Choose a few stories for each release. This gives end users a clear view of project progress.

Continuous Design, Refactor With tests in place, you have the freedom to refine your initial design. By using the simplest solution first, you avoid investing time in hard to follow and difficult to maintain code. Your initial design will change. Your plan will change. Expect this and allow it to happen.

"Premature optimization-including premature low-level design--is the root of all evil."
-- Michael Abrash

When you see an opportunity to refactor, do it! Eliminate duplicate code. Relocate common features into a new object or a function. Reduce complexity and interconnections. Don't maintain the same functionality in multiple places. Use simple, well-defined, and consistent interfaces. This, along with your test suite, will allow you to overhaul individual pieces without having to track down holes in far-flung files. Release Often, Release Working Features Commit to regular release dates. This shortens the feedback loop. Users who can count on regular, stable releases with valuable new features will be more likely to use the software. It also provides more frequent entry points for new developers.

Follow your plan to add a few important features to each release. Focus programmer time and effort towards a simple, reachable goal. Allow time for design, testing, documenting, and packaging. The more often you have to do this, the more likely you are to streamline these processes. Resist the urge to add features you cannot complete in time. Instead, break them up into smaller stories and implement the most important parts. As usual, the unit tests help to stabilize the codebase and keep it in a state of stability. After completing a release, take time to modify your stories, shuffling priorities as necessary. Then commit to the next release.

Conclusion If we truly want excellent software, with well-developed features and no messy surprises, we need more discipline in our approach to creating software. In my experiences with these techniques (and in talking to other developers), I have found that even simply migrating to a test-first approach, though painful, has increased my productivity and my confidence. It's scary at times, but immensely satisfying. Taken together, who knows what levels of excellence we can reach?

An anonymous reader sent in an awesome article by Michael Abrash (If you don't know, I'm not telling). Tons of great bits in there, advice, anecdotes etc. Definitely worth a read if you are either a programmer, or a game fan.