Messages

To me, his legs seem too short in proportion to his torso.

[Edit:]

I added the bit after "Edit" after you'd written your reply, so no wonder you didn't see it!

In order to instantly move your character from where it's at to somewhere else, it used to be:

character[EGO].x = ... ;
character[EGO].y = ... ;

(You need to fill in the numbers, of course.)

That's the way to do it in AGS 2.62. With AGS 2.7 (beta) I think it's a bit different, so if you're using that you should check up on it.

Changing the background image doesn't change the hotspots, I'm fairly sure. You'll have to do that explicitly. Use EnableHotspot and DisableHotspot. You can look those up in the help file that comes with AGS.

Edit: Your current predicament seems similar to this old thread. Unfortunately, the image link is broken.

I betcha that does allow intersecting walkable areas. Just draw them on top of each other. You see that each area is a polygon (a triangle, to be exact), and two areas are connected if they share a side. If you draw two areas that cover the same space, but don't share a side, you'll have overlapping, distinct walkable areas.

I don't think the areas genuinely have height. I think the editor just projects the "groundplan" up by a certain height, scaled by the same amount as the object scaling. That way, people working on it can get a better sense of the space they're defining, and set the scaling appropriately.

Of course, it's possible that the areas genuinely have height, and the engine is in fact projecting objects in 3D space onto the background. That would be kind of cool, and allow for easily extending it to 3D characters (as has often been discussed for AGS).

Bhup, see the edit to my last response. Regarding threads, yeah the two senses of the word are probably related.

[Edit:]

Nonono, a thread on a forum, a messageboard or a newsgroup is a discussion, like this. A group of messages where each response appears after the last. This thread is called "Can't move frames I want to animate to bottom left of screen".

Edit: Bhup, I'm reading this thread and trying to figure out what your problem is. It's giving me a headache. I really don't see where you can be going wrong, so the easiest thing might be to just demonstrate. I mocked up some incredibly crude pictures of the scene you describe, to show you how it can be achieved.

(Some people have been having problems seeing my pictures. If they don't show up in your browser, let me know and I'll see what I can do.)

Here's the background:


And here are the object sprites:


Put them all together and you get this:


When the guy picks up the sword and the rope, you just turn those objects off.

Now you need an animation for the guy throwing the rope:





(It's probably a good idea to make all of these equally big, because it makes it easier to position them, but I couldn't be bothered.)

When you run the animation, it will look like this:


Finally you need a picture for the rope and buoy:


This is what the picture looks like after the animation is over:


You'll need to turn off the old buoy object and turn on a new one for the rope and buoy once the throw is over, or change the sprite and reposition it.

Depending on what you want for hotspots and stuff, and differences between the animation you want and what I drew, you want to split up some objects into several, make more graphics for e.g. the boat, and lots of other things I haven't considered. This should give you the basic idea, though.

Those are good considerations, Snarky. But I believe that the walkbehind problem and the character problem can be worked around. How, I'm not sure, but I guess it would involve a hell of a LOT of trial and error.

I prefer to work it out in my head first before going off and trying it. 

The walkbehind problem I don't think you'll be able to get around, except as I described. It's a fundamental property of 2D images. However, there's no reason why a workaround of turning all walkbehinds into objects wouldn't work.

I didn't know 3D rendereds could render like that! Could you please give me an example of one, so I could check it out, maybe get this thing off theoretical ground? I used Blender once, but I don't remember the ability of rendering like that (not that I was even looking, tell the truth...)

I haven't used it myself, I've just seen people create images like that with 3D renderers.

If it doesn't support it internally, you could just render the image twice from two slightly different points of view (right next to each other), tint one of the images green and the other red, and merge them together.

Don't many 3D renderers support an option of rendering in this way? If so, just use 3D-generated backgrounds. I also think it wouldn't be that hard (comparatively speaking) to make a Photoshop filter which allowed you to take an image (or a layer) and generate an anaglyph picture for a certain distance. Then you could set different layers at different distances, and you'd get the "cardboard cutout" look Scuthbert is talking about. A slightly more advanced filter would allow you to set a distance gradient, which (with some work) would allow you to create complex 3D scenes.

I don't see why antialiasing would be a problem. However, what would be a problem is walkbehinds. You would have to do it for each channel separately, which means they would have to be stored separately and blended by AGS. Also, AGS would need to know how far the channels were offset, which is the same as knowing the distance to each point. At that point, you're actually doing real 3D, just an impoverished version of it. If you can do without walkbehinds (say use objects for all walkbehind areas) it might work.

I think there's a real risk that all characters that are supposed to stand on the ground will look either like they're floating in front of it, or sunk within it.

Another thing that might be worth pondering is the additional capabilities these devices sometimes offer. I mentioned using the microphone and the camera; some handhelds also come with GPS sensors, gyroscopes that can detect tilt, or perhaps most commonly, network connectivity. These features could be used to create context-sensitive games: how about a game which went down a different path if you traveled a certain distance while playing it? Puzzles that required you to shake the device?

I also had an idea for a business model: A company would give the game away or sell it cheaply, then charge people for hints. An in-game hint system would allow players to buy a clue when they get stuck. This would generate and send a coded text message to the company servers, which would respond with a text message giving the hint. The whole process would be transparent to the user, the hint would appear within the game.

The system might work because users are accustomed to text message services they have to pay for, and because actually connecting to the Internet to look up a walkthrough would also cost them money, as well as take them out of the game. Also, reading long documents on a cell phone is unpleasant.

And no, your avatar does not show either. Not even in a new window

Hmmm... I've logged on to the forums from different computers on the opposite side of the world, so I know it's not just locally cached or anything. On the other hand, Lycos did say something about hotlinking images. Does anyone else not see it? Maybe I should look for a different host.

Yes, but you see that is for already made games made
with pocketSCUMM, i want to put MY game on it made with ags...
(not to be rude..)

No, it's not about PocketSCUMM. It's about making original adventure games for handhelds. I used PocketSCUMM as a case study to investigate the possibilities and limitations of making and playing adventures on a mobile device.

I'm pleased that you're requesting this, because it demonstrates how there is a demand for a way to create adventure games for handhelds. However, this question has already been asked and answered when it comes to AGS. Unless someone ports Allegro or CJ finds a way to get away from the dependency, it's not going to happen. I think we should look for alternative solutions.

What i meant was that thread explains the downsides of pocket pc gaming (Different Resolutions etc)

Actually the PocketPC, specifically, avoids many of those problems. It has a known resolution that works great with classic VGA-style games, it can easily be tipped over, and it has both touchscreen/stylus and hardware buttons. I prefer to think of the issues as challenges rather than downsides. It is my firm belief that it is possible to create great adventure games for handhelds that play well and use the differences in the platform to their advantage.

In that case, better add a link to this thread.

[Helpful Hints Running Curse of Monkey Island]

One way to overcome the problem with not having a mouse over hotspot activated statusline (at least for touch sensitive screens) is to drag the stylus across the screen. When it is over a hotspot, the statusline would show its name.

Yeah, that doesn't work so good. The problem is that in order to drag the stylus around the screen, you first have to tap somewhere, which tends to cause something to happen (like the character starting to move around). Also, it seems like PocketSCUMM clicks on anything you drag the stylus over, because you can't find a hotspot without activating it.

The workaround is a "free look" mode where tapping and dragging just moves the pointer, and never registers a click. I mapped it to one of the keys, so when I pressed it I could look for hotspots, and when I pressed it again I could activate them. It's a bit tedious, though.

I think the verbcoin GUI would be great for a mobile. You tap on a hotspot, and the verbcoin shows up. You then tap whatever action you want to do.

Actually, the documentation indicates it's kind of fiddly:

Helpful Hints Running Curse of Monkey Island
1. Make sure to assign a button for Rt-Click in Options.
2. As usual, tapping the stylus acts as the Left-Click. Tapping
on an area of the screen that causes the cursor to turn Red means
that some action can be taken. To do that, hold the stylus at that
position until the Action Interface (also called the Verb Coin)
comes up. It will have on it a 'Grabbing Hand' to pick up, push or
use something, a 'Skull' to examine objects, and a 'Parrot'
to talk to, eat, drink, taste, blow, or bite. AT FIRST, IT WILL
SEEM TRICKY USING THE VERB COIN- the best way is to hold the stylus
on the screen until the Verb Coin appears and then, without taking
the stylus off the screen slide it over the Hand, Skull or Parrot,
then withdraw it.

As for keypads, you could have the arrows move the characters around and the numbers (on the mobile at least) represent different actions, such as talk, pick up, etc. To perform an action on something, you would have to go up to it using the arrow keys, and then press the appropriate number. Admittedly, "looking" at something would be hard. Perhaps when someone clicks the look button, the game will pause and a pointer will come up which can move with the arrows. You move it over what you want to look at and click the look button a 2nd time.

Yeah, that could work.

I really think forcing the point-and-click style interaction on devices that don't have a mouse is wrong-headed. Devices with button controls should have keypress interactions (like you describe), devices with a touchscreen should take advantage of that, and so on.

About the playlength, yeah, they would have to be pretty short, easy games to hold the players attention, and to be playable in comparitively short lengths of time.
By the way, the 1st pic in your post (presumably of a pocketPC with an adventure game) is not showing up

Hmmm... I can see it. Does my avatar (a toothy grin) show up for you? Can you open it in a separate window?

If the company does such a thing, snarky, the game will be removed at once.-

Dude, Vivendi isn't going to come out and say "We don't want people to distribute the old Larry games because it shows off how bad the new one is". However, if that's the case then you are hurting the copyright holders.

Yeah, in most cases the companies probably don't care. However, abandonware is not in general a victimless crime.

I still download old games that I can't buy. If the company won't sell it to me, I frankly don't care if I'm hurting their business strategy a tiny bit. But I know that it's not legal, and I don't pretend that it should be.

[Handheld Platforms]

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?

(It is kinda like listening to a CD-player in public, or borrow a friend a CD or a movie. Both are illegal in terms of copy-rights. Listening to a CD in public (without head-phones) is considered public broadcasting - something only radios are permitted to do. And borrowing something to a friend is distribution - if your friends want to see a movie or listen to a record or play a game, he MUST (according to the laws) BUY IT!)

I'm not entirely surprised to see that your beliefs about copyright law are completely inaccurate.

Loaning a CD to a friend is not illegal. As long as it's not being copied, the CD can be transfered around as many times as you like. How do you think libraries can have a CD section?

You say that abandonware is not hurting anyone. However, a company might have good business reasons for not allowing an old game of theirs to be distributed. For instance, they might want to release a version on (say) a mobile phone in the future, and therefore not want people to have played it for a long time. Or they might reason that it competes with other games they're selling. Or they might believe that it hurts their brand name (because of its nature or its quality). Or they might feel that allowing people to get one game for free makes us expect to get all games for free, and therefore encourages warez. Or they might be planning a compilation. Or have a licensing deal in the works that might be jeopardized if they're perceived to not be able to control their properties.

There are a hundred ways in which abandonware can hurt the copyright owners. Pretending anything else is lying to yourself.

Thank you for the link, Babar. Just in case Evil doesn't stumble upon this thread, I'll PM him about it.

Doing the perspective effect itself seems simple enough, both to work out the formula and to do the mapping.

I'm sorry, but I don't quite understand. I mean, I can understand doing that for a single image, but not for umpteen images... which is probably not what you meant, anyway. I get the feeling you have a solid idea of how to do it, though. Could you please expand?

I meant the task of implementing a panorama lense filter. Weren't you asking whether it would be feasible to add something like that to AGS? The math and coding required to transform suitable images into a nice rotating panorama is not hard. (Of course, whether it would be hard to add it to AGS is a very different question.)

I have no idea how difficult it is to draw backgrounds that look right with the panorama distortion. Many people have difficulty with regular perspective, so I'm sure it would be a challenge. I was pretty much assuming that you'd use 3D rendered backgrounds to get around this problem.

Good job with the addition, Rich! 

I think I've experienced this a couple of times before, though I didn't comment. One time the information was in some other documentation (a tutorial or a help file), not the BFAQ. The other time it was there, but as part of an answer to a completely different question, so a newbie probably wouldn't have found it. Saying it happens "a lot" was probably an overstatement.

As the lip sync is linked to the speech files, if a translation is in use the speech won't play, so neither will the lip sync.

If a translation is in use, speech won't play? Hmmm...

Might not some people want to play a game with the speech in the original language, but with translated text? That way it would be like a subtitled foreign movie, which would arguably be better than no speech at all (and potentially really good for people who're learning a language).

No, the effect cannot be achieved with a static image.

Have a look at some VR Panorama pictures to observe how it works. Different parts of the picture are stretched and scaled differently, somewhat like a "pinch" deformation around the centre. (The word you're looking for Rui is "vanishing point".)

Doing the perspective effect itself seems simple enough, both to work out the formula and to do the mapping. There are probably other issues you'd have to deal with too, though.

I don't really care for the first-person POV, and making it 360-degrees just makes it worse. However, I think it could be a cool effect for third-person games. (Did QFG5 do this, or did it just scale and move the background around?) Of course, then you'd have to transform the character, walkable areas and walkbehinds as well as the hotspots.

Snarky -> it's not what you think. There isn't any actual relationship between these projects, save for the coincidence that I am involved in both of them. Actually I am one of the few people to be involved in both, despite both teams being 8+ people.

What made me think it was that the page for this new game had all these quotes that referred to KQ 2.5.

If you need some replacement statements for ATOTK, I can repeat mine:

"Nice!"

Oh, so this game is "abandoned", is it? That's a shame!Ã,