[games_access] one switch bejewelled

Eelke Folmer eelke.folmer at gmail.com
Fri Mar 7 14:12:03 EST 2008

Hi Richard,

Sorry for my late reply, Thanks for the feedback! The cancel option
is definitely worth considering. I think the original bejewelled doesn't
switch jewels if they don't clear a row. Ours just switches it. We could
implement a cancel option though if you make a mistake you can just click
"through" without any consequences, which i think is faster (that is if we
don't switch the jewel if it doesn't clear a row). I would like to make this
mechanism as agnostic as possible. In that case we could potentially just
place it on top of an existing game interface and just put through mouse
clicks so we don't have any dependencies to a particular game, not sure if
that would work though.

Do you have any links to the one switch tetris/ arkanoid/ platformer? I'm
currently writing a paper on our "rotate and extend" mechanism and it would
be nice to discuss these under related work. I already have dimitri's chess
+ invaders.

One spot for one switch prototypes could work: I could add to that
- 1 switch fps (halflife)
- 1 switch secondlife
- 1 switch TBS (sid meier's colonisation)
- 1 switch RTS (mechwarrior 2) ( in development)
- 1 switch monkey ball (neverball: in development)
- 1 switch racing game (tuxracer: in development...this is really hard)

Cheers Eelke

On 01/03/2008, AudioGames.net <richard at audiogames.net> wrote:


> Hi Eelke,


> Great experiment and glad to see the differences (in selecting the gem to

> move - phase 1) and the similarities (in selecting the gem to both the

> initially selected gem to - phase 2) of both solutions. Will send you the

> statistics file later on.


> In short: I immediately liked the second one better, because it felt more

> natural and seemed to be a bit quicker (?). Also, I found the blue arrow

> more clearer than the red selection bars in solution one (although this can

> be fixed with graphic design of course). I could easily play the game with

> both solutions, so both work very well in that respect. One suggestion you

> might want toy around with: I find Bejewelled a simple kind of Puzzle

> Game in which players (well, at least I) don't make many mistakes - you

> basically scan where you see a possible move and when spotted, you execute

> that move. So as long as you don't spot a possible move, you won't make a

> move. So with the thought in mind that when the player finally makes a move

> he or she already knows it CAN be made, you might want to add the

> option/feature that the computer only selects those gems to move to (so

> phase 2) that are possible. This will speed up the gameplay a lot I think

> and will not interfere much with the game's challenge.

> One other thing I just thought of: there is no solution yet for deselcting

> a gem during phase 1 when you accidentally select the wrong gem. In the

> original game, you simple click the gem again (I had it once while trying

> you demo). You could try adding some kind of solution for this, for instance

> a timer during phase 2 that deselects the gem after x amount of

> non-activity.


> Since I have some one-switch experiments laying around here as well

> (one-switch tetris (two different interaction mechanisms), one switch

> arkenoid (two different interaction mechanisms) and a one switch platform

> game (only one interaction mechanisms)), maybe we can set up a spot

> somewhere as a IGDA GASIG One Button Experiment Lab where we can add more

> stuff like this and maybe get more people inspired?


> Greets,


> Richard


> ps: sorry for never answering your Guitar Hero question related to our

> IEZA article. I started a reply but never finished it. We will try to answer

> it in full length in a follow-up article. But in short: the framework

> features 2 dimensions, from which 4 categories arise. But this is not the

> same as a cross-table. So a sound could very well border on two categories,

> a bit like so:



> There is more to this than I'll write now (like how can one sound be "more

> diegetic" than another), but expect our thoughts on this in a follow-up :)



> ----- Original Message ----- From: "Eelke Folmer" <eelke.folmer at gmail.com>

> To: "IGDA Games Accessibility SIG Mailing List" <games_access at igda.org>

> Sent: Thursday, February 28, 2008 10:08 PM

> Subject: [games_access] one switch bejewelled



> > hi,

> >

> > My student Tyler made a simple one switch bejewelled with two

> > different interaction mechanisms (scan & select / rotate & extend),

> > http://www.eelke.com/files/GEM.exe which you can download here. If

> > you'd like to help us with some research on which mechanism is better

> > please play the game using both mechanisms for a bit and mail us back

> > the file: statisticOutput.txt (please mail to oneswitch at eelke.com).

> >

> > Disclaimer: this is not a fully fledged game since we are only

> > interested in finding out which mechanism works best.

> >

> > Thanks Eelke

> >

> >

> > --

> >

> ----------------------------------------------------------------------------

> > Eelke Folmer Assistant Professor

> > Department of CS&E/171

> > University of Nevada Reno, Nevada 89557

> > Game interaction design www.helpyouplay.com

> >

> ----------------------------------------------------------------------------

> > _______________________________________________

> > games_access mailing list

> > games_access at igda.org

> > http://seven.pairlist.net/mailman/listinfo/games_access


> _______________________________________________

> games_access mailing list

> games_access at igda.org

> http://seven.pairlist.net/mailman/listinfo/games_access



Eelke Folmer Assistant Professor
Department of CS&E/171
University of Nevada Reno, Nevada 89557
Game interaction design www.helpyouplay.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://seven.pairlist.net/pipermail/games_access/attachments/20080307/ab23b75f/attachment.html>

More information about the games_access mailing list