1 Topic by mardy

  • mardy
  • AlwaysBall
  • Offline
  • Registered: 2011-06-29
  • Posts: 21

Topic: Improving game experience on a mobile device

Hi all!
  I'm porting neverball to the Nokia N900, and among some technical difficulties with the porting itself, I found some other issues that affect the gameplay (due to screen size and different input: accelerometer and touchscreen). I should say that I just recently found neverball, and I played it only briefly on a desktop; so, it may be that some of the points are also valid for the desktop.

  • Accelerometer input: when controlling the floor with the accelerometer, it's practically impossible to hold it completely still. As a result, the ball is also always moving, and this causes the gameplay to be extremely difficult. After the 5th level in the easy mode, the gameplay becomes really difficult already.
    My initial attempt at solving this issue has been changing the accelerometer input function so that instead of reporting the angle itself, I report a non linear function of it (such as x^3), so that variations of the device angle around the 0 value produce a very little change in the game stage. This helps in having the stage more stable, but the game does not become more playable, because the ball is still very difficult to control.
    I think that a better way to solve this is to introduce a friction with the floor (well, I guess it's already there), so that the ball would stop soon when the floor is horizontal -- but we should make it so that high speeds are still possible, by continuing to hold the floor tilted. I believe this should be possible, without preventing any game level from being completed because of this changed physics.

  • Accelerometer calibration at the beginning of every level: we could add a function to tilt.h which would be called right before a level starts, so that the tilt implementation would save the current values as "horizontal floor". This would allow the player to play the game holding the phone in his favourite position.

  • Camera: the default camera makes the game very hard to play; as soon as you hit an obstacle the camera might turn, and this causes the accelerometer input to be mostly unpredictable. I'm not sure how to solve this. Maybe a fixed camera would be better, and we could use touchscreen gestures to let the user move it left, right, up and down.
    Another option is to have an automated camera similar to the current "chase" mode: it would behave in "chase" mode for high speed, while for lower speeds it would raise (and be almost vertically on top of the ball for low speeds, when most precision is needed).

  • Easier levels: it would be nice to have some very simple levels where there is little precision involved, just a lot of running. :-)

  • Bigger GUI elements. Some widgets (as the level selector buttons) are really hard to tap without a stylus.

  • Better touchscreen support. Without mouse, we don't have the "hover" functionality: therefore, when selecting levels, it's now impossible to see the level screenshot. Maybe a two-phase level selection would do: first you tap on the level number (and this causes the right screenshot to be displayed), and then press a "Start" button to begin the game.

I'll try to address these issues in my N900 port; if you think this can also be beneficial to have in the master branch, please let me know. Comments welcome! :-)

2 Reply by nue

  • nue
  • nue
  • OccasionallyBall
  • Offline
  • From: Vienna, Austria
  • Registered: 2005-05-19
  • Posts: 555

Re: Improving game experience on a mobile device

As an experienced NB player I had little trouble with the accelerometer (on the Android beta version).

Howerer, even with the mouse and on the computer, NB is a difficult game to play in the sense that you need fine motorics and many tries. This may severely limit its usefulness for mobile devices (since it will never be a game which you can play, eg., in public transport).

Still, I don't feel that changing the physics (which have traditionally been a strong point of NB) would be a viable way to "make the game easier thus more mobile-friendly". On the other hand, your suggestion of a suite of levels with less geometry and which are also easy enought to play for a beginner on a mobile device would be an interesting option (provided there is someone willing to make them!).

Apart from that, I agree. It would, however, be preferable if the changes in appearance and behavior could be limited to the mobile version (I'm not sure what you suggested) .

3 Reply by gjtorikian

  • gjtorikian
  • OftenBall
  • Offline
  • From: San Francisco, CA
  • Registered: 2010-04-26
  • Posts: 112

Re: Improving game experience on a mobile device

I'd like a chance to respond as I've been trying to put out a (playable) Android port for months now:

Accelerometer: I'm not much of (any more) a math person, so I'd be very interested in any solutions you come up to this. To be honest I did not find the "frictionless" play to be too difficult, since, just like the computer version, it requires you to tilt the floor. A lot.

Bigger GUI elements: I've replaced every instance of GUI_SML with GUI_MED, because the text was too small. I also took out all the "Back" buttons, since on Android there's a dedicated button for it. Finally, I took out a lot of unnecessary options, like Fullscreen, changing Resolution, or entering your username (I base it on a user's gmail username).

Better touchscreen support: I think the solution for this is to tap once to select, and twice to confirm, rather than add a new button (think of it as a double-click). But, maybe you're right--the Start button could highlight once a level has been selected.

Right now my biggest problem is getting unplayable levels playable, and I'm stuck. In other discussions there have been suggestions to reduce the map sizes; and, like you, I tried to reduce the UPS value, to some limited success. Do you have any videos or screenshots?

4 Reply by mardy

  • mardy
  • AlwaysBall
  • Offline
  • Registered: 2011-06-29
  • Posts: 21

Re: Improving game experience on a mobile device

gjtorikian wrote:

Right now my biggest problem is getting unplayable levels playable, and I'm stuck. In other discussions there have been suggestions to reduce the map sizes; and, like you, I tried to reduce the UPS value, to some limited success. Do you have any videos or screenshots?

Here's a video which a took a few days ago:
http://www.youtube.com/watch?v=IIRx1bELrWY

It's from the gles branch (which, as I wrote in another thread, for me is 4 times faster then the trunk), shadows set to 0, textures set to 2, mipmap to 1 (IIRC; unfortunately I deleted my conf).
Later I wrote this patch, which delivers a similar performance with textures = 1 (and now the texts are much nicer to read); not that the patch works only with textures = 1, because the image_scale function has not been adapted to work on 16bpp.

5 Reply by gjtorikian (edited by gjtorikian 2011-07-12 21:22:40)

  • gjtorikian
  • OftenBall
  • Offline
  • From: San Francisco, CA
  • Registered: 2010-04-26
  • Posts: 112

Re: Improving game experience on a mobile device

Could you describe specifically your experience with Level 4 of the Easy set? There's some problem with chrome textures and playing on the GL ES device--I can't remember which thread it was discussed in, but I can dig it up if necessary. Edit: also, I am running off the trunk branch, and couldn't find any performance change.

I guess I ought to start putting my code online, too...

6 Reply by parasti

  • parasti
  • Developer
  • Offline
  • From: Latvia
  • Registered: 2005-06-18
  • Posts: 3,845

Re: Improving game experience on a mobile device

Chrome textures look wrong because the sphere mapping effect has not been reimplemented. In the OpenGL ES thread rlk has laid out a solution for that, I just haven't attempted to tackle it.

7 Reply by gjtorikian

  • gjtorikian
  • OftenBall
  • Offline
  • From: San Francisco, CA
  • Registered: 2010-04-26
  • Posts: 112

Re: Improving game experience on a mobile device

parasti wrote:

Chrome textures look wrong because the sphere mapping effect has not been reimplemented. In the OpenGL ES thread rlk has laid out a solution for that, I just haven't attempted to tackle it.

Right, I remember that post: http://forum.nevercorner.net/viewtopic. … 009#p25009

I was just wondering if mardy was hitting the same specific play issues.