Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (0)
to General by Kalatti - 2 days, 9 hrs ago -
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 4 days, 6 hrs ago -
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 5 days, 3 hrs ago - more...
| The Following User Says Thank You to qgil For This Useful Post: | ||
|
2009-11-19
, 12:43
|
|
Posts: 341 |
Thanked: 607 times |
Joined on Dec 2008
|
#32
|
Originally Posted by qgil
Hm, my gut feeling was that tapping on any illegal square should cancel the move. But failing that, I think that after a square/piece is selected, the entire area outside of the board should be blurred, and allow to cancel the move by tapping on it.
At this very point of time we need more work on interface / interaction design than pure graphics design. Although if someone provides better graphics than the ones currently in use we won't reject them.But the app looks ok already.
For instance, how does the Settings page look like? How are we going to organize the Menu options? Nobody knows for sure today and it would be good to have someone able to play with Qt Designer or at least faster than me producing purely visual mockups for discussion.
There are Miniature builds that run on the Maemo 5 SDK, the N900 and the Ubuntu desktop. Give them a try, any proposals for improvement are welcome in any form!
Another example: hopefully one of these days Miniature will learn the legal moves, and therefore will be able to identify the illegal. How should they be reflected in the UI? My current assumption is:
1 - User selects a piece with one tap. Piece shows highlighted.
2 - User selects destination square with a second tap.
3 - Destination square turns red with some transparency for 0.2 seconds.
4 - Original peace is still selected and highlighted.
5 - Repeat 3 if user selects a wrong square again.
mikhas and I were also discussing a reversed mode of entering moves earlier. First you tap on the target square, then all pieces which can move to this square (if any) are highlighted. Tapping closest to any of the highlighted pieces would move it to that square. The idea is that it's harder to make a mistake with the second tap, and you don't necessarily need a third tap for confirmation (also it can still be tricky if many pieces are close to each other and can move to the same square).
| The Following User Says Thank You to kanishou For This Useful Post: | ||
|
|
2009-11-19
, 13:00
|
|
Posts: 341 |
Thanked: 607 times |
Joined on Dec 2008
|
#33
|
Originally Posted by qgil
I would personally sort this differently, into just four possible outcomes, and an optional "reason". E.g.:
I went through my current task of defining possible game endings. I was amazed about the amount of possibilities!
Please check whether you still miss a potential game ending at http://wiki.maemo.org/Miniature/Deve..._after_a_match
An opportunity of contribution for native English speakers (or equivalent) with a clue of chess: proposals for text strings accepted. The shorter the better. The more chess standard vocabulary used the better. Let's make life easy for translators.
* White/Black Wins
- Checkmate
- Resignation
- Time
- Lost connection (if noescape flag is set)
* Draw
- Draw agreed (does it matter who requested it?)
- Threefold repetition (don't forget three times the same position)
- X moves without captures
- Stalemate
- Insufficient material
* Aborted
- Abortion agreed (does it matter who requested it?)
- Insufficient moves (quitting or disconnecting the game before X moves are played, freechess will abort the game instead of resigning/adjourning)
* Adjourned
- Adjournment agreed (does it matter who requested it?)
- Connection lost
There is also the possibility of a game being decided by a referee (adjudication), but I don't think that the interface has to be aware of this.
Also a quick note regarding accept/deny confirmations. Whatever you do, do NOT show a modal dialog, or otherwise interrupt the player's move or even concentration. Agreeing or denying must be possible at the player's leisure. It's much better to miss a draw request by making a move before answering it, than to be disrupted in your move and possibly losing on time (let alone opening the door to abuses).
 |
|
2009-11-20
, 21:54
|
|
Posts: 3,105 |
Thanked: 11,088 times |
Joined on Jul 2007
@ Mountain View (CA, USA)
|
#34
|
Originally Posted by qgil
http://wiki.maemo.org/Miniature/Development/Strings created. I believe the use cases of Phase 1 are all covered, and even a little more. Or do you miss anything?
An opportunity of contribution for native English speakers (or equivalent) with a clue of chess: proposals for text strings accepted. The shorter the better. The more chess standard vocabulary used the better. Let's make life easy for translators.
How is the engine progressing? Is Miniature starting to learn some proper chess?
What about teaching only about the first move of the pawns? The logic can't be simpler, and once implemented we can start experimenting with the UI around the move of pieces, legal/wrong squares and so on.
 |
|
2009-11-21
, 06:00
|
|
Posts: 805 |
Thanked: 440 times |
Joined on Aug 2009
@ Mississauga, On
|
#35
|
I've been away for a bit due to some personal issues, but I'm back! What artwork can I help out with?
|
|
2009-11-21
, 08:03
|
|
Posts: 3,105 |
Thanked: 11,088 times |
Joined on Jul 2007
@ Mountain View (CA, USA)
|
#36
|
kore is teaching Miniature to play some chess:
http://gitorious.org/miniature/minia...13536f62e2e187
Now the pieces are supposed to know how to behave alone. The next step is to make them interact with each other correctly. kore explains more at
https://garage.maemo.org/pipermail/c...er/000072.html
http://gitorious.org/miniature/minia...13536f62e2e187
Now the pieces are supposed to know how to behave alone. The next step is to make them interact with each other correctly. kore explains more at
https://garage.maemo.org/pipermail/c...er/000072.html
|
|
2009-11-21
, 08:11
|
|
Posts: 3,105 |
Thanked: 11,088 times |
Joined on Jul 2007
@ Mountain View (CA, USA)
|
#37
|
Originally Posted by joshua.maverick
Good to see you back:
I've been away for a bit due to some personal issues, but I'm back! What artwork can I help out with?
See my post above: http://talk.maemo.org/showpost.php?p...8&postcount=31
Artwork in the sense of icons etc is not a big need anymore.
Can you also design animations? What about defining a nice effect for the selection of pieces and squares, and for the movement of pieces? I guess it's ok to discuss proposals over Flash or SVG, but the programmers might have better tips for you.
Check the wiki page for current screenshots and binaries you can install in the SDK, the N900 or Ubuntu, with all the current graphics available. Ask here if you need more information to get the source graphics.
| The Following User Says Thank You to qgil For This Useful Post: | ||
|
|
2009-11-21
, 08:18
|
|
Posts: 805 |
Thanked: 440 times |
Joined on Aug 2009
@ Mississauga, On
|
#38
|
What format would the animations have to be in? I can animate in Flash np, but I what should I output as?
| The Following User Says Thank You to joshua.maverick For This Useful Post: | ||
|
|
2009-11-21
, 16:31
|
|
Posts: 148 |
Thanked: 199 times |
Joined on Nov 2009
|
#39
|
Originally Posted by joshua.maverick
Yeah, difficult question for us. So far we tried to keep everything scalable. I am not sure how well animated SVG would work for us; we'd have to extend the Webkit hack we currently use (since QtSvg is not very capable).
What format would the animations have to be in? I can animate in Flash np, but I what should I output as?
How is proper scaling for different resolutions approached in the Flash world?
|
|
2009-11-21
, 16:40
|
|
Posts: 341 |
Thanked: 607 times |
Joined on Dec 2008
|
#40
|
Originally Posted by mikhas
Flash is vector based, so it's just the same as with animated SVG.
Yeah, difficult question for us. So far we tried to keep everything scalable. I am not sure how well animated SVG would work for us; we'd have to extend the Webkit hack we currently use (since QtSvg is not very capable).
How is proper scaling for different resolutions approached in the Flash world?
The way it's done in Fremantle is that designers produce flash mockups and instructions, which the programmers then manually turn into Clutter effects. I don't know if Qt GraphicsView has any ready-made format for defining animations?
| The Following User Says Thank You to kanishou For This Useful Post: | ||
For instance, how does the Settings page look like? How are we going to organize the Menu options? Nobody knows for sure today and it would be good to have someone able to play with Qt Designer or at least faster than me producing purely visual mockups for discussion.
There are Miniature builds that run on the Maemo 5 SDK, the N900 and the Ubuntu desktop. Give them a try, any proposals for improvement are welcome in any form!
Another example: hopefully one of these days Miniature will learn the legal moves, and therefore will be able to identify the illegal. How should they be reflected in the UI? My current assumption is:
1 - User selects a piece with one tap. Piece shows highlighted.
2 - User selects destination square with a second tap.
3 - Destination square turns red with some transparency for 0.2 seconds.
4 - Original peace is still selected and highlighted.
5 - Repeat 3 if user selects a wrong square again.
However, discussing UI without mockups is slow and prone to fail due to different people drawing differently in their minds even if reading the same text. I can play with GIMP / Inkscape but I'm damn slow. I have the ideas and some skills to express them in text fast, but beyond that...