Bueno, ya que ha acabado el curso de python de Coursera, y siguiendo el ejemplo de JGuardon de usar lo visto en dicho curso en gambas3.......... pues aquí está mi versión del blackjack.

Antes del curso, yo de clases sabía una m, pero ahora ya se un poquito más que incluso pude implementarlas en gambas,

Bueno, pss publico las fuentes por si a alguien les sirven de algo:

blackjack-0.0.1.tar.gz

Saludos!

Hola razaAztk.

Cuando comencé a hacer el juego de las cartas.Que no he terminado por que no hago por ponerme.
Un componente que usaba para colocar las cartas es los contenedores de alineación.

Para insertar la carta en el control  Hpanel en este caso, usaba la clase baraja, que tenia
este método:
 


La idea es de que aproveches el contenedor para situar las cartas una detrás de la otra.
Y puedes también tener un espacio entre cada carta.  Además, no tienes que complicarte con coordenadas.

Una vez que comienzas a trabajar con clases, ves la programación de otra forma. Pero es algo complejo.

Ey, gracias por el código!.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Shell, el proyecto de razaAztk es perfecto, tal y como hay que hacer las cosas en un programa, usando un poco de POO. Sólo se usa un DrawingArea y tres botones, no hace falta más. Por sacarle un defecto, yo habría espaciado más las cartas, pero nada más.

El problema que es la mayoría de vosotros pensáis que para hacer juegos donde se muevan objetos, éstos objetos tengan que ser necesariamente controles independientes, como he visto en alguna ocasión. Mover un control PictureBox con una imagen por un formulario es una barbaridad, cuando la manera de hacerlo es pintar dentro de un drawingarea y mover esas "entidades" dentro... pero dibujando, no moviendo controles.

Cualquier engine de juegos es lo que hace, no hay otra forma. De hecho, gb.sdl tiene un objeto window que es donde se dibujan las cosas y no puedes poner controles dentro, porque no es un formulario. Igualmente la clase screen de pygame funciona muy parecido...

Estos son mis dos céntimos!

Saludos

===================
Jesús Guardón

Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".

"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"

razaAztk:

Te ha quedado muy bien... gracias por compartir el código.
Me lo tengo que estudiar!!!  

Saludos

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!

Jesús:

jguardon escribió: [Ver mensaje]

Shell, el proyecto de razaAztk es perfecto, tal y como hay que hacer las cosas en un programa, usando un poco de POO. Sólo se usa un DrawingArea y tres botones, no hace falta más. Por sacarle un defecto, yo habría espaciado más las cartas, pero nada más.

Perfecto no hay nada, perfecto en programación es relativo.

Mi intención no era ver defecto.Era compartir la idea de un componente que puede ser mejor que un sistema de coordenadas.
Comparte muchas ideas con respecto en el diseño de las clases a los juegos que intentaba yo mismo hacer de cartas.

Te lo diré con un ejemplo:

Tengo una ventana en la que tengo que colocar  x componentes uno pegado a lado de otro con una distancia x entre ellos.
Al usar un contenedor solo tengo que ir instanciando los componentes dentro del contenedor Hpanel y este mismo se encarga
de ordenar y situar horizontalmente con una distancia entre ellos. ¿ Que hay de erróneo en eso ?.
¿ Donde están las coordenadas ?.¿ Donde están las operaciones de cálculos de distancias ?.  

Es otra forma de hacerlo.No es erróneo, es diferente.Relativo.

jguardon escribió: [Ver mensaje]

El problema que es la mayoría de vosotros pensáis que para hacer juegos donde se muevan objetos, éstos objetos tengan que ser necesariamente controles independientes, como he visto en alguna ocasión.
Mover un control PictureBox con una imagen por un formulario es una barbaridad, cuando la manera de hacerlo es pintar dentro de un drawingarea y mover esas "entidades" dentro... pero dibujando, no moviendo controles.

Son cosas que vamos viendo y aprendiendo. Mucho de nosotros, no tenemos tutores, aprendemos por nosotros mismo ya sea por el método de prueba y error.
Buscar información, heredar de otros códigos y a la vez heredar soluciones, problemas y costumbres.Costumbres que pueden ser positivas o negativas.

jguardon escribió: [Ver mensaje]

Cualquier engine de juegos es lo que hace, no hay otra forma. De hecho, gb.sdl tiene un objeto window que es donde se dibujan las cosas y no puedes poner controles dentro, porque no es un formulario. Igualmente la clase screen de pygame funciona muy parecido...

Y a mi no me parece mal.Pero para eso hay que verlo y aprender de nuestros errores.
Por eso estoy aquí, para aprender.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

A ver, que no quiero que se me malinterprete.

Lo que quiero decir es que en el terreno de los juegos, esa es la forma correcta de hacer las cosas. Pero evidentemente no es la única. Pero usar controles para representar cosas encima de un formulario no es lo mejor desde el punto de vista de un programador, porque los controles consumen memoria, cada control que instancies está consumiendo memoria y si lo mueves, se tiene que volver a dibujar, etc. Muchos recursos consumidos para poca cosa. ¿Que puede ser más sencillo?... depende. Sin embargo usar una superficie de dibujo como un drawing area o el objeto window de gb.SDL sólo consume ciclos de procesador para los cálculos, porque lo que se pinta da igual. Se está refrescando x veces por segundo siempre, independientemente de lo que pintes dentro. La huella de memoria no se ve muy alterada en ese aspecto.

Desde luego nadie dijo que hacer un juego fuera algo fácil, porque requiere muchas matemáticas y una visión diferente de las cosas. Un juego no es programación de formularios. Y que conste que no soy para nada aficionado a los juegos, pero en estas semanas de atrás he visto y comprendido algunas cosas que ignoraba y me han hecho ampliar la forma de ver las cosas o de abordar un problema específico.

Desde luego, estamos aquí para aprender y compartir lo aprendido, no era mi intención recriminar a nadie la forma de hacer las cosas. Pero eso no va a cambiar mi opinión, opinión que tengo por cierto desde que comencé a programar y mantengo que cada control tiene su función y usarlo para lo que no ha sido diseñado, no es lo mejor.

Saludos

===================
Jesús Guardón

Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".

"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"

Citar:

Mucho de nosotros, no tenemos tutores, aprendemos por nosotros mismo ya sea por el método de prueba y error.

Bueno como bien dice Shell, así estamos, no hay tutores y aprendemos con método de prueba y error...

Os comento mi experiencia de "ensayo y error":

En el programa del Creador de Orlas tengo hecho un editor gráfico, para definir las posiciones de las fotografías y con la posibilidad de moverlas a  nuestro antojo para organizarlas dentro de la orla.

 La primera idea que tuve fue hacerlo dentro de un control drawing area,e ir redibujando  todo.... hice una pequeña versión y se probo en los ordenadores donde se va a usar el programa (los portátiles pequeños o netbook que le daban a los niños en los colegios), iba muy mal, muy despacio ya que estos ordenadores tenían poca CPU pero mucha memoria. En mi ordenador corría el programa bien, porque le sobra CPU para hacer este trabajo...

El caso es que tuve que rehacerlo de nuevo usando un  picturebox para cada foto de alumno o profesor,y tanto en mi ordenador como en los netbook he conseguido que vaya fluido...

Con esto quiero decir, que cuantas más maneras de hacer una cosa sepamos mejor... seguramente habrá una más optima, pero siempre hay que tener un plan "B", por si se presentan problemas...

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!

Julio:

Aun no he tenido tiempo de ver el creador de orlas, ¿ tienes la aplicación con  las dos formas ?.
(Con DrawingArea y con los Picturebox.)

Si es bueno tener un plan "B", pero hay que estudiar el problema con tiempo. Tiempo que a lo mejor no tienes.
El que tenga que entregar un proyecto con unos plazos, debe ser bastante agobiante. Y luego no siempre queda bien,
con las prisas, los errores.

Si en pequeñas aplicaciones que mostramos en la comunidad, aun necesitan optimización,
imagina una aplicación con bastante código.

Algunas veces queda fuera de nuestro alcance y es probable que con el tiempo veamos otras posibilidades
para hacer la aplicación. Cuando ves muchos ejemplos, te olvidas de los anteriores. En el caso de aplicaciones
que te están dando algo mas, tienes que estar con ellas.Días,semanas, meses.

Por mi parte he recomenzado el tema de los juegos, dibujando en el DrawingArea.
Aunque sean una tontería, por algo se empieza.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Shell:

Citar:

¿ tienes la aplicación con  las dos formas ? (Con DrawingArea y con los Picturebox.)

No, eran simples "pruebas". El proyecto esta subido con subversion a en code google, pero lo subi ya con la opcion de los picturebox (nota: uso una clase que herencia de los picturebox).

Como ejemplo puedes ver mi aplicacion "croquis" que hice ( http://jsbsan.blogspot.com.es/2013/...afico-para.html) , y compararla con el editor del Creador de Orlas, para que veas como era la idea inicial

Citar:

Algunas veces queda fuera de nuestro alcance y es probable que con el tiempo veamos otras posibilidades
para hacer la aplicación.

Pues si, pasa mucho eso... al final ves cosas que  podrías mejorar.... yo por ejemplo no use nada de bases de datos en las aplicaciones, me he limitado a crear unas clases que lo hacen todo con ficheros planos de texto para guardar la información.... pero me he dado cuenta que a la larga trae más problemas... si lo hubiese resuelto con sqlite, me hubiera ahorrado un montón de bugs, que han ido apareciendo... en fin... experiencia para otros proyectos  

A mi me pasa que a algunos  de mis programas le cojo "cariño", y nunca los veo terminados,  pues vas mejorandolos día a día, no solo corregiendo bugs, sino añadiendo opciones que te comentan o te piden los usuarios (eso pasa cuando hay usuarios que los usan , el caso contrario, pierdo las ganas de seguir haciéndole modificaciones   )

Citar:

aun necesitan optimización

Si hay es importante la optimización, pero hay que poner en la "balanza" el tiempo que tienes disponible, cuanto te cuesta optimizar el código, etc...

La verdad es que :
-conocer que quiere el cliente
-dialogo con el cliente (mostrar esquemas, pre visualización de pantallas, etc),  la "retroalimentación"
-y una buena planificación (estudiar como tienes que organizar los datos, clases que te harán falta, módulos que puedes aprovechar de otras aplicaciones, etc...)
Con estas cosas consigues "no perder mucho tiempo" e ir sobre "seguro"... y eso si cada vez que hagas algo (bien o mal, siempre aprendes más cuando lo hiciste mal y tuviste que repetirlo        )

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!

Hola!.

Algo mas que se puede complicar el juego del Blackjack.

A mi es que me gustan los juegos de cartas, de ordenador (como no tengo con quien jugar una partida. También prefiero
programar.   ), naturalmente, nunca juego  por dinero, juego por divertirme. Por cierto:

¿ Habéis visto la lata que dan por la tele con el tema del poker ?. Estamos con la crisis y que pongan esos anuncios.
Pero esto sera de pago, lo mas seguro, no juegan por diversión.

Volvamos al tema. Como aficionado a los juegos de cartas.Muchos de los juegos de blackjack cuando empezamos a hacerlos
por primera vez o lo vemos por primera vez. No se contempla o contemplamos la jugada "Split".

¿ Cuando se produce split ?. Cuando tenemos dos cartas iguales.
El que habla debe preguntar al jugador que puede hacerlo si desea hacer split.
Dividendo la cantidad apostada en dos y teniendo otra posibilidad de ganar.

Entonces, tendremos dos manos distintas en la misma partida, el juego continua, terminas con la primera y luego con
la segunda. Naturalmente, puede haber otras posibilidades de hacer split. ¿ Hasta cuantas veces se puede hacer split ?.
Supongo que las que se pueda.

Lógicamente, existen otras posibilidades. "Insurance". Cuando al comienzo de partida el ordenador tiene dos cartas, una no la vemos y la otra es un as
por ejemplo, ¿ en que consiste Insurance ?.

Cuando son muchos los jugadores, tu pagas por ese "seguro" de que pueda ser un 21 del que habla,
la banca. Si la banca gana, tu no pierdes y ganas, no recuerdo si la mitad.

Ah, para el DrawingArea. Aun no entiendo muchos conceptos. Imaginar que tenemos capas de dibujos, si fuera posible.
Una posible capa seria un tapete y saber en que posición "remarcada" deben ir las cartas. Podemos bajar alguna imagen
de Internet y usarla como fondo.

Ejemplo de una distribución de una mesa.

 

Una saga de juegos de cartas y juegos de azar, era Hoyle Casino Games.
Hubo muchas versiones, mejorando el aspecto de los jugadores, animaciones,etc.

Olvidaba. Si queremos complicarnos mas, se podría hacer un juego servidor-cliente.
Así tendríamos la posibilidad de que jueguen mas jugadores en la partida.


Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"