Ver la versión completa : ¿Qué lenguaje utilizo?
Buenas.
Había pensado en meter un poco la nariz en los lenguajes de programación y empezar a crear un juego. La idea que yo tengo es hacer un juego de estrategia a lo Fire Emblem, es decir, combinando toques de rol con estrategia y con "relativamente" pocas unidades sobre el campo de batalla. Me centraría más en que las tropas suban de nivel y sean poderosas que en tener diez mil soldaditos que mueren al primer golpe.
Ahora la duda, ¿qué lenguaje utilizo para programarlo? Como supondréis, el juego estaría pensado para GP2X y, en un futuro, portarlo a la Wiz si es posible. No sé si ambas consolas utilizan el mismo lenguaje siquiera.
Lo malo viene siendo que yo no tengo ni idea de lenguajes de programación más o menos avanzados (como C o Fenix), lo máximo que he programado yo y se le parece es en RPG Maker, con todas sus variables, eventos y esas cosas. xD Tengo altos conocimientos de html, pero no creo que venga muy al caso.
¿Con qué lenguaje me recomendáis empezar? Que sea fácil para empezar desde cero.
Si quieres aprender a programar con cojones, ponte con el C. O lo amas o lo odias (yo lo odio) pero es algo que hay que tragar antes de rechazarlo. Si quieres algo más sencillote y portable, prueba con python y pygame.
Ni te plantees hacer un juego de rol complejo a la primera, no suelen salir bien: Wartricks. (wartricks.blogspot.com)
loixartx
27/12/2008, 00:24
El más sencillo es fenix; sin duda. Si empiezas con C sin tener ni idea de programación seguramente te aburras antes de dominar el lenguaje.
Además fenix te puede servir como base para aprender otros lenguajes más avanzados el día de mañana, como C, C++, java, etc.
Mi consejo: Fenix.
un saludo y no empieces con cosas muy difíciles; empieza por el clásico pong, algún juego de naves ...
hellcross
27/12/2008, 00:44
Fenix y luego C
Ni te plantees hacer un juego de rol complejo a la primera, no suelen salir bien.
no empieces con cosas muy difíciles; empieza por el clásico pong, algún juego de naves
Ya, claro, pues no me queda ni na para empezar a hacer el proyecto este. xD Empezaré con cosas sencillitas para ir probando el lenguaje.
Pues voy a buscar por ahí algún tutorial de Fenix de momento y ya me pasaré a C. ¿Sabéis alguno fiable?
De momento he encontrado esto: http://descargas.abcdatos.com/tutorial/descargarZ7048.html
Ese manual de Fénix es el que todos hemos leído y es muy recomendable. Tiene muchos ejemplos comentados y es hasta adictivo. Veo que te gustan los juegos de estrategia, bien, bien, empieza con algo sencillo como las tres en raya, y poco a poco irás aprendiendo más.
¿Por qué siempre habláis tan bien del fénix? ¿para los que sabemos programación no es bastente mejor alguna librería para C, C++, Pygame o algo asi?
El problema que le veo al fenix es que se pueden coger malos hábitos de programacion, si tienes intencion de programar en serio mas adelante, empieza por el C.
chemaris
28/12/2008, 16:28
lo bueno de fenix es que obtienes resultados inmediatos y para hacer juegos en 2D esta muy bien pensado, empezar directamente con C sin saber programar puede ser un muro bastante dificil de traspasar, por eso creo que lo mejor es empezar con fenix y hacer algun jueguecillo y mas adelante si te ves capaz y quieres aprender mas dar el salto a C
Por otra parte fenix no es tan limitado como puede parecer y se pueden hacer grandes proyectos con el, luego esta bennu que es una evolucion de fenix en la que quieren que sea una especie de lenguaje de scripting para C, pero hace meses que no sigo el proyecto y no se como esta el tema
Entonces me leeré el manual ese y a ver si saco algo en claro. xD
Acias. :P
enkonsierto
29/12/2008, 18:15
De nada... :)
loixartx
29/12/2008, 19:11
El problema que le veo al fenix es que se pueden coger malos hábitos de programacion, si tienes intencion de programar en serio mas adelante, empieza por el C.
¿Malos hábitos? Es un lenguaje procedural, como puede ser C. Sin los clásicos quebraderos de cabeza que puede dar los punteros para alguien que aún no domina la programación.
A mí fenix me parece uno de los lenguajes más sencillos para empezar a programar, su sintaxis es junto a Pascal, lo más parecido a pseudocódigo que conozco.
Una vez que controlas el tema de control de flujo: condiciones, bucles, procesos, etc. Pues entonces sería interesante meterse directamente en C++, SDL y un diseño orientado a objetos.
Casi que me saltaba C :D
Yo tambien te recomiendo Fenix. Para los que no sabemos nada de programación y partimos de 0 es lo mas recomendable. Gracias a su inmediatez es sencillo ver resultados y no desanimarse. Usa una sintaxis bastante coherente y tiene mucha documentacion/ejemplos en español... y aquí siempre te responderan dudas algunos buenos expertos del foro.
PD: Mi mejor consejo a la hora de programar... planificacion 100% del juego y sus características antes de empezar! No hay nada peor que llevar medio juego programado y querer añadir una nueva "feature" indispensable con lo que tienes que modificar el 80% del còdigo ya escrito... osea abandono de proyecto :lamer:
Saludos
¿Malos hábitos? Es un lenguaje procedural, como puede ser C. Sin los clásicos quebraderos de cabeza que puede dar los punteros para alguien que aún no domina la programación.Y con un diseño completamente orientado a programación concurrente, que es lo que puede hacer que se cojan malos hábitos de programación :P Luego te pones con un lenguaje secuencial y te haces la picha un lío si nunca has resuelto problemas sin utilizar concurrencia.
anakinmay
30/12/2008, 12:31
Procura usar un lenguaje correcto, evita las abreviaturas y no digas tacos que estamos en navidad..
Usualmente se habla español, aunque hay gente que se defiende muy bien en inglés.
Si alguien sabe algo de francés que avise que no me vendría mal una limpieza del sable!!
salu2 a to2
animanegra
30/12/2008, 13:07
No me parece que fenix o cualquier otro lenguaje sea malo para empezar, bueno el perl porque programar con jerogrificos no es muy intuitivo pero por lo demas...
fenix no es concurrente, no se ejecuta ninguna funcion de forma concurrente. NO hay ningun proceso que se ejecute a la vez que otro, hay un planificador que ejecuta secuencialmente los procesos. No me parece ni mucho menos un mal lenguaje para empezar.
Si os parece que fenix es malo y el problema es la organizacion en base a procesos, usas la forma habitual usando funciones y listos. Asi no usarias los procesos y no habria problema de aprender a programar de lo que suponeis es una mala forma.
El unico problema que le veo a fenix es el tema de que no sea nativo, eso significa mayor portabilidad pero menor rendimiento.
¿Porque estais en contra de c y a favor de c++? Si Torvals os leyese seguro que os montaba aqui el pitoste padre ^^.
Yo por mi parte para aprender usaria cualquier lenguaje, la verdad es que le tengo mucho apego a c y me parece lo mejor del mundo, pero la gente lo suele odiar a muerte sobre todo lo que mencionan de punteros(si te pones con c yo le hecharia un vistazo a las herramientas valgrind y gdb que ayudan un monton).
La verdad es que aprendiendo en cualquiera pasarte a otro no va a ser problema. Al final los algoritmos que uses para solucionar las cosas van a ser los mismos en todos. y solo variaran un poco los tags.
El unico problema que puedes tener es al pasar de unos estructurado a otro orientado a objetos, que con el tema de encapsular y esos rollos la organizacion puede variar un poco, pero vamos que una vez cogido el concepto es simple.
Es solo una opinion, espero que te haya ayudado algo de lo que he dicho, si no pues nada ^^
¿Malos hábitos? Es un lenguaje procedural, como puede ser C. Sin los clásicos quebraderos de cabeza que puede dar los punteros para alguien que aún no domina la programación.
Lo digo porque he visto codigos que no estaban muy estructurados, pero claro eso depende de como programe cada uno.
El fallo que le veo es que en los procesos tienes que poner un bucle infinito e ir llamando a frame en cada iteracion. Creo que hubiera estado mejor si tuvieras unos metodos por defecto y si te interesa se reescriben.
Yo el fenix / DIV lo hubiera hecho asi, tal vez tambien hubiera añadido cosas como eventos para disparar sonidos u otros procesos... no se...
Process foo
Begin
OnInit()
Begin
// codigo que se ejecuta al crear un proceso
End
OnDestroy()
Begin
// codigo que se ejecuta al destruir un proceso
End
OnFrame()
Begin
// codigo que se ejecuta en cada iteracion del bucle del juego, aqui se pondria el codigo
// para mover el proceso (IA),
End
OnDraw()
Begin
// despues de OnFrame se llama a OnDraw para dibujar el proceso, si se deja vacio se
// dibuja el sprite asociado al proceso, tiene la ventaja de que podemos dibujar mas sprites por
// procesos, por ejemplo el escudo de una nave
End
End // del proceso
De esta forma te obligaria a tener todo mas estructurado.
Editado:
Tal vez de esta forma en vez de interpretar el lenguaje seria mas facil de hacer un traductor a C++, y despues compilar este... asi ganarias en velocidad...
animanegra
30/12/2008, 13:28
pero ese tipo de estructura la puedes hacer en fenix si quieres. Hace el proceso que responda a señales y manejadores y listos. De todas formas yo no soy muy fan de la programacion orientada a eventos. :D Yo creo que un programa esta bien programado si sigue un patron funcional y el analisis se ha hecho con cabeza. No hace falta que siga un patron especifico.
Aparte no creo que esa fuese la estructura optima para programar un juego, pero es solo una opinion. Simplemente que yo no me sentiria comodo con ella ^^. ***** patrones de diseño para GUIs :P Dejad de mirar codigos en .NET!!!! (Es broma eh!!)
Pero en fenix lo tendrias que hacer a mano, la idea es que se llamen a esos metodos de forma automatica al crear, destruir, mover o dibujar un proceso.
Yo el .NET no lo he mirado, de hecho lo ODIO...
fenix no es concurrente, no se ejecuta ninguna funcion de forma concurrente. NO hay ningun proceso que se ejecute a la vez que otro, hay un planificador que ejecuta secuencialmente los procesos. No me parece ni mucho menos un mal lenguaje para empezar.Se ve que tienes algunos fallos de concepto... La multiprogramación es programación concurrente pura y dura, y ahí no se ejecutan en ningún momento varios procesos a la vez (ya que no es posible en una única CPU), sólo se intercalan.
animanegra
30/12/2008, 18:48
Bajo mi punto de vista la programacion concurrente requiere que haya varios procesos a la vez en ejecucion theads o forks accediendo a recursos y que no controles su ejecucion ya que quien se encarga de controlar dicha ejecucion es el SO. Aqui no hay varios procesos en ejecucion si no que cada vez que se requiere, hay un cambio de contexto controlado por el usuario. No hay ningun problema de concurrencia (no hay que usar ni semaforos ni ningun tipo de monitor) asi que yo al menos no considero que sea concurrente. Entiendo que mi forma de pensar no es un fallo de concepto simplemente que discrepamos ^^.
La defición de la programación concurrente deja poco lugar para la discrepancia. Genios como Dijkstra ya hablaron largo y tendido sobre ello. A grandes rasgos, en Wikipedia hay información sobre el tema:
http://es.wikipedia.org/wiki/Computaci%C3%B3n_concurrente
http://es.wikipedia.org/wiki/Multiprogramaci%C3%B3n
Pero en resumen, cuando el nacimiento o muerte de un proceso se produce entre el nacimiento y muerte de otro, es concurrente, incluso aunque uno de ellos no hubiese ejecutado una sola instrucción durante todo el tiempo de existencia del otro.
Tampoco es requisito que el sistema operativo gestione los hilos o procesos del programa. Lenguajes como PascalFC implementan la gestión de procesos por software.
Los monitores y los semáforos son el modo en el que hoy día se sigue enseñando en las universidades la gestión de acceso a recursos concurrente, por la razón obvia de que obliga al programador a entender la concurrencia para que sea capaz de implementarlo correctamente. En la práctica muchos lenguajes tienen soluciones de alto nivel para gestionar estas cosas. Supongamos un hipotético lenguaje que permite marcar funciones como "mutex". Esto quiere decir que sólo un proceso podrá estar ejecutando el código de esa función cada vez (supongamos que por ejemplo esa función escribe en el log del programa, y no queremos que se mezclen líneas que mandan varios procesos a la vez). En este tipo de lenguaje, cuando se accede a una función mutex, si hay otro proceso en el método, los demás se ponen a la espera, y todo es gestionado limpiamente por el propio compilador. Incluso hay lenguajes con concurrencia que soportan un cambio de contexto "manual", que en el caso de Div/Fenix es la sentencia "frame" (en otros, como Java, es el método "yield").
La pega que se le podría poner a Div/Fenix como ejemplo de concurrencia es la misma que muchos lenguajes concurrentes modernos: la existencia de un "yield" o "frame" que de control al programador sobre los cambios de contexto han hecho que se pierda una característica de la programación concurrente que tradicionalmente se ha considerado inherente a la misma: su indeterminismo.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.