Adventure Gamers - Forums

Thanks, I’ll check it out.

Intense Degree - 20 June 2012 07:55 AM

Generally I agree with others who have said that most of the list appear to be gimmicks only. I don’t have a DS or similar and therefore don’t have a lot of experience with shaking/turning/microphone/camera interaction but it doesn’t sound like anything more than an irritation to me personally. Millions may disagree with me though!

That’s one of the reasons I’m doing this survey - disagreements are natural when it comes to these things and of course, nobody HAS to use any of these things when developing an adventure. But some people will WANT to use them and I am trying to find out, which ones would be most popular.

Intense Degree - 20 June 2012 07:55 AM

I think that one of the problems is the the interfaces for “traditional” adventure games is pretty much established (although variable within a set of reasonable parameters) and some people will feel that when you add shaking/turning etc. it starts to drift away from “traditional”.

True, but the interface has developed over time. Compare for example the interface in Monkey Island 1 and 2 with that in Monkey Island 3 - both types of interface are usable, but they’re very different.

Intense Degree - 20 June 2012 07:55 AM

However, multi touch is a must for me as if one touch is a left click, two simultaneous touches are a right click.

This is true for ports of games from the PC. In developments specifically for mobile devices, it can be used for many, many more things.

Intense Degree - 20 June 2012 07:55 AM

You may already know this, but the free AGS engine for traditional adventure games is being ported to Android and PSP. [...]
It uses a “mouse cursor” which you drag around screen [...]. The guy doing the port may well be able to help you more on various things like this and you can get him at the above link on the AGS forums.

I didn’t know that, which is weird - I did search quite a lot before I started my project and should have found that. Well, I’ve downloaded the port and will test it later. Also, I’m going through the thread, maybe I’ll find useful information there.
The “mouse cursor” solution is similar to that used in the current android version of ScummVM (at least judging from your description) and again, it’s useful for ported games. They used to have the finger as the cursor and it was pretty difficult to use at times. If however games are developed directly for mobile systems, one can have an interface which works well without a cursor.

Anyway, thanks for the information, I’m sure it will be valuable.

Any other answers? The more I get, the better.

From what you’ve mentioned I think what holds the most possibilities when it comes to fun factor is multi-touch and the ability to tap things quicker and such more naturally than what you’re able to do with a mouse. This would be great for a wide array of puzzles and minigames.

Stuff like shaking the device might be fine for your phone, but would be incredibly annoying if you’re playing on a tablet, which most adventures are, I assume.

Henke - 29 June 2012 01:43 AM

To be able to “move” objects by pressing and draging (like opening a door or pulling a lever) is the most important aspect an adventuregame should have when played on a touch screen IMO.

That should be available, you’re right. Of course, only if the game designer chooses to use that. ^^

Henke - 29 June 2012 01:43 AM

The ability to zoom in a scene is also important since we’re talking about smaller screens.

Agreed, thought that again depends on the developers - not all rooms should be zoomable, I guess.

Henke - 29 June 2012 01:43 AM

An engine like this is just what I’m looking for so I’m following this with great anticipation.

I’ll keep you informed. It’ll probably be a few months though, so you’ll have to be patient. ^^

Kasper F. Nielsen - 29 June 2012 03:28 AM

Stuff like shaking the device might be fine for your phone, but would be incredibly annoying if you’re playing on a tablet, which most adventures are, I assume.

It probably would be, yes. One suggestion I’ve had is, that you can switch the input methods, maybe even set up input profiles. So, if you’re playing on a tablet the input could be slightly different from when you’re playing on a smartphone. Shake your milkshake by rapid finger movement instead of shaking the whole device. Stuff like that.

Thanks for the input, it is greatly appreciated.

I’m not sure I’m any help at all now, but my answer is - none.
Those are nice features, but they limit game’s porting possibilities. And for me its kinda important that the game could be made easily for other platforms.

Building up on other’s ideas:
- zooming - yes! important if there are details! not sure pixelhunting is pop today.
- interface - imo interface should be easy, fast, work on most platforms (with minor nuances, but point remains). Thats the challenge i would try to find a solution first, as gameplay circles around that.

lewuz - 04 July 2012 01:55 PM

I’m not sure I’m any help at all now,...

You are.

lewuz - 04 July 2012 01:55 PM

...but my answer is - none.
Those are nice features, but they limit game’s porting possibilities. And for me its kinda important that the game could be made easily for other platforms.

True, porting to devices other than smartphones and tablets does become much more difficult when using that kind of thing. On the other hand, I think that the future of gameplay lies in devices with a range of sensors at least similar to what I mentioned above. The Wii was a big hit (which uses motion sensors), the Nintendo DS was quite successful (which uses a touchscreen) and the Kinect is way more powerful when it comes to alternative controlling mechanisms than any phone or tablet.

Admitedly, there haven’t been many adventures for those platforms, but that may partially be because both the Wii and the Kinect require a lot of movement (which doesn’t make that much sense in an adventure) and the DS is difficult to develop for if you don’t work for a big games company. With Android and iOS however, anyone can make games.

lewuz - 04 July 2012 01:55 PM

Building up on other’s ideas:
- zooming - yes! important if there are details! not sure pixelhunting is pop today.
- interface - imo interface should be easy, fast, work on most platforms (with minor nuances, but point remains). Thats the challenge i would try to find a solution first, as gameplay circles around that.

Zooming certainly, I didn’t list that in the original post but it will be in the engine. Guaranteed.

The interface is a challange of course, because there’s little to build on. As the screen size is limited the interface should take up as litte space as possible while still being easy to use.
The portability within the area of smartphones & tablets shouldn’t be to much of a challange (both in the area of code and interface transfer), more so when it comes to regular computers. However, at least at first, I won’t create a port for Windows (or Linux, or OS X, or…) so those platforms are of lesser concern to me. (The project will be open source however, so if anyone else want’s to port it they’re welcome to do so.)

Regarding interface… well, i have no idea whats your concept but my personal preference would be: find hotspot>click/tap>choice of commands (as less as possible,1-2, max 3). Otherwise I would keep screen just for the game. But i dont know is it doable with your project.
If u have inventory bar (dont make separate screen like eg in Runaway), that can be brought up with slide.
Basically - like its been in adv for a while.

Yes, that’s pretty close to what I was thinking. But even so, it can be done well or it can be done badly - and of course, I would prefer if it’s done well.

The basic idea is, that you have the whole screen for the room and in the corners there are buttons (inventory, settings, sound on/off, custom button which could open a map or something). There would also be a seperate interface for dialogues (making the text as readable as possible, though of course recorded dialogue is possible) and a highly modifiable interface for “special” rooms (minigames, closeups, etc.). And yes, the inventory would (normally) be a bar, though I might offer a seperate screen as an alternative, if the game developers really want that.

Tapping on something (with one finger) will either have the character walk there (if there’s nothing else in the area), open a choice of commands, e.g. on a disc, or somehow interact with an item (for minigames, opening doors, stuff like that).

The multitouch interface should be pretty intuetive - pinch zoom is a must, manipulating (e.g. turning, moving, stretching,...) items should be pretty easy to understand. Doing stuff with several items at a time should also be understandable. But one big problem with Multitouch is, that even within multitouch devices there are variations. Some can detect only two, some five and others ten fingers at once. Of course, as you want to limit your pool of potential players as little as possible, all puzzles with multitouch will have to use either a maximum of two fingers or offer an alternative - which again is probably part of the interface in some way. Well, we’ll see.

How far do you plan to take this engine? Just make a first release for school purposes, or actually make it properly useable for making games with? And what language will the scripting be in? LUA, something custom?

Well, the first release will be mainly for university purposes, but I do intend to continue developing it so that it can be used properly. After all, the main reason I decided to create the engine in the first place is that I want to be able to play adventures on these devices. And yes, LUA is the language I’m currently aiming for.

Licence wise, it will be published under an open source licence which permits commercial use. So, you can use it for free and earn money with your games, if they’re good enough. ^^

For small-time developers it’s always nice with the engine being free, so you’re not royally screwed if your game doesn’t become profitable, and if it does become profitable you can always thank the engine-makers with donations afterwards :-)

Looking forward to following the development of this engine, and might try to develop something with it once it’s ready for use.