#60 lo mismo digo, aunque solo sea de pascal, c y c++ xD
Pues lo dicho, ahora mismo necesito gente que ya haya desarollado otros proyectos grandes o sea capaz de ayudarme un poco con las especificaciones técnicas. Necesito bastante ayuda (Sobre todo otro punto de vista) con la planificación del proyecto, desde discutir un poco las características a pensar por dónde es mejor empezar.
Programadores de C++ también harán falta 
En cuanto consiga más o menos tener las ideas claras, empiezo a programar para mostrar un poco la idea.
#64 Dibujos , diagramas, ayudan mas que codigo para mostrar ideas.
Por dnd es mejor empezar, pues supongo que por los objetivos del diseño , portable, moddable, modulable, etc.. y como conseguirlo.
#65, si, si los dibujos y diagramas es lo que estoy haciendo ahora. En cuanto lo tenga, será cuando me ponga a trabajar. Lo que necesito es a alguien que me corrija y aporte nuevas ideas, porque puedo pensar que algo está bien hecho/es una buena idea, y no serlo tanto porque no me he dado cuenta de algo que me podría haber dicho otro. Por eso es bueno hacerlo entre varias personas.
#66 Subelo a ver, con explicaciones y entre todos cojes lo que mas te guste de las opiniones, nose, esque a mi me keda un poco grande hacer el diseño de esto cuando no he hecho nada grandecito.. y menos bien. xD
Con que programa lo haces ? Usas UML o algo ? A mano ? Sobre que proyecto ? Porque se han dicho muchas cosas y decidido nada. Nose.. xD
Creo que se esta trabajando en el juego de estrategia por turnos moddable. Con scripts, C++ y alguna libreria grafica (no se cual la verdad)
Bueno,
Perdonad el retraso en contestar.
Vamos a INTENTAR (y recalco lo de intentar jejeje) hacer la opción de un juego basado en turnos, en vista que elkaod es el usuario que creo q tiene más claro los conceptos. Por ello mismo, él será el lider del proyecto.
A partir de aquí, me sumo para aportar lo q pueda. Conozco C++, aunque hace varios años que no programo con él. De librería gráficas conozco por encima varias, pero nunca he trabajado con ninguna por lo que una vez se decida cual se va a utilizar, me pondré a "empollar" lo q sea.
Por otra parte, tengo 0 experiencia de trabajos en grupo, ya que donde trabajo, lo hago solo, por lo que no suelo hacer especificación de requisitos y me salto muchísimas partes de la ingenieria del software. Por lo tanto, ahí es posible que no pueda colaborar, pero quizás pueda colaborar con ideas de como realizar ciertas partes, etc.
Bueno, nada mas, elkaod, si necesitas ponerte en contacto conmigo, pídeme el MSN por privado.
Creo que esta claro:
elkaoD dijo:
"Sólo de pensar las posibilidades de modificación que brinda AngelScript siento pequeños orgasmos... "
#70 De la esp. de requisitos al no tener cliente fisico, tendremos que inventarnoslos nosotros, hasta donde queremos llegar.
por que no creais un canal en el irc y hablais en tiempo real y no tener que esperar por aqui a que se firme para avanzar...
Acordaros de publicar en el foro las últimas decisiones y novedades, para que nos vayamos enterando todos los que no podemos andar por el IRC a todas horas.
¡Saludos!
Yo en cuanto desarrolleis un organigrama, boceto o lo que sea xD, me meto en la parte en la que mas pueda aportar explorando algo que no haya hecho antes.
Al final, yo creo que el juego por turnos puede ser bastante factible. Con que sea una especie de BattleIsle (la filosofia de un juego por turnos sencillo, no que sea el mismo juego) nos podemos dar con un canto en los dientes.
Aunque solo sea por practicar el tema de manejo de animaciones etc, que pocas veces en el mundo laboral podemos hacer xD
Como dice #77 es algo que rara vez vamos a programar los que curramos de programadores. Yo estoy hasta los cojones de las select, update y demás polladas del software de gestión. Algo así me ilusionaría. El problema es el tiempo, como siempre... Seguiré el proyecto de cerca y lo mismo si puedo colaborar aunque sea una pequeña parte, lo haré.
¿En qué red de IRC os gustaría el canal? A mí me da igual Hispano o QuakeNET, no entro a ninguno apenas... aunque empezaría a entrar por el proyecto.
De momento estoy en #Proyecto.ForoDEV en irc.quakenet.org pero me da que nos vamos al Hispano.
EDIT: Canal #Proyecto.ForoDEV en irc.irc-hispano.org ya creado.
EDIT2: Hemos hablado mucho por el IRC y se ha avanzado bastante en la planificación. Juanaka ya está con papel y lapiz preparando clases y todo xDDD Soltrac en "breves" subirá una conversación con lo hablado donde explico todo como lo tengo pensado.
Seuron, algo así se está preparando. Yo tenía pensado el juego en plan tileado de cuadrados, no hexagonal, pero hacer que soporte ambos (O incluso isométrico) no debe ser muy difícil. Es sólo la forma de representarlo.
Ahora mismo se necesita alguien que se encargue de lo que es SourceForge. Vamos, el administrador del tracker, SVN y demás, que si todo va bien empieza a fluir código dentro de poco. También se necesitan programadores de C++ también, y de C si pueden hacer pequeños aportes también. Diseñadores no, de momento vamos a dedicarnos al motor exclusivamente hasta que tengamos algo sobre lo que trabajar.
PD: Juanaka y Soltrac, a partir de ahora al Hispano.
Ya me ire pasando por el irc a ver como evoluciona.
Pero para hacer clases habria q terminar de perfilar como seria el juego no ? XD
cada unidad ganara experiencia ?
o se dara dinero al ganador para poder comprar/mejorar unidades ?
no se si eso ya se ha hablado :/
Yo trabajo de desarrollador java, ya que c++ tambien es poo y hice C en la universidad supongo que con bajarme 4 tutoriales de c++ y ponerme un poco al dia servirá xD
Bueno, me he encargado de dar de alta el proyecto en sourceforge:
Nombre: mediavida-project
Unix-name: mv-project
Acceso por http://sourceforge.net/projects/mv-project/
Descripción publica:
Open Source project designed and coded by members of the forum http://www.mediavida.com leaded by user kaoD. Estrategy turn-based game compiled in C++.
Para que nos lo hosteen he tenido que aceptar una de las licencias, y he aceptado la mas tipica GNU General Public Licence(GPL).
Actualmente está en pending, cuando esté activo os vais apuntando a sourceforge para daros de alta como developers :3
Yo de momento estoy con un borrador de lo q seria un diagrama de clases chapucero.
Tengo un pequeño lio en el ceporro del copon pero weno, resumo un poco lo que se ha hablado:
Se ha hablado de hacerlo orientado a eventos, es decir se tiene una lista de eventos que se van mirando y se van llamando a funciones que los traten. Digo yo que sera como los eventos tipicos, tipo y source, y asi se trata desde el objeto en cuestion que lo provoca. Pero eso no se.
Tambien se ha hablado un poco de que tendra cinematicas para ponerle historia, me dijo el nombre de quien queria hacerlas pero no recuerdo bien, solo q tb hay q programarse la clase cinematica para hacerle un play() del copon. ^^
Ninja edit :\
Lo otro es algo ya mas de diseño, se trata de una clase Entidad con Propiedades. Explico en que ha quedado la cosa.
Entidad es cualquier objeto que pueda pertenecer al ejercito de un jugador, es decir, tanto edificios como unidades como barcos o aviones o lo que cualquier persona se quiera inventar en un mod del juego.
Propiedad sera un atributo modificador del comportamiento de la clase Entidad, quiero decir, una entidad tendra una serie de atributos, por ejemplo:
Entonces con este tipo de relacion Entidad - Propiedad, podemos definirnos cualquier unidad, en la clase entidad hay un atributo que dice si es Estatico/Movible y otro para Terrestre/Aereo/Maritimo [Lo que es mas concreto es todo de mi borrador eh], pero los conceptos son esos.
Los mapas se cargan desde un fichero, para poder hacer despues una aplicacion que cree mapas y eso, pero vamos q es lo de menos, la cosa es tener informacion del mapa en un fichero para cargarlo...
Problemas q me han surgido:
Tenia pensado tener en la clase mapa todas las posiciones de la pantalla, y que cada posicion tubiera en caso de estar ocupada a la entidad que lo ocupa, el problema es que desde la entidad no se sabe su posicion para moverse :S , por lo que estariamos en que la posicion tiene al objeto entidad y la entidad al objeto posicion, y eso explota seguro xD. Nose como arreglar eso, aver si algun avispao me entiende y si ademas lo soluciona pues mejor xD
PD:
No puedo entrar al proyecto en sf:
Permission Denied
Access to this page is restricted (either to project members or to project administrators) and you do not meet the requirements to access this page. Please contact the administrator of this project for further assistance.
#86 creo que te has apresurado a abrir el proyecto en SourceForge, que necesitamos responsables pero no tener el proyecto ya abierto (Más que nada porque dudo que se acabe llamando MV-Project xD) Aún así, ya que has abierto ese pues se usa, así que avisa si lo aceptan y tal
#88 Yo creo que lo estás enfocando mal, se puede hacer que cada entidad de no-terreno tenga un x y un y que designan donde está. Luego las entidad terreno si que posée las entidades de no-terreno. No sé si me explico, por IRC es más fácil xD
PD: Las entidades tambien deberían poder no pertenecer a nadie, es decir, estar libres.
EDIT: Estoy leyendo lo que se ha dicho por el IRC en mi ausencia. Reshnak, ya que has trabajado con sockets, vendrías más que bien para el código de red. ¿Te ves con fuerzas? Si además sabes usar los sockets de UNIX ya que ni pintado.
Lo de las imagenes comento lo que tengo pensado. Lo que es el grueso del juego se pondría en la carpeta mods (Por ejemplo.) Dentro de esta cada subcarpeta sería un mod, con su propia jerarquía, etc. Luego, para cargar imagenes, cada entidad visible debería tener una. Por lo tanto, al crear la entidad habrá un argumento del tipo "/images/units/tank.png". Se puede hacer un .pak de las carpetas por comodidad, pero de momento... Las animaciones no son más que imágenes en cadena. Y lo mismo con los controles de la GUI.
Lo que han comentado del XML, ya lo había pensado pero no mucho, y la verdad tienes razón. Es otra cosa que hay que mirarse lo de la EntityFactory, porque puede venir bien para definir las unidades. ¡Además hay millones de librerías libres para tratar XML! Por ejemplo, TinyXML http://www.gamedev.net/reference/articles/article2159.asp
http://www.gamedev.net/reference/programming/features/enginuity1/ <- El ensayo sobre engines que comentaba. Es buenísimo, tiene 5 partes y todas dignas de leer.
http://www.gamedev.net/reference/articles/article2172.asp <- Puede ser útil.
GameDEV es la ostia, en serio, hay que leer mucho de ahí.
para lo del mapa yo habia pensado en una cosilla:
El mapeado está definido en una matriz[x][x] de tipo Terreno (por ejemplo)
Y las entidades esten mapeadas encima con una multilista (lo suyo seria indexar las entidades con un identificador unico y acceder por hashing, si lo hicieramos en plan civilization con scroll con un mapa bastante basto x > 500, si lo hacemos en plan simplote con otra matriz[x][x] de tipo Entidad sobraria). Si usamos acceso por hashing podemos acceder a nuestras entidades con un coste muy bajo y no tendriamos que guardar informacion redundante en la entidad. Aqui ya es decision de diseño(memoria - tiempo) (ver si las zonas de excedentes de las tablas de hash superan en memoria al guardado de información redundante de las posiciones en cada entidad)
Lo de los valores de variables decrecientes, habria que poner otro parametro, el decrecimiento, no todo el mundo querrá que se pierda una unidad por turno, alomejor se quiere perder 50 xD
En cuanto a las propiedades de las entidades, propondria una lista de Atributos (clase atributo) con acceso directo por hash, transformando el string en hashcode obtendremos más rapido el valor del atributo. En principio esto no deberia hacer falta pero ya que tratamos scripts, y con maquinas virtuales nos interesa que lo que pida el script lo reciva con un coste constante.
No puedes entrar al proyecto de sf porque todavia no ha estado aceptado 
ya os avisaré
Si tambien vamos a poner audio, tendremos que relacionar sonidos con acciones, por eso propuse el XML, se lee mucho mas rapido un fichero de texto que un script interpretado por una maquina virtual, y más viendo ahora todo el material que vamos a tener que relacionar en el XML. El script ya tiene suficiente que tiene que controlar las acciones cuando pulsemos un evento, y como dijo alguien en el log (sorry pero no me acuerdo XD) la cosa seria implementar el patron observer y crear listas de "escuchadores".
LLega lo doloroso, hilos y sincronismo, creo que este proyecto apunta directamente a esto porque sino la comunicacion por sockets será una tarea ardua(imposible mas bien) si solo usamos programación secuencial(el juego se bloqueará irremediablemente en medio de una partida online). Mi experiencia con sockets no ha pasado de probar un chat multiusuario en LAN, asi que la cosa primero seria provarlo en lan y luego hacer las modificaciones para pasar por routers y todas esas polladas.
