Archive for development

Modern platforms and the indie scene: An analysis of the pros and cons

{ January 19, 2008 @ 6:39 pm } · { development, interesting, video games }
{ Tags: , , , , , , , , , , , , , , , , , , , , , , , , , } · { Comments (6) }

The idea of the average joe going gung hoe and simply making a creative piece without much in the way of official support from major entities is one which has long been a part of most entertainment scenes. Profitable underground scenes exist for the movie and music industries which have their own devoted followings willing to expose various underdogs to the world. It’s only been in recent years that video games have had something similarly viable in the form of indie games. Essentially able to buck the potentially arduous process of becoming a licensed developer and finding a decent publisher, indie games have the ability to reach their audience in a more direct manner, albeit on a smaller scaller. What then matters more is what platform the development team chooses to create its games on, for the most popular ones in recent years each have their own inherent strengths and weaknesses. These in turn not only affect the creative process, but also how the game can be released. For simplicity’ s and conciseness’ sake, each system will be analyzed in a bullet-point format outlining the pros and cons.

Dreamcast

Pros
-Extremely easy to load unlicensed software on most systems, thanks to the inner workings of the system’s disc drive
-Multiple possible development environments, including a modified version of Windows CE to make the system work like a quasi-PC
-For arcade ports based on NAOMI hardware (ie: recent Guilty Gear games), the hardware is almost the same except for a few minor differences
-Solid fan base for console, as well as prominent online coverage of modern developments
-It’s still possible to publish and sell games for it to the public without interference from Sega

Cons
-Underpowered hardware compared to its other console brethren from the same period
-No easy way to use official Dreamcast discs (GD-ROMs); finding blank discs is a relatively easy task, but finding a disc writer is a costly proposition
-Hence, reliance is entirely on CD-ROMs, which have approximately 300 megabytes less space
-Previously-mentioned alternative Windows CE environment isn’t exactly the most intuitive thing in the world

PlayStation 2

Pros
-Incredibly large fan base
-System is easy to mod in a number of ways to load unauthorized software
-Using Linux to run the game is theoretically possible
-Accepts regular burned DVD-Rs
-Emulation is a decent testing option for those with powerful computers
-Can use CDs or DVDs as the game-carrying medium

Cons
-Notoriously difficult development environment
-No legal ways to develop games, as using the SDK without a license is illegal
-Hardware isn’t as powerful as GameCube’s and Xbox’s
-Emulation support is either good, spotty, or not present on the PS3, depending on which model is used for testing
-Have fun with the vast piracy scene if the game goes commercial somehow
-Linux on the PS2 is incredibly obscure and getting the right equipment for it is quite an endeavor

Xbox

Pros
-Easily modifiable hardware, especially the hard drive
-Powerful specifications
-Legal development kit alternatives are available online
-Can accept CDs or DVDs
-Hard drive can be used for file caches
-Large underground following
-Linux (or even Mac) can be installed and used, should developing for the Xbox variations of those sound appealing
-Games can be run directly from the hard drive

Cons
-Might as well be developing for a circa Windows 2000 PC
-Xbox is used more often for applications (ie: emulators, music players, etc.) rather than outright games
-Hardware is more finnicky about accepting burned DVDs due to the different available drives
-Almost certainly no way to make it backwards compatible on the Xbox360 due to the system’s emulation method (software)
-Emulation on a computer is virtually non-existent

GameCube

Pros
-Relatively easy development environment
-Powerful hardware if harnessed properly on all fronts
-Designed for low load times
-Linux, yet again, is possible
-Wii is backwards compatible, thanks to including the same hardware specifications (assuming a firmware update doesn’t change what can load in the future)

Cons
-Hardest system to get unauthorized software loaded
-Only viable way to run full-scale games is to do a major disc drive mod
-Hence, system cannot run conventional mini-DVDs out of the box
-Incredibly tiny development scene compared to the others
-Emulation is still in relatively early stages
-It’s much easier to want legitimate development hardware than to actually find some

Xbox360

Pros
-XBLA development environment is universal (code can be run on a PC and 360) and easily acquirable
-Very low entry fee to be “authorized” by Microsoft
-Good-sized user base a few years into the generation
-Community is rather supportive of indie games on the platform

Cons
-Arcade games have a 150-megabyte limit
-No legal way to make larger-scale games
-No current method to run unauthorized code
-Again, good luck finding legitimate development kit hardware

PlayStation 3

Pros
 -Linux is actually more or less legitimate, as Yellow Dog Linux appears to be full-fledged.
-Plenty of horsepower to work with, especially regarding the Cell processor
-Sony actually keeps an eye on the scene to see what would work best with its system
-No known download size limitations

Cons
-Development on the system is notoriously hard
-Reception to indie games on the system has been mixed
-Sony appears to be more selective about which games are officially made for download
-Hacking the system, while present, still needs to make more progress
-Who uses Yellow Dog Linux?
-Not surprisingly, finding a legal way to develop games without Sony’s endorsement is currently oxymoronic
-Optimizing graphics to prevent frame rate drops is easier said than done

Wii

Pros
-Opera browser in tandem with third-party stuff can be used to make Flash games compatible
-A good chunk of the hardware is the same as the GameCube’s with just some upgrades here and there on top of the motion-sensing capabilities

Cons
-Hacking the system has just barely become possible and still needs time for refinement
-Although it can take burned DVDs, encrypting homebrew games into Wii format is probably much easier said than done
-The facilities for Nintendo-sanctioned indie games is, as of this writing, not currently up and running
-Not every game can involve hitting the other players with the wiimote and nunchuck attachment
-Firmware updates could mean keeping unauthorized games playable on updated Wiis will be an uphill battle

DS

Pros
-A number of ways to go about getting indie games to run on the system
-Besides the touch screen, hardware such as the graphics cards can be used creatively (ie: boost the graphical power of one screen)
-Huge user base
-A decent amount of coverage for unofficial games on the Internet
-Tools exist to help make such endeavors legal

Cons
-Indie games have to be run off of SD cards or something similar, instead of being put onto a legitimate DS card
-Space limitations could arise due to above issue

PlayStation Portable

Pros
-Best portable system for rendering polygons
-Thriving hacking scene
-PSP Slim models come with more RAM

Cons
-Sony isn’t nearly as supportive of its PSP as it is with the PS3 in regards to indie games
-Firmware updates have the potential to render work null and void at least temporarily on updated systems
-Getting unauthorized code to run on it (read: modding the system) can be a bit more complex than on the DS
-A lot of sanity could be lost due to loading times if it’s a full-fledged game, especially on non-Slim models
-Creating decent controls may be a headache-inducing task

PC
-No need to worry about Microsoft, Apple, etc. making the game null and void via an update
-Constant access to the latest hardware, meaning fewer possible constraints
-Plenty of programming languages, modelling tools, engines, rendering standards, etc. to choose from
-Much more common to be able to have large-scale beta tests
-Storage space is not an issue anymore
-Many more experts on the Internet for working with PCs than there are for consoles and handhelds

Cons
-Not every user has the same hardware and that absolutely needs to be taken into consideration during development, lest the game is completely broken for some people
-Getting attention without using the popular outlets could limit awareness
-Nothing is really constant/stays the same, especially in terms of hardware and OS updates

The world of indie games may not be especially profitable, but it is vast. The ideals behind it are far less prohibiting than the standard developer/publisher model, enabling incredibly abstracts games to still get their fair shake. Additionally, events such as the Independent Games Festival get a decent amount of press and last year’s E3 had added a similar section to their convention. Just a few years ago, the indie scene wasn’t nearly as prominent as it is today. But because of things such as Xbox Live Arcade and the rise of the Internet, a lot more attention is now present. Regardless of which platform is used and what challenges must be overcome, the idea of being able to turn the imaginary into reality is the very core of the indie scene. Plus, just about any gamer can apply. All that’s needed is a little bit of commitment, a willingness to stand up for imaginary ideas, and a hunger to make things the best which they can be.

Doing the RTS genre justice elsewhere: A profile on Nintendo

{ January 13, 2008 @ 10:19 pm } · { development, gamecube, gba, video games }
{ Tags: , , , , , , , , , , , , , , } · { Comments (4) }

When you boil down the real-time strategy genre to its bare bones, what’s left is essentially a style of gaming in which players simply command a bunch of troops into battle. Most games include other nuances related to battling, such as resource-gathering and unit upgrades, but those are really tangential to the real core of the RTS genre. But it’s because of these extra features that such games tend to work only on the PC because there aren’t as many control restrictions as on other platforms. There have, however, been attempts to make a successful RTS game inhabit consoles, although most of them tend to make mistakes which cripple their potential. But there is one company which has a history of getting it right: Nintendo. There are two cases in point which prove this: the Pikmin series and Napoleon, a Japan-exclusive game for the GBA. They’re RTS games through and through, but not in the vein with which many are familiar.

The Pikmin games and Napoleon are both successful entries partially because they’re both well-executed interpretations of the genre, rather than complete adherents. Both games have conventions which are instantly familiar to the average RTS player, but they’re included in such a way that they’re not overwhelming aspects of each game. Pikmin, for example, has resourcing gathering. Each time the player has the colorful soldiers kill an enemy creature or knock down special flowers, they get pellets. Unlike in games such as StarCraft and Command&Conquer, however, the pellets only go towards one thing: expanding the pikmin army. There’s no need to worry about diverting some of it to buildings, some of it to repairs, and the remainder to miscellaneous things. In Pikmin, you gather the pellets as a means to create a greater army and nothing else. There’s a bit of depth with the numbers on the pellets, as well as their colors, but their inherent purpose remains the same. It’s just one such thing which eliminates a lot of the confusion that can be found in PC RTS and allows players to simply focus on other goals.

If we examine Napoleon under a similar premise, we find that the genre has been simplified even further for the purpose of overall usability. Napoleon is straightforward in that its goals are always clearly laid out based on how it presents each map and in the fact that each unit can only be used either to fight or to capture. Some have other minor abilities, like being able to be a guide for a few other units, but other than that, the game always makes it clear what needs to be done. This is vastly different from Pikmin, which is much more of a free-form RTS whose goals depend on exploration and how the player reacts to the environment. (ie: “Do I send these blue Pikmin in the water, even though its inhabited by several tough enemies, all for one unnecessary part?”) Pikmin also enables players to prioritize tasks based on what day they’ve reached in the game, whereas Napoleon is very linear by comparison in terms of progression. Players simply take care of what needs to be taken care of and move on to the next map. Napoleon then takes this linearity further by streamlining and automating the resource-gathering aspect of the game; money simply flows in at a steady rate depending on how many cities have been captured. There’s no mad dash to simultaneously micromanage the resource-gatherers and the attackers in the game, for much of it is already regulated by the game itself. Similar simplification can be found in other features of the game in an effort to allow it to be as accessible to as many people as possible.

It’s been established that Napoleon and the Pikmin games are successful on the grounds of how they translate certain traits of the RTS genre. But what is perhaps even more important is the fact that they control intuitively in a genre which is virtually infamous for convolution. In Pikmin, the most important controls can be split into three easily understandable parts: 1. The control stick is used for moving Olimar and the cursor in front of him. 2. The C-stick is for moving the pikmin around Olimar and the world. 3. The A-button is for almost all interactions with the pikmin, including things such as throwing them and plucking them out of the ground. 4. The B-button is for summoning them back to you. There are other auxilary functions assigned to other parts of the GameCube controller, but it’s important to note that the game is very playable with just those four parts to the extent where the game could be beaten only using them. Knowing that every action in the game can be summarized into a few very concise things again allows players to place attention on other things, instead of obsessing over something such as keyboard combinations.

Napoleon again does this on the GBA. In fact, the game is played almost entirely with the D-pad and the A-button. Whereas Pikmin uses a few more buttons on the GameCube’s controller in order to accommodate more functions, nearly everything in the game is accomplished solely by using the D-pad and the A-button. This simplicity is made possible in the fact that the game determines what the player wants to do depending on the context of the situation. Everything from moving units to creating them to attacking others is done in this manner. The player simply has to determine what it is they want to do and the game is able to keep up. There’s nothing really unintuitive about that, per se.

One other thing which should be addressed is the fact that Nintendo’s RTS games are also successful because they manage to break from the mold in general. Whereas most entries in the genre are either science-fiction or medieval/historically-inclined, Pikmin places players in the shoes of a stranded space ship operator in search of parts and Napoleon is played from the viewpoint of the legendary Frenchman himself. Cliches are not what define either one at all. Few games have players dealing with highly abstract creatures or, in Napoleon’s case, beast summonings via pentagram. That in turn makes them memorable and just as creative and pioneering as their more famous PC counterparts.

Nintendo isn’t the only company to attempt to make a well-done RTS game on something other than a computer, but it’s one of the few that’s consistently gotten it right. From how certain gameplay mechanics are treated to how the game controls as well as how they’re conceived, games such as Pikmin and Napoleon has shown how to do RTS games properly without making them look like a mere shadow compared to giants such as WarCraft. If nothing else they’re endeavors which prove the seemingly impossible: An RTS can be done on consoles and portables and still hold up. That in itself is a feat which few in the industry have yet to replicate.

Another Theoretical Porting Project: The Sims

{ January 13, 2008 @ 6:24 am } · { development, ds, interesting, port, the sims, video games }
{ Tags: , , , , , , , } · { Comments (2) }

In one entry on my blog on GameSpot, I discussed how I would port games such as Ikaruga and Gears of War to platforms which were hardly built for such games. While it got a warm reception (albeit mainly for the absurdity of it all), it was a bit too complex for its own good. Although maybe somebody in the emulation development community might have understood what I said, they aren’t really my audience, so a lot of my points may have been lost. In an attempt to rectify that mistake, this entry will keep things intelligent, but more accessible to the average gamer. Ultimately, this should result in the best of both worlds. Having said that, this is a project which I would personally enjoy pursuing much more than the last ones discussed and this is essentially my vision for it.

The Sims
Porting Platform: Nintendo DS

I’ll admit that The Sims has had a couple of installments on the dual screen system over the years and, to be fair, they’re probably decent translations of their respective console brethren that are released at the same time. However, a dyed-in-the-wool Sims game hasn’t ever really been attempted on the DS, which is what this entry tackles. Given the capabilities of the hardware, I believe a port of the PC classic is more than possible. But some things might have to be changed in order to make it work well with the system.

Graphically, I believe the DS could easily handle rendering things Sims-style, where only things such as the people, house, etc. are actually made out of polygons and everything else is sprite-based. Frame-rate wise, making the graphics in a similar matter for the port would probably work just fine and wouldn’t be particularly taxing on the system. A fully three-dimensional graphics engine like what’s found in The Sims 2 would also be theoretically possible, but because there can be, at times, a lot of things happening on the screen, skipping/lag would be more liable to happen and, in order to prevent that, some polygon counts somewhere would have to be limited. Whether or not a fully 3D system would make the game more visually appealing because of that would therefore be disputable. It could still look perfectly fine with the sprites and polygons combination.

The artificial intelligence in The Sims also isn’t particularly complex, which can be attributed to how the game is purposefully designed to be that way. (The game is, in many ways, a virtual doll house and dolls aren’t exactly sentient beings.) The characters perform their tasks in a linear order, stand around when they have nothing else to do, and, if the player enables it, can be somewhat self-regulating with regards to bodily functions. A problem may crop up when a lot of sims are in the same area as once but, again, because of the simplicity of their AI, that may actually be a blessing for the CPU. Hence, there really isn’t too terribly much to worry about in this area.

I’d like to think that the DS is perfectly capable of playing Simlish and the modest music roster without much hassle, so I won’t even worry about addressing that here. But feel free to reflect on how cool it would be to have Simlish on the go.
Controls are where porting The Sims to the DS could potentially get hairy if they aren’t handled properly. The Sims has very much been a series which is best done with a keyboard and mouse simply because there’s more room with which to work. The DS, however, is a tad more limited in that respect. The game could control decently if different functions were assigned to different buttons, but that doesn’t necessarily make it overly user-friendly. But, if everything is simply assigned to the touch screen, things could easily get cluttered and make things equally frustrating. What should be done?

Do a quasi-hybrid of buttons and touch screen usage, but with more emphasis on the latter. However, before we even start talking about specific functions, it’s best to mention how each of the two screens would be used. The upper screen would be used to give a close-up view of the action, with something reminiscent of what the original Sims games provides. The view can be rotated and whatnot, but for all intents and purposes, not much is done with the top screen. (It would still, however, also be used to jump to where important events are taking place to notify players of their occurrence.)

The bottom screen with its touch screen would therefore be vastly more important. The majority of its real estate would have a top-down view of the floor which the currently-controlled sim is inhabiting. It wouldn’t take up the entirety of the screen and, indeed, there would be well-defined borders to tell users what exactly the boundaries of it are. Within the window, the stylus would be used like the mouse was in the PC game: to highlight the world around the sim and indicate what should be done at that specific location. For example, if a randomly blank patch of flooring was selected, a menu would pop up with two options: “Move here” and “Cancel.” Or, if an object or sim was selected, then a menu with possible actions related specifically to it would appear. If a refrigerator was picked, then things such as “Fix a snack” and “Fix a meal” would show up. If a sim was selected, then options like “Talk to” and “Smack” would appear. In the latter example, the DS port would also be consistent in that actions with other sims are contextual depending on where they’re located and what’s around them. (ie: The two could be made to play a video game if they’re sitting in front of a television that has a console hooked up to it.)

The remainder of the screen space on the bottom would then be devoted to things such as menus and picking other sims. With regards to certain menus, such as those pertaining to construction and buying/placing furniture, these would again be dependent on the stylus and their manipulation should be mostly self-explanatory. (The rotation of furniture, for the record, could be done by selecting it with the stylus, picking an edge, and then dragging it accordingly, all while still in the pause menu.) However, other miscellaneous functions could be possible with the help of the touch screen. To incorporate the fact that user-created content was popular in the original game, features such as texture creation (for things such as roofs, arcade cabinets, etc.) could be included as a way to personalize the household and its items. An object model-making feature could be possible as well, but because of scripting issues, this wouldn’t necessarily be for the average player.

As for how the remainder of the system could be used in terms of its buttons, there’s very little that would need to be used. Really, the game could get away with maybe using only the L and R buttons for camera rotation and not use any of the other buttons at all. Sure, the D-pad and face buttons could also be used for menu navigation, but those are mostly givens. The D-pad could also possibly be used as a stylus substitute on the bottom screen, but moving that cursor with it would be about as free-flowing as playing SimCity on the SNES without the mouse peripheral.

Doing a real port of The Sims, instead of simply a translation of the series’ console counterparts, would be an interesting endeavor to undertake because although the system may appear to be tailor-made for something like it at a first glance, it’s still delicate enough where the wrong design decisions could break a potentially great game on the system. From the way the graphics would be rendered to how the game would simply control, everything would require careful consideration in order to get everything just right. But really, it’s The Sims, so to do everything just right is the only way to properly do justice to it. There simply wouldn’t be any other way, especially on a system like the DS.

An opening day promotion. Get it now while it’s still hot!

{ January 12, 2008 @ 4:59 am } · { development, gamecube, interesting, mario, sdk, software development kit, video games }
{ Tags: , , , , , , , , , , , } · { Leave a Comment }

Video game development has always fascinated me to no end. It’s always an exciting endeavor for me to go look at a game which I know very well and start looking at old materials related to the game which were posted before its release. I nitpick everything from screenshots to gameplay videos in an almost archaeological fashion. Most games tend to at least undergo some sort of evolution over their course of development. The more interesting ones, however, go through whole revisions. (Resident Evil 4 is especially famous for having done that.) It’s the notion of what a game could have been, rather than what it became, is really the intrigue which drives me to this very day to keep on investigating.

Hence, it probably shouldn’t be considered much of a surprise that I’ve acquired some interesting relics over the years. One of the ones of which I’m proud the most is a set of old GameCube software development kits I acquired for less than $100. While some of them are just different versions of the basic software, others cover things such as music manipulation and working with external development hardware (ie: special cartridges made for the system). After attempting to take some of the discs for a joy ride, I decided to go dumpster diving and see what interesting little tidbits I could discover lying around.

Luckily enough, a few piqued my interest. My favorites are a couple of theoretically playable tech demos included in order to acclimate developers to the then-new hardware. One was made by Nintendo in which you could travel to different rooms to see different parts of the hardware being put to work. It mainly focused on visuals, as there are rooms devoted completely to things such as anti-aliasing, texture reflections, and sheer polygon counts. None of it may look like Resident Evil 4 or Twilight Princess, but it’s still neat to see what Nintendo was experimenting with at the time before the GameCube’s launch. (Did I mention some of the software is from the Dolphin days? No?)

The other tech demo was a physic-oriented one which I believe was made by the studio behind The Simpsons: Hit and Run, of all things. Based on a video that I saw on it, I believe objects could be thrown at a basic character who would react to the impacts accordingly.  It was physics based on collision, so no ragdoll or other such nonsense in that demo.

The best part about both of those, however, was the fact that documentation came with both of them. Nintendo’s came in the form of some HTML pages which functioned as a “tour” and the other one as a PDF. While they’re definitely written in developer-speak, there’s still enough which is comprehensible to the average intelligent gamer. That’s where this “promotion” comes into play. Because I’m in a generous mood, I thought I should let some people take a gander at part of what I found, specifically the Nintendo demo’s documentation. Let me know what you think of the comments section and, maybe in the future, I’ll do more things like this.

As such, feel free to nab it here. Nothing super sketchy is included, of course. Just extract the files, open up the index HTML file, and have fun. (Oh, and the good stuff is in the the “Technical Information” section of the main page.)