Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - Snarky

#281
General Discussion / Software MIDI driver
Thu 02/06/2005 00:19:09
I remember seeing a link to an application that was a MIDI player and also could act as a software MIDI driver. Now I can't find it. Searched the forums in all ways I could think of.

Could anyone help me out?
#282
This doesn't seem to have been posted here, but just about every other indie adventure game site reports that the game 5 Magical Amulets is now available for download at http://offstudio.fabry.cz/.

I'm downloading it now. It's a massive 142 MB size, includes English and Czech language options, and it's made with the Wintermute engine. Looks pretty promising
#283
Adventure Related Talk & Chat / Pimp My Game
Wed 16/03/2005 05:32:52
What's the best ways to promote an AGS game?

How far can you go before you start annoying people and creating a backlash? Are there any mistakes some people make that cause a game to get less attention than it deserves? Is there something obvious that could be done but no one has done yet? Have any AGS game releases had an actual strategy for publicity? Or tried any dirty tricks guerilla marketing tactics to get more attention?

Speaking as an AGS "consumer", I think the #1 mistake made by game creators is to not post any screenshots in the announcement thread. I'm much more likely to download a game with horrible graphics than a game where I have no idea what to expect.
#284
I've been playing with PocketSCUMM (ScummVM for Windows CE) recently. For those of you who don't know, it allows you to play classic adventure games like Monkey Island and Broken Sword on PocketPC PDAs and Smartphones running WinCE.


Flying back home after Christmas, I brought with me my iPAQ and a bunch of games I haven't finished: Loom, Indy 3, Flight of the Amazon Queen, and Simon the Sorcerer. I ended up playing FotAQ for much of the flight.

This got me thinking: How would you design and make an original adventure game to be played on a handheld platform? The discussion has come up before (#1, #2), but didn't touch on the specific design challenges imposed by mobile devices. I think that would be an interesting topic to consider.


Handheld Platforms
Let's start by clarifying what handheld devices we're talking about.

You have gaming systems: The Gameboy, Nintendo DS and the Sony PSP being the major ones. Screen resolution is, respectively: 240x160, 2*256x192 (two screens, you know), and 480x272. The games are controlled with joypad-style buttons. The Nintendo DS, however, also has a touchscreen with stylus.

Then you have PDAs: Your Palm and PocketPCs. Screen resolution: (up to) 320x480, and 240x320, respectively. Mainly controlled with touchscreen with stylus, although there are a few buttons, and you can buy (tiny) keyboard peripherals.

Then you have mobile phones: Specs for these vary enormously. You can get models with 320x240 or higher screen resolution. Some have touchscreens, some have keyboards. Most have telephone push buttons as well as arrow keys and other control keys.

There are also hybrid devices: The iPAQ in the photo also functions as a cell phone. The Nokia N-Gage is a cell phone and a (crappy) gaming system. Each new mobile phone has more PDA functionality.

The point here is that all of these devices are powerful enough to be adventure game platforms. There are already other games for all of them. Of course, you also have handheld devices that probably aren't suitable for graphic adventures, like iPods, digital cameras and graphic calculators, so let's focus on the ones mentioned above.


The Case for Handheld Adventures
Why would we want adventure games for handheld devices, anyway? Well, for one thing, it might turn out to be a niche for adventures to flourish (commercially). Having fallen out of fashion on the PC, and never really gained a foothold on console systems, mobile gaming creates a new opportunity for these games to gain popularity. There are some reasons to believe this might be possible:

The golden age for adventure games ended partly because they were superceded technologically, and never found a way to take advantage of the increased power of modern PCs.Ã,  Handheld devices have specs similar to back when adventures reigned, and it's possible that price considerations will mean that lower-end devices don't improve drastically in the near future.

Cell phones, in particular, are everywhere. My sister still doesn't have a PC, but she sure has a cell phone. Most of these people aren't traditional gamers, and might be a better market for adventure games than gamers are.

Some people predict a coming boom in mobile gaming. If these are the platforms of the future, we want adventure games to be along, right? There's certainly some demand for them, as seen in the threads I linked to.

Finally, even if handheld adventure games don't break through into the mainstream, it will allow dedicated fans (i.e. us) to play them while on the move. So in conclusion, I think it's worth trying.


The Challenges
Some of the problems facing handheld adventure games can be observed in PocketSCUMM:

Screen
The screen size of the iPAQ is 240x320; it is taller than it is wide. Since PC monitors are wider than they are tall, you have to tip the iPAQ on its side to utilize the screen optimally. That's not a big problem, and tipped over the screen size is perfect: The full resolution of the classic VGA games plus a bar at the bottom for the PocketSCUMM controls. However, other WinCE devices don't have standard screen sizes, and the original graphics have to be resized to fit on their screens.



Image originally posted by Jaz
For original games, I see two challenges here. First, many devices have non-standard resolutions, meaning that it would be difficult to release a game for many different devices. Secondly, most handheld screens are portrait-oriented (taller than they are wide), and not all can be tipped over as easily or elegantly as the iPAQ (think flip-open cell phones). Is a tall aspect ratio suitable for adventure game backgrounds? I have my doubts.

I expected that the small physical size of the screen would present a problem. In fact, I found it difficult to play Indy 3 because the text didn't show up well on the iPAQ (too thin, not enough contrast). However, other games were just fine, even when I tested them on another device with a much smaller screen. So if graphics are designed with this in mind, I don't think it will be a problem.

Controls
This, I think, is the biggest obstacle to adventure games on handheld devices. It might also present the greatest opportunity. Almost all modern graphic adventure interfaces work within a point-and-click paradigm. You have a mouse pointer, you move it around, and you click on things. This doesn't apply to handheld devices. Using a touchscreen and a stylus, like on PocketPCs, might seem like it's equivalent, but there are major differences. There's no mouse pointer. That means you can't indicate when the player moves the mouse over a hotspot. There's no right-click. That means you can't switch modes quickly in Sierra games, or perform default actions in LucasArt games. You can't place the pointer anywhere without having it count as a tap (a click). (PocketSCUMM allows you to map the buttons on the device to get around these problems, but it's still somewhat awkward, especially when pixel-hunting.)

Taking adventure games away from point-and-click interaction and to tap-and-drag interaction means rethinking the interfaces, and I think that's a great opportunity to move the state of the art forward. How about an interface that allows you to circle stuff? Or rub parts of the screen? Nintendo DS is experimenting with these interactions right now. Or how about voice-driven interactions (since most handhelds are guaranteed to have a microphone)? How would Loom play if you actually had to hum or whistle the notes? Can the camera that is now commonly built in be used?

For devices that don't have touch screens, the interface issue becomes more thorny. A pointer that cycles between hotspots instead of moving around all the screen? Allow users to select their action from a list of options? Back in the day I played Indy:FoA without a mouse, moving the pointer with the arrow keys on my keyboard, but I doubt it would be very popular as a standard control.

Mobility
The essential point of mobile and handheld devices is that you can carry them around with you and use them anywhere. That creates some additional considerations for game design. Players might be jostled, interrupted or distracted at any moment. So all actions should be undoable and/or repeatable, there should be a handy way to pause/suspend/quit the game instantly, and the game should not allow players to possibly miss critical information. You can't assume players have access to paper and pen, so code-breaking puzzles are out, as are most mazes (yay!). The battery might run out, so a reliable autosave/backup feature is required at the least.

Also, the game might be played in public, and this might affect what sort of content is appropriate. Music, sound effects and speech might prove irritating to others and embarrassing to the player (unless headphones are used). Some amount of discretion is probably required.

Play Patterns
It seems likely that a handheld game will be played in shorter sessions (maybe in the line at the supermarket, on the bus to work etc.), and this should influence the design. It should be quick and easy to start up the game (no forced intros or lengthy company logos) and jump back into play (maybe some kind of reminder about what's going on, like the notes in the Ben Jordan games). It should be possible to make some progress in five-ten minutes. In terms of storytelling, players may perhaps not be as patient with reading lengthy dialogues or found diary entries. You may have less of their attention as they're playing. I'd assume this would make simple or humoristic plots more appropriate for handheld adventure games.


Developing and Distributing Handheld Adventures
Making games for the portable gaming systems, whether the Gameboy, DS or PSP is (AFAIK) only possible for commerial developers. Writing the games requires access to platform SDKs, and distribution is on propietary formats.

For cell phones and PDAs it's much easier. Games can be downloaded directly on to the device, or to a computer and transfered to the device wirelessly, over a cable or on a standard memory card.

Java runs on a large number of these devices, and is probably the most feasible development option if targeting more than one device. For PocketPC and WinCE devices, there's also the .NET Compact Framework, with the option of developing in C#. Writing in C(++) runs into the problem of getting hold of compilers for each platform, ensuring native support on all devices, and possibly problems deploying the game (devices that allow you to run Java apps don't necessarily allow you to run external native apps).

Of course, there's no AGS for making handheld adventure games. Ideally, there would be an engine that ran games on handheld devices, or failing that a library of classes useful for making an adventure game. However, the first few people to develop handheld adventures will probably have to do it from scratch.


Conclusion and Further Discussion
Dammit! I want some adventure games for my phone and for my iPAQ.

While I welcome discussion on any point raised in this post, I'd especially like to hear back on these questions:


  • Do you have any ideas for an adventure game interface on mobile devices?
  • Some sketches of backgrounds in a tall aspect ratio (say 200x320)
  • What would the business model for commercial handheld adventure games be?
  • If I, hypothetically, was to develop an adventure game for handhelds, would you prefer I wrote it in Java or .NET CF, or something else?
#285
Is there any reason at all why I should use GetGlobalInt() and SetGlobalInt() instead of just defining and importing ints in the global script and script header?

With GlobalInts it seems like it would be a huge hassle to keep track of what each one represented, and make sure not to use the same one for two different things.

Are they just a legacy feature since before AGS supported importing ints from the global script, or do they offer something more?

SMF spam blocked by CleanTalk