Intro

El Xcrabble es una reimplementación con la librería gráfica Gtk - Gimp Toolkit - para la asignatura de Interacción Hombre Máquina del Scrabble, un juego en modo texto, realizado en Laboratorio de Programación en Ada.

El Scrabble es un juego de palabras cruzadas para 2,3 ó 4 jugadores. El juego consiste formar sobre el tablero palabras que se crucen entre sí, al igual que en los crucigramas, haciendo uso de fichas marcadas con una letra y un número. Cada jugador trata de conseguir el mayor numero de puntos posible, colocando sus letras de manera que obtenga la mayor ventaja de los valores de las letras y de las casillas con premio que hay encima del tablero.

El juego original funciona en Unix en modo texto. El objetivo es que el rango de jugadores se amplíe. Al estar desarrollado en modo texto hace que resulte atractiva a poca gente. Al estar desarrollada para Unix hace que su audiencia sea escasa. Ahora que se permite la utilización de elementos gráficos, se pretende acercarse lo más posible a lo que es jugar una partida en Scrabble, tanto en el color del tablero, las fichas, marcador etcétera, como en movimientos intuitivos con el ratón, en vez de tener que escribir las palabras con el teclado, como era obligado en la versión modo texto, que no utilizaba para nada el ratón.

Análisis del producto

En nuestro caso en particular cuando ya hay un concepto para el producto, y una buena idea sería empezar con el resumen de que es lo que ya está decidido. Cuando no tienes idea del producto probablemente sea mejor empezar con el análisis de usuarios y actividades para obtener ideas de las necesidades del producto.

Cómo se ha utilizado USERfit. La ruta a través de la metodología:

Análisis del producto (PA) 2003-08-12
 |
Contexto ambiental (EC) 2003-08-13
 |
Ambiente del producto (PE) 2003-08-13
 |
Descripción de grupos implicados (UA1) 2003-08-14
Lista de escenarios de grupos implicados (AA1) 2003-08-14
 |
Atributos de los grupos implicados (UA2) 2003-08-14
Resumen de elementos de actividad (AA2) 2003-08-14
 |
Resumen de requisitos de actividad (AA3) 2003-08-17
 |
Análisis del producto (PA) 2003-08-17
 |
Matriz de atributos del producto (PAM) 2003-08-18
 | 
Resumen de requisitos (RS) 2003-08-18
 |
Resumen de diseño (DS) 2003-08-18
 |
Estrategia de evaluación total (UE1) 2003-08-20
 |
Plan de evaluación (UE2) 2003-08-22
 |
Resumen de la evaluación de facilidad de uso (UE3) 2003-08-22

Como una idea bien definida del producto existía y los desarrolladores adaptamos un juego ya existente, se decidió empezar con el análisis del producto (PA), y entonces clarificar que era conocido sobre como el producto sería usado y el ambiente en el que operaría. Después de que las herramientas contexto ambiental (EC) y el ambiente del producto (PE) fueron usadas, se decidió a mirar más detalladamente los atributos de los usuarios del producto (herramientas UA) y las actividades que tendrán lugar (herramientas AA).

Como resultados del análisis hubo algunas redefiniciones de lo que el producto debía hacer, así que la herramienta de análisis del producto se utilizó de nuevo. La especificación emergente fue chequeada contra los atributos deseados que salieron del análisis de usuarios y actividades, con la matriz de atributos del producto (PAM), y después de la discusión la especificación fue revisada y documentada en los resúmenes de requisitos y diseño.

Al mismo tiempo se discurrió la estrategia de evaluación y los consiguientes planes de evaluación. Esto se documentó con la herramienta de evaluación de facilidad de uso (EU). Los resultados finales se documentaron con la herramienta del resumen de la facilidad de uso (UE 3).

Análisis del producto (PA)

Fecha:

2003-08-12

Descripción del producto o servicio: Xcrabble. El juego del Scrabble en Gtk.

Especificaciones amplias/objetivos de diseño, análisis razonado, operación detallada, acciones necesarias:

• Juego secuencial modo texto diseñado para su utilización en entornos Unix con XWindows, extenderse a otras áreas, incluyendo el uso por usuarios de Windows con una interfaz guiada por eventos, cómoda para usuarios menos experimentados, exploración de librerías Gtk y del código original.
• Interfaz autoexplicativo, útil para gente que quiere una operación simple, pocos botones y siguiendo el desarrollo natural del juego, especificar la interfaz.
• Carga automática del diccionario, el usuario no debe de preocuparse por como se carga el diccionario, carga del diccionario al seleccionar nuevo juego, conseguir el diccionario.
• Indicador del estado del juego, se debe saber que jugador está jugando, mostrar mediante indicadores gráficos como labels, estudiar el reparto de turnos entre los jugadores del juego original.

Resultados y siguientes pasos

El análisis del producto ha revelado el número de decisiones de diseño que ya están hechas, y que el concepto era tener una interfaz de usuario moderno y adecuado. Esto permitirá una difusión más amplia, y un juego más agradable. Las limitaciones técnicas como nuestra falta de habilidad con la librería tendrán que solventarse observando ejemplos. También se decidió dar una breve lectura por encima a todo el código.

Contexto ambiental (EC)

Fecha: 2003-08-13

Descripción del producto o servicio: Xcrabble. El juego del Scrabble en Gtk.

Preguntas iniciales, detalles, temas que requieren atención, acciones necesarias.

• ¿Cuál es el producto/servicio?, el juego del scrabble, conocimiento del juego,coger experiencia jugando al scrabble.
• ¿Cuáles son las necesidades del producto/servicio?, parece una buena idea que los usuarios de Windows puedan utilizarlo, utilizar una librería gráfica que funcione en Windows, configurar el Windows para que funcionen los caracteres de escape vt100, se requieren privilegios de administrador.
• ¿Dónde se originó la idea del producto?, en el Cps.
• ¿A quien se venderá o repartirá el producto? a los profesores de la asignatura de Interacción Hombre Máquina y a todos los que quieran jugar con él.
• ¿Cómo será usado? como un juego normal, con la posibilidad de instalar, chequear la disponibilidad de un instalador como el setupgenerator.

Resultados y siguientes pasos

Se ha clarificado que el producto debe ser usado al fin y al cabo por usuarios medianamente familiarizados con la informática, con cierto nivel cultural. A pesar de eso también nos hemos dado cuenta de que no teníamos tan claro como se creía sus usuarios potenciales. Sería necesario un estudio más detallado del mercado destino.

También se ha decidido jugar un rato con la antigua aplicación hasta familiarizarse completamente, y luego comentar la experiencia.

Ambiente del producto (PE)

Fecha: 2003-08-13

Descripción del producto o servicio: Xcrabble. El juego del Scrabble en Gtk.

Función, ¿quién lo hará?, ¿cómo se hará?, implicaciones de diseño, acciones necesarias.

• Necesidades de entrenamiento, desarrolladores, mediante la documentación en doc\ del paquete gtkada, leer lo necesario del manual de referencia.
• Documentación, con texto plano, después se pasará a html y doc, estudiar los documentos USERfit.
• Mantenimiento, los usuarios, con las utilidades de sourceforge, crear una cuenta en sourceforge.
• Soporte, ¿es esto necesario?

Resultados y siguientes pasos

Procedimiento de análisis de usuarios

Descripción de grupos implicados (UA1)

Descripción del producto o servicio: Xcrabble. El juego del Scrabble en Gtk.

Categoría del grupo, rol, implicaciones de diseño, acciones necesarias.

• Informáticos, jugadores, testers, muchos informáticos tienen larga experiencia con este tipo de juegos, cuidar el estilo.
• No informáticos, jugadores, poca experiencia en informática en general, cuidar la sencillez e ir al grano.

Resultados y siguientes pasos

Como resultado de la descripción de grupos implicados, se dispuso que los usuarios compañeros de carrera informáticos y los usuarios conocidos no informáticos no formaban parte del mismo grupo. También nos dimos cuenta del escaso interés por la labor, una mala señal para el futuro del producto. Los desarrolladores son los únicos motivados.

Se decidió concentrarse más en aquellos atributos del análisis que fueron clasificados como agradables a los potenciales usuarios. Las técnicas para sacar estos atributos fueron la discusión en grupo con los potenciales usuarios.

Atributos de los grupos implicados (UA2)

Fecha: 2003-08-14

Descripción del Grupo: No informáticos

Atributo, implicación funcional, características del producto deseado, acciones necesarias.

• Familiar a los primeros juegos de Windows, no demasiado complejo ni demasiado simple, parecido a juegos ya hechos como el solitario, estudio del solitario.
• Diversos grados de experiencia, facilidad de instalación, crear un auto-instalable.
• Reticente a los cambios, la interfaz no debe desviarse de lo acostumbrado, estudio de aplicaciones existentes.

Descripción del Grupo: Informáticos

Atributo, implicación funcional, características del producto deseado, acciones necesarias.

• Freak, están habituados a este tipo de juegos, no es necesario hacer un interfaz extremadamente sencillo sino que puedes asumir cierto interés, se pueden incluir elementos barrocos.
• Sedentario, movilidad limitada por pasar largas horas delante del ordenador, debe ser adictivo, colores atractivos.
• Caótico, necesita tomar las mínimas decisiones, debe de seguir la filosofía de "todo por defecto", interfaz con pocos botones.

Resultados y siguientes pasos

El análisis reveló que el Xcrabble necesitaba ser tan simple de uso como se pudiera, y que era necesaria algún tipo de contacto con los usuarios una vez que tuvieran el juego. Se pedían efectos de audio y visuales. También se acordó que el comportamiento de los botones debía de ser el acostumbrado, para no confundir.

Se decidió proceder a un análisis de posibles sitios en internet donde alojar la aplicación para satisfacer estas necesidades.

Procedimientos de análisis de actividades

Como tarea paralela nos dividimos también en algunos detalles que las actividades que los usuarios necesitaban realizar para usar el juego. Esto se realizó mediante observación directa y discusión en grupo.

Las herramientas de análisis de actividad resumen el entendimiento de los desarrolladores sobre las actividades llevadas por las diferentes categorías de grupos implicados que son suficientemente relevantes como para ser tenidos en consideración. El primer formulario resume los atributos primarios de las actividades de cada grupo implicado. Para entender los requisitos basados en las actividades es importante entender el contexto en el que el producto será usado, y para qué será usado.

Lista de escenarios de grupos implicados (AA1)

Fecha: 2003-08-14

Descripción: Instalación/uso

Escenario, atributos del escenario, acciones necesarias

• Instalación del juego, sin necesidad de un especialista, identifar las habilidades que son necesarias, chequear las distintas configuraciones del host destino.
• Reparar el juego, necesario un especialista, identificar si se ha corrompido el ejecutable o el diccionario o los archivos del sistema operativo.
• Entrenamiento de los usuarios? por otro jugador experimentado, ¿sería necesario?

Resultados y siguientes pasos

La información de las actividades del usuario suscitó preguntas sobre que clase de máquina sería usada, identificando ciertos hábitos. Algunos usuarios dejaban la partida colgada por mucho tiempo, otros en cambio querían acabar cuanto antes. Los no informáticos intentaron repetidas veces utilizar el ratón aunque no tenía utilidad, y les costaba tiempo buscar en el teclado.

Los escenario se revelaron como usuarios habituales y ocasionales, pero no tienen mucha relevancia a la hora del diseño.

Resumen de elementos de actividad (AA2)

Fecha: 2003-08-14

Grupo y escenario: No informáticos, jugando.

Actividades en el escenario, implicación funcional, características deseadas del producto, acciones necesarias.

• Arrancar el programa, necesidad de conocer el comando, un icono donde clicar, diseñar y crear el icono
• Nueva partida, empieza directamente sin preguntar si quiere nueva partida tras cargar el diccionario, ninguna, ninguna.
• Poner palabra, necesita escribir la palabra en el teclado, poder arrastrar las letras como en el juego real, idear un sistema a nuestro alcance para hacerlo con el ratón.
• Terminar partida, se acaba cuando se sobrepasan los "pasos" o no quedan letras o se llega a un nº de puntos, una mejor explicación, mostrar el motivo por pantalla.

Resultados y siguientes pasos

Ya se anticipó que el uso de botones y ratón ayudaría a los usuarios. Nuestro análisis detallado reveló que el mayor problema estaba en la confusión inicial que causaba el no usar el ratón como suele pasar con las aplicaciones de texto. Otra sugerencia fue que el juego mostrase barras con los puntos acumulados en vez de puntuación.

Resumen de requisitos de actividad (AA3)

Fecha: 2003-08-14

Grupo y escenario: No informáticos

Características deseadas del producto, posibles conflictos, prioridades para desarrollar.

• Sistema de guía al usuario,,no aplicable.
• Facilidad de uso, ninguno, alta.
• Pocos y accesibles botones, ninguno, alta.
• Tablero parecido al real, tamaño, media.

Resultados y siguientes pasos

Se ha notado una falta de información sobre lo que un usuario da por sentado en un juego, cualquiera que sea este. El alto nivel de análisis ha indicado alguna ambigüedad sobre la facilidad de uso por parte de los usuarios. Una vista más detallada sugiere que lo que más valor le daría al producto es que sea lo más automático posible, insensible a errores y también se constató que el modo texto supone una habitual parada para algunos usuarios. También se ha identificado que es importante dar el producto a conocer y ofrecer una mínima asistencia tras la instalación.

Análisis del producto (PA)

Fecha: 2003-08-14

Descripción del producto: Scrabble. El juego del Scrabble en modo texto.

Especificaciones amplias/objetivos de diseño, análisis razonado, operación detallada, acciones necesarias:

• Selección automática de la dificultad, se evita una opción más para aumentar la velocidad con que se empieza el juego, eliminar esa opción, revisar las rutinas de inicialización.
• Todos los botones accesibles, necesidad de pocos menús, todo accesible en menos de dos clics, aplicarlo al diseño de la interfaz.
• Indicador del estado del juego, un buen diseño indica como está funcionando, indicadores mediante text labels, incluirlo en el mismo sitio donde estaba los mensajes al usuario en la aplicación original.
• Alarmas auditivas, útiles para usuarios con visión limitada, beeps o tonos musicales, averiguar alguna forma de hacerlo.

Resultados y siguientes pasos

En la revisión del análisis del producto se tuvieron en cuenta las discusiones preliminares que habíamos tenido con los usuarios. Las principales necesidades del producto fueron la necesidad de botones grandes y de asegurar un mantenimiento simple.

Matriz de atributos del producto (PAM)

Para mirar en detalle el grado de acercamiento entre los requisitos emergentes del Xcrabble y la especificación emergente, el equipo de desarrollo usó la matriz de atributos del producto.

Especificación del producto	Especificación del producto	Operación con el ratón	Avisos al cerrar	Botones grandes fáciles de pulsar	Indicador luminoso	Estilo convencional	Fácil de actualizar y cambiar	Reloj	Fichas similares	Prioridad	Resumen
Costo de desarrollo		Alto	Bajo	Alto	Alto	Bajo	Bajo	Alto	Medio	-	-
Prioridad		Alta	Alta	Media	Alta	Baja	Baja	Baja	Alta	-	-
Requisitos del usuario final (UA3)	-	-	-	-	-	-	-	-	-	-	-
Indicadores Sonoros				NO				OK	?	N/A	N/A
Controles simples			OK		NO	?	OK	NO		Alta	Ok
Siplicidad de uso		OK								Media	Ok
Botones rápidos			NO	OK	?	OK				Alta	N/A
Movimientos con el ratón								NO		N/A	No
Autoexplicativo			OK		OK		OK		OK	Alta	No
Soporte		NO	NO	NO	NO		OK	NO	OK	Baja	Ok

Resultados y siguientes pasos

La matriz muestra el anticipado encuentro entre los atributos deseados del producto (filas) y los atributos que ya habían sido considerados (columnas). Las filas y las columnas del PAM vienen directamente de la especificación del producto (PA), análisis del usuario (UA) y análisis de actividades (AA).

La discusión subsiguiente permitió que la matriz se resumiera en términos de la especificación emergente del producto se iba adecuando a los requisitos deseados y viceversa, que los requisitos se adecuasen a la especificación. El valor e control dado por los botones grande se discutió, y a pesar de que no había sido explícitamente especificado en el estado de desarrollo, se tomó como algo que sería positivo. La discusión también hizo aparecer el hecho de hacia quien iba a ser destinado el producto, si para un público reducido o para todo el mercado de consumo. Se decidió que el esfuerzo merecía un público amplio.

No se tenía idea del espacio que iba a ocupar la aplicación, pero se pensaba razonablemente que mayor que la aplicación original, aunque con las librerías compartidas de la gtk no está claro si forman o no parte de la aplicación porque hipotéticamente son compartidas - si alguna otra aplicación las utiliza -.

La necesidad de un registro del tiempo también se discutió pero no se llegó a ninguna conclusión clara, así que se marcó con un No. Todo esto se resumió en el documento de resumen de requisitos.

Resumen de requisitos (RS)

Fecha: 2003-08-18

Descripción del producto: Xcrabble. El juego del Scrabble en Gtk.

Requisito deseado, grado de adecuación con la especificación, acciones necesarias:

• Uso de sonido así como de indicadores visuales, la especificación inicial no lo indicaba, desechado.
• Controles Simples, parece una buena idea hacerlo un poco más complejo con tres botones de operación, necesitamos confirmar que esto es aceptable.
• Botones grandes, sin problemas anticipados.
• Buena comunicación del estado de la aplicación, no especificado pero se intentará por parte de los desarrolladores, necesidad de desarrollo adicional

Resultados y siguientes pasos

La matriz de atributos del producto se ha utilizado para identificar si hay características incluidas en la especificación que no encajaban en ninguno de los requisitos. Se notó que La propuesta de la operación con dos botones no era suficiente, y se aumentó a tres para evitar esta limitación. El uso de indicadores auditivos fue descartado por falta de tiempo y conocimientos. Los desarrolladores estuvimos de acuerdo que la especificación emergente no era exactamente como el modelo inicial pero que no había implicaciones de diseño significativamente diferentes.

Resumen de diseño (DS)

Fecha: 2003-08-18

Descripción del producto: Xcrabble. El juego del Scrabble en Gtk.

Especificaión funcional, prioridad, detalles de operación:

• Conforme al estándar, baja, fijarse en otros juegos parecidos.
• Solo tres botones para la operación normal, alta, Esto ha sido considerado para su rediseño pero su inclusión ha sido finalmente aceptada.
• Indicadores visuales, media, usar los existentes métodos del juego originar y transformar la salida para ser mostrada en text labels.
• Botones grandes, media, fijar el tamaño de los botones encajados en las imágenes.

Procedimientos de evaluación de facilidad de uso

Además de referirse a la especificación del producto los desarrolladores deben considerar como va a ser evaluada la facilidad de uso. Los criterios que se deben satisface3r para que el producto se considere como un éxito. Estos elementos deben ser considerados en las fases tempranas del ciclo de desarrollo, así como su discusión para el refinamiento del producto.

Estrategia de evaluación total (UE1)

Fecha: 2003-08-20

Descripción del producto: Xcrabble. El juego del Scrabble en Gtk.

Propósito, tipo de evaluación planeada, detalles del plan:

• Observar su uso en su ambiente natural, prueba de campo, se intentará instalar el producto en una casa por un día para ver el uso durante ese tiempo.
• Prestar atención a eventos que no ocurren habitualmente, pruebas por parte de los usuarios, una muestra de usuarios potenciales. La idea es tener los que accedan a ello intentando eventos inusuales.
• Proporcionar una perspectiva amplia, opiniones de expertos, contactar con jugadores habituales y pedir su opinión

Plan de evaluación (UE2)

Fecha: 2003-08-22

Descripción del producto: Xcrabble. El juego del Scrabble en Gtk.

Característica deseada, objetivo de facilidad de uso, actividades, tipo de estudio, procedimiento de medida, criterio de aceptación/rechazo.

• Uso de indicadores sonoros y visuales, conseguir que los usuarios de visibilidad reducida les sea fácil jugar, no se ha implementado.
• Controles simples para hacer la aplicación lo más sencilla de usar, los botones deben ser autoexplicativos, los usuarios no han fallado más de dos veces seguidas, prueba de campo, error en las operaciones.
• Botones grandes, belleza visual y sin pérdidas, no ha habido dudas de lo que eran botones aunque sí errores al colocar la ficha en la casilla, prueba de usuarios, ausencia de dificultad observada.
• Simplicidad de mantenimiento, facilidad de encendido/apagado y transparencia de la carga del diccionario, ciertas dudas se han observado durante la carga del diccionario que requirieron la explicación, prueba de campo, aceptación del usuario.

Resultados y siguientes pasos

Este documento ha sido usado para enseñar como los requisitos deseados que han sido identificados durante la especificación del producto serían evaluados, y como las actividades se transforman en objetivos de facilidad de uso. Por ejemplo, la característica deseada de indicadores auditivos se ha rechazado, pero la de mantenimiento ha sido satisfecha.

Resumen de la evaluación de facilidad de uso (UE3)

Fecha: 2003-08-20

Descripción del producto: Xcrabble. El juego del Scrabble en Gtk.

Objetivo de facilidad de uso, ¿ ha sido satisfecho ?, acciones necesarias:

• Discriminar si es fácil de jugar y aprender, algunos de las dudas se presentarían también en el aprendizaje del juego sobre la mesa, el producto podría ser más explicativo con abundancia de tooltiptexts.
• Aplicación funcional en Windows, plenamente satisfecho.
• Los usuarios pueden identificar su puntuación y turno, las confusiones se han vuelto a dar, mejorar la información de los textlabels.
• El usuario tiene las mismas funcionalidades que con el juego original, parcialmente satisfecho.

Resumen final y acciones asociadas

La fase final de USERfit es la de grabar los resultados de las evaluaciones que han tenido lugar una vez que el producto ha sido construido, y decidir si es necesario hacer algo más. La satisfacción debe de estar garantizada tanto como hayan sido alcanzados los objetivos de facilidad de uso. La evaluación debe también identificar requisitos adicionales no que no se hayan podido llevar a cabo. En definitiva, y dado el tiempo disponible, se ha alcanzado una valoración positiva.

Anexo: ¿Cómo se juega?

Al comienzo de la partida a cada jugador se le asignan, de forma aleatoria, siete fichas que se colocan sobre su atril.

El primer jugador, al que la ha sido asignado su turno de forma aleatoria, combinados o más de las letras de su atril para formar una palabra y la coloca sobre el tablero en línea horizontal o vertical, debiendo poner una de las letras que forman la palabra en la casilla central. No se permite colocar palabras en diagonal.

Un jugador completa su turno cuando cuenta y anuncia el total de los puntos obtenidos. Posteriormente añade a su atril tantas letras nuevas como fichas haya utilizado hasta llegar a tener siete.

A continuación el turno pasa al siguiente jugador. El segundo jugador (y a continuación los demás según su turno) añade una o más letras a las que ya se han jugado, con el fin de formar nuevas palabras. Todas las letras que se usan en un turno se deben colocar en vertical u horizontal sobre el tablero. Deben formar una palabra completa, y si al mismo tiempo tocan otras letras en hileras contiguas, también tendrán que formar palabras completas con las mismas, al igual que ocurre en los crucigramas. El jugador se anota los puntos de todas las palabras que haya formado o modificado en su turno.

Las palabras nuevas se pueden forman principalmente de tres formas: añadiendo una o más letras a una palabra ya formada, colocando una palabra que cruce a otra palabra o colocando una palabra en paralelo a otra, siempre que las letras contiguas formen también una palabra.

Ninguna letra puede ser cambiada de lugar una vez que ya ha sido colocada en el tablero de juego.

Cualquier jugador puede hacer uso de su turno para cambiar tantas letras de su atril como desee. En lugar de colocar letras en el tablero o cambiar su atril, pudiendo o no poner palabra, el jugador puede pasar su turno. Si todos los jugadores pasan 2 veces consecutivas, se da por terminado el juego. Son aceptables todas las palabras que se encuentran en el diccionario y si un jugador pone una palabra inaceptable o que no encaja con las letras contiguas este pierde su turno. Solo se podrán formar palabras que puedan ser leídas de izquierda a derecha o de arriba abajo.

El juego continua hasta que se hayan cogido todas las fichas y uno de los jugadores haya utilizado todas las letras de su atril, o hasta que quedándoles fichas a los jugadores, ninguno de ellos pueda colocar las que les sobran.

Cuando un jugador termina su turno se le debe anotar el total de los puntos obtenidos. El valor de cada letra lo indica un numero en la parte inferior de la ficha.

Los tantos de cada turno son la suma total de los valores de las letras de todas las palabras que se formen o se modifiquen en su turno, mas los valores de los premios que se consiguen al colocar las letras en las casillas con Premio. Cuando se forma mas de una palabra en el mismo turno se apuntan los tantos de cada una de ellas. La letra que les sea común se cuenta en cada palabra. El jugador que logra colocar las 7 letras de su atril en una sola jugada consigue una bonificación de 50 puntos además de los que le corresponden por la palabra.

Al final del juego se le rebaja a cada jugador el valor total de los puntos de las fichas que le han sobrado, y si un jugador ha utilizado todas sus fichas se le añade a su puntuación el valor total de los puntos de las fichas que han sobrado al resto de los jugadores.

Hay cuatro tipo de casillas con premio: las que duplican y triplican el valor de la letra y las que duplican y triplican el valor de una palabra cuando una de sus letras coincide con una de estas casillas. Si en estas ultimas, además hay premio para las letras, estos puntos extra se cuentan antes de que se doble o triplique el valor de la palabra. Si se forma una palabra que cubra dos casillas con premio para palabras este se contabiliza dos veces, es decir, se multiplica por 4 o por 9 el valor de la palabra según corresponda.

La casilla central del tablero es una casilla de doble tanto de palabra. Estos premios se contabilizan solamente la primera vez que se cubren las casillas.

Repetición y valor de las letras: el número pegado a la letra indica y el número situado al lado el numero de fichas que hay con esa letra.

A1 - 12  B3 - 2  C3 - 4  D2 - 5  E1  - 12
F4 - 1   G2 - 2  H4 - 2  I1 - 6  J8  - 1
L1 - 4   M3 - 2  N1 - 5  Ñ8 - 1  O1  - 9
P3 - 2   Q5 - 1  R1 - 5  S1 - 6  T1  - 4
U1 - 5   V4 - 1  X8 - 1  Y4 - 1  Z10 - 1

Modificaciones del juego original: en el juego descrito anteriormente hay dos fichas en blanco que pueden usarse a gusto del usuario asignándoles las letras que desee. Cuando un jugador coloca una de estas letras debe indicar que letra representa y ninguno de los jugadores podrá cambiarla durante el juego. En la resolución del problema llevada a cabo esta posibilidad se ha suprimido. No existe ninguna ficha blanca ya que para solución que hemos dado al problema hacia que las búsquedas de palabras en el diccionario fueran mucho más lentas. Además de la dificultad de representar en el tablero el comodín.

Otra modificación al original ha sido que las letras CH, RR y LL no se han considerado como tal sino como formadas por dos letras diferentes: c y h, dos erres y doble l.

La razón de haber suprimido estas letras, aparte de que nos ocasionaban problemas a la hora de almacenar el diccionario en el trie, es que la Real Academia de la Lengua Española ya no las considera como tal.

Después de esto el numero de fichas en juego se reduce de en 5 (de 100 a 95): dos blancas, una CH, una RR y otra de LL, porque aunque hayamos suprimido estas fichas no hemos añadido mas de las que les sustituyen.

El valor de estas letras en el original sería: 0 puntos para el blanco, 5 para la CH, 8 para la LL y 8 para la RR.