En general salen cosas interesantes, de momento me es muy complicado aprender a programar yo, en segundo lugar si aprendiera no tendría tiempo de hacerlo con lo cual estamos en la mismas, ahora mismo me estoy informando sobre lo que significa programar, eso es diferente a saber programar. Sabiendo lo que significa programar podré decirle al que contrate lo que quiero y en segundo lugar podré desarrollar un plan de trabajo.

Por lo que he leido, la mejor forma de programar es por modulos, es decir, ir creando paquetes o subprogramas casi independiente pero con relación unos con otros. Por ejemplo un modulo básico podría ser la interface, una vez realizado podría arrancar el juego y vería la interface claro que no podría hacer nada más sólo tedría un cascarón vacio. En segundo lugar iría creando los modulos, por ejemplo un segundo módulo sería el mapa, despues otro que sería las diferentes pestañas de producción diplomácia etc y por último el modulo de reglas y IA todos relacionados pero trabajados de forma independiente. ¿Es correcto?

Si es así, diseñaría un programa de trabajos por modulos, se ya está diseñado de antemano hasta el más mínimo detalle es trabajo que te ahorras después, lo que no puedes es empezar y después ir añadiendo las cosas que te gustan, no lo puedes hacer así no terminarías nunca. Es necesario especificarlo todo antes. Por ejemplo la unidad x se enfrenta a la unidad y ¿Qué variables se tendrán en cuenta? ¿Cómo se miden esan variables? ¿Que secuencia siguen? cúal se tiene en cuenta primero, el tiempo, el clima? especificando al milimetro todo eso te ahorras tiempo de programación con lo que la fase de diseño se convierte en la más importante.

Por tanto como productor del proyecto y guionista, más que saber programarlo yo, lo que necesito es saber hasta que punto de nivel de detalle en la simulación se puede llegar.

El tema está no sólo en que aprendas a programar y ver las dificultades que puede entrañas sino que el coste de un juego casero es inabordable, a no ser que te sobre el dinero claro y lo hagas por puro placer, lo suyo es que lo haga uno mismo y ver si hay suerte.

Te dejo un link que leí hace tiempo en el wargamer:

http://www.armchairgeneral.com/the-stat ... gaming.htm

Algo que me llamó muchísimo la atención cuando lo leí es que panther games esperaban vender 3.000 copias de su juego Conquest of the Aegean, y estamos hablando de uno de los mejores wargames que ha salido en los últimos años con numerosos premios en su haber.

No se como iría al final la cosa, pero de hecho su próximo juego de la serie en el frente del este, que ya hay una expectación tremenda y será un taquillazo para lo que suele ser en este tipo de juegos, está siendo aplazado cada dos por tres porque al tio no le llega para mantener al equipo de programadores (seis personas), le salió un trabajo para el ministerio de defensa australiano que es el que le da de comer, supongo que algún día saldrá el juego.... pero repito que estamos hablando de una de las mejores series dentro del mundillo del wargame.

Yo sinceramente no haría semejante desembolso pero bueno....

Aunque no he estudiado informática como mucha gente me dedico profesionalmente a ello. Al principio empece tirando lineas de código, luego a diseñar sistemas y desde hace un tiempo a dirigir proyectos. Aunque parezca lo + sencillo te aseguro que esto ultimo es lo + difícil (o al menos a mi me lo parece) y no te estoy hablando del trato con el cliente sino de estimar correctamente los plazos/esfuerzo requeridos , en cuantas fases/hitos dividir el proyecto (y en que consisten) , coordinar las diferentes tareas ...

Yo tengo bastantes años de experiencia programando/diseñando sistemas "científicos" o con una alta carga de ingeniería y aún así algunas veces (por suerte no demasiadas) lo que había previsto que tardase X acaba tardando en hacerse el doble , el triple o mas. Cuando uno construye una casa, autopista si la empresa tiene experiencia en ello pues puede estimar con un margen alto de confianza los costes asociados a la obra pero con el SW es harina de otro costal y salvo que uno haga un pequeño desarrollo (un juego no lo es ), la incertidumbre en la estimación es muy grande.

Al final equivocarse en un % no muy grande en el coste de desarrollo puede significar que un proyecto de beneficios o no, y mucha gente (las popias empresas) ha invertido/invierten mucho tiempo y dinero en intentar racionalizar/convertir en algo + o - científico la estimación del coste de un proyecto (sin demasiado exito en mi modesta opinión ) Personalmente, la mejor gente que he visto estimando esfuerzos/costes era gente con experiencia y con mucha intuición (sexto sentido o como le quieras llamar). Al final es + un arte que una ciencia y en cierto sentido se asemeja bastante a la economía, cuando esta intenta predecir los movimientos bursatiles: después del proyecto esta chupado explicar porque las cosas fueron bien o mal pero a priori es mas un acto de fe que otra cosa.

Leyendo tu descripción de como sería el sistema creo que confundes algunos conceptos básicos:
- Especificaciónde lo que debe hacer el sistema. Aqui se podrían incluir las reglas, formulas matemáticas, casos de uso para la interfaz, ....
- Arquitectura del programa. Dividir el programa en programas, subsistemas, modulos, clases, funciones ... , en definitiva cajitas que hacen cosas. Esta parte es realmente difícil y la debe hacer alguien que sepa de informática y con experiencia. No es suficiente decir que habra una interfaz, una IA, un motor de renderizado, .. o lo que sea. Esto es demasiado genérico y una descripción de demasiado alto nivel . Hay que definir realmente cual es la función exacta (a nivel de SW) de cada elemento, como intercambia información con los otros elementos (interfaces), como interactua con los demás ...
- Diseño detallado: A veces se detalla el comportamiento de cada función/parámetro, a veces no si el programa no es complejo, quien programa sabe de que va, tiene experiencia, no hay dinero/tiempo para hacer diseño detallados, ....

Esto es solo la fase de requisitos/diseño, luego hay la fase de codificación,pruebas, integración, validación, ..., puede que se haga en una sola fase o en varias fases (p.ej. hay un prototipo o no, hay una sola versión o hay N versiones con cada vez + funcionalidades, ..... ), ...

No quisiera desanimarte pero me parece bastante "temerario" embarcarse en una empresa de tal calibre si uno no tiene ningún tipo de experiencia en el ramo/nunca ha programado . En cualquier caso tomatelo como un simple consejo ya que cada cual es libre de hacer lo que uno cree más conveniente con su dinero/tiempo

Aún así y aunque no sepas programar, te propongo el siguiente ejercicio : aprender HTML/JavaScript (o Php o cualquier lenguaje de scripting) a nivel básico es relativamente sencillo y no debería tomarte demasiado tiempo. Una vez que controles lo necesario planteate desarrolar cualquier página/sistema que no sea una trivialidad(i.e. que no se haga en una tarde). Detalla todas las cosas ha hacer e intenta estimar cuanto tiempo crees que se va a tardar en cada una de ellas y ponte a ello. Si lo haces y acabas el proyectillo, te sorprenderás cuando releas lo que escribistes al principio

Y eso que es algo sencillo, que conoces/hay información ( programar páginas Web no es programación de IAs) y muchísimo menos complejo que un juego

Muchas gracias Sefirot y no te preocupes por darme caña Si ya me imaginaba yo que fácil no sería pero bueno, Roma no se construyo en hoy día. Yo empece a hacer mi juego hoy, y me ire a la cama sabiendo cosas que antes no sabía.

Me alegro de que te lo tomes bien

Desconozco lo complejo que sería el proyecto pero sin ir más lejos dos personas/hombre para todo un juego se me antoja demasiado poco.

Creo recordar que la persona que programa el motor de Ageod se tiró solo un par de años (o quizás más) desarrollando su motor y estamos hablando de alguien que se dedicaba profesionalmente a la informática (creo que desarrollaba programas para la industria farmaceutica o algo parecido), que ya había hechos sus pinitos en esto de los juegoss en plan hobby, que trabajaba junto a P. Tibaut

Pero el motor no es mas que la parte de SW que no se ve, luego hay que diseñar una interfaz gráfica, diseñar escenarios, adaptar el motor al juego (p.ej. Ageod llevan + de un año añadiendo un modulo diplomático a su juego y explicaron que en el Napoleon Campaigns no lo habían añadido porque era demasiado costoso), integrar las cajitas, testearlo, ....

Por ejemplo es algo que la gente suele despreciar/no suele tener demasiado en cuenta pero si quieres que el producto tenga un mínimo de calidad el tiempo de verificación/validación del producto suele ser como mínimo igual al tiempo de desarrollo.


Si al final estas decidido ha embarcarte en ello, leete cosas sobre Ingenieria del SW aunque solo sea para tener una idea de las cosas ha hacer en un proyecto SW.