Messages

Thanks for your reply, Vince.

You've got a whole new set of possibilities, think outside the mouse-driven box.

Yep, that's what I'm trying to do ... I was just wondering what was, according to players' experience, the most convenient/efficient way to present the GUI and its interaction model.

I think I'll try some games on my iPad to analyze it further...

Thanks for your reply.

Indeed, "pixel perfect click" is not achievable anymore on touchscreens without "additional tools". "Tooltip" informations aren't available anymore too... (like in the following example)



So, the way we must interact with the tablet could potentially modify the logic and the gameplay... That's why I looking for some good advices before starting the initial work...

Thanks also for your suggestions. I played the flash version of Machinarium a long time ago... I'll give a while to the iPad version 

Hi,

It's been a while since I wrote a message on here... I'd like to discuss one aspect of adventure games.

I'm furiously thinking about making adventures games on tablet and mobile phones since several weeks but I'm facing big questions about the way to interact with the touchscreen. The traditional "point 'n click" GUI model is not applicable here. So I'm looking for some informations, design, reviews, testimonials and stats... in order to optimize the user experience for my "future" adventure game on these kinds of platform.

To be honest, I didn't take the time from now to buy and/or try some games on touch screen (for instance, buying Monkey Island I & II on iOS or installing scummvm on Android - maybe I should do this to make all clearer). I just watched videos about people recording their game sessions ...

What I note as typical interaction models are:

• single touch on the screen (the most evident one of course )
• touch and drag on the screen with the same finger (move the cursor positioning just above the player's finger position)
• touch and drag on the screen with two fingers (move the cursor positioning just above the first finger position with your other hand)
• touch the screen long enough to enable "pixel perfect touch" (a zoom window appears above the player's finger position)
• touch and drag on the screen with the same finger with automatic zoom window
• other ones... ?

What do you think about these solutions ?
What are the most efficient and/or convenient ones according to you ?
Are they really the best way to play adventure games on touchscreen ?

Thanks in advance for your help and your contribution !

Best,

Benco

Using the default Safari browser for iOS 3.1.2 on an iPhone 3G, the game runs at about half speed.

I've heard that Mobile Safari has been enhanced with iOS 4.3 but I don't know if the speed difference is that notable.

works great on my FF 4 beta 10 (win32)...

I have been wondering about attempting a really retro-DHTML renderer that doesn't need Flash or HTML5, just works with absolutely-positioned <img>s and <div>s and stuff. It wouldn't be able to do everything, but for a particularly simple game it might be enough. It's hard to imagine there are really that many people left who would benefit from it, though...

Of course, for special effects... canvas/flash is the only way to go. But I think the advantage of dhtml can be found in managing hotspots and areas (walking, interactive ...). Those one should be simpler to implement. And the algorithm for path-finding could thus be simpler too - but knowing that I was thinking about a specific html5/flash  editor too that would also generate some init data...

Crap, that is annoying. I suppose the solution is to do some (ugly) browser-sniffing and then ensure there's only ever one audio file playing at once...

I think the only solution would be in this case (and yep, you should snif the browser version/os version - not sure if it's inherent in webkit or iOS):
1) pause() the current sound
2) save the track position
3) put the position to the end
4) play the second sound
5) wait for the complete event
6) restore the position on the first track
7) play()

to test... (and knowing that it only works with two concurrent sound files only)

Cheers,

Benco

[VERY]

RickJ On HTML5:
HTML5 is VERY powerful indeed. I have very little doubt it could be used as a SCUMM interpreter or a platform for our AGS games.

Actually, there is already someone working on a SCUMM interpreter in JS (mostly based on the ScummVM code), proving it's feasible - I tested it and basically, it works

https://github.com/mutle/jsscummvm

First of all, as everybody said: Congrats ! 

You were the fastest ha ha  ... I was planning to make an adventure game engine in html5/js. I had begun collecting resources last year and AGS (that's still my favourite engine) was in my opinion the best candidate to analyse (api requirements ...) for my first experimentations.

I took a look at your js code. Indeed, it's a really incomplete engine but there are nice stuffs all the same (in my case, I wasn't planning to base all on canvas but also on imgs-areas-maps but it seems to rock anyway) !

Just about the music and sounds:

* On mobile safari, there is currently a bug that impede playing more than one sound file at the same time and I don't know when they plan to fix it
* I think when the new mozilla audio api will be popularised and used , it will allow playing more audio formats - a bit like new flash 10 stuffs allow now. And there are already experimentations done about Amiga MODs playing what is really awesome: you might take a look at the dynamicaudio.js library and the jsmodplayer project on github, it's really interesting

Good luck with it all!