Y esta argumentacion si que es Gold! creo que has dado en el clavo.
Como comentario adicional, creo que entiendo el porque no sabemos que va a tener ED al final y si lo sabemos para SC. Desde mi punto de vista tiene que ver con el modelo de desarrollo que ha elegido cada uno.
En ingenieria de software, el modelo de desarrollo de ED es un modelo iterativo, el modelo de SC es un modelo en cascada. En el modelo en cascada primero analizas y disenyas el producto hasta el mas minimo detalle, luego viene la fase de desarrollo donde se construye el producto con todas y cada una de las funcionalidades que se han disenyado, lugo se entra en la fase de pruebas, donde se prueba todo y luego esta el producto acabado. En el modelo iterativo se disenya-desarrolla-prueba-entrega una version minima de una parte del producto final, acabada esta primera iteracion, se recoge el feedback del cliente y con esto, el codigo de la anterior iteracion y los objetivos en mente, se entra en una segunda iteracion donde se disenya-desarrolla-prueba-entrega ...
Una de las normas del proceso iterativo es que, aunque tengas un objetivo a largo plazo en mente, en el momento actual lo unico que importa es el siguiente escalon. Por ello Frontier puede suponer e incluso afirmar de forma vaga (como han hecho a menudo) que van a haber patas y planetas con atmosfera y vida. Pero como no son el siguiente escalon, no estan ni siquiera definidos. La ventaja del modelo iterativo es que es flexible. Si en el momento se descubre que lo que realmente interesa es cazar bichos en superficie, pues eso es lo que se hara. Como muestra, recientemente Frontier ha decidido que el siguiente escalon es darle profundidad a las mecanicas existentes (no sabemos si todas o solo algunas). Con este modelo de desarrollo es normal que no puedan decirte que van a estar programando dentro de dos anyos, y eso es una desventaja, pero si lo hiciesen estarian encarrilando el proyecto y perdiendo flexibilidad.
Por su lado SC con su modelo en cascada ya ha pasado las fases de analisis y disenyo, y ya sabe mas o menos todo lo que aspira a tener y los detalles de cada apartado. Esto tiene la ventaja de que pueden comunicarlo y publicitarlo y darle bombo. Ahora su trabajo es "simplemente" desarrollar el proyecto para que sea tal cual se ha decidido en el disenyo.
A largo plazo, si todo va bien, SC y ED tendran en unos anyos un juego completo y con profundidad de mecanicas a la par. Si todo va bien. La ventaja de ED es que puede maniobrar por el camino para alinear su producto con lo que quiere el cliente, la desventaja es que clientes pueden cansarse o acostumbrarse al juego de forma que no noten el esfurzo hecho durante el camino. La ventaja de SC es que si logra acertar con lo que esperan los clientes, el hype generado jugara a su favor y sera super exitoso y brillante, la desventaja es que si tras tanto tiempo su diesenyo era equivocado y las sensaciones que da el juego no logran cumplir con las expectativas, le van a caer golpes como panes.
Discusión de "traca" informática, me encanta. [big grin]
No estoy totalmente de acuerdo con esto. A ver si encuentro algo de documentación, pero recuerdo que no por tener los requisitos desde el principio es cascada, es un tema más de como se gestionan los cambios en los requisitos durante el desarrollo. Lo principal de el modelo en cascada es la rigidez ante el cambio y el hecho que tener todos los requisitos desde el principio es algo prácticamente obligatorio si quieres que funcione (de ahí lo que algunos hacían de, una vez obtenidos requisitos, ponerlos en contrato y si el cliente cambiaba requisitos cuando* se diese cuenta que se había equivocado, los retrasos estaban justificados contractualmente). Pero no por tener los requisitos desde el principio ya no eres un modelo iterativo. La frase clave de los modelos iterativos es que los requisitos no son necesarios desde el principio, pero si los tienes, genial: total, ya sabemos que van a cambiar si o si. [big grin][big grin]
* => cuando, y no si. [big grin]
Para mi, la diferencia fundamental es que Elite tiene, pero no ha publicado los requisitos (que provienen de las features que quieren que tenga el juego), de forma que tenga flexibilidad para ir descartando o repriorizando las features que quiere sacar en cada momento sin que nadie pueda criticarles*, y Star Citizen, en teoría, si que las ha publicado (y luego si tiene que pegar recortes o mejorar algunas cosas, lo hace, sin mayor problema, como se ha visto como ha dicho michifu con los anillos de embarque, o con la influencia de la carga en el modelo de vuelo de las naves, que lo va a haber, pero no tan complejo como se pensaba), lo que les resta margen de maniobra de cara a hacer grandes cambios en los mismos, porque entonces los backers se les echarían encima (y con razón).
* de hecho esta es una de las críticas de Frontier en reddit ultimamente, porque por lo que se entendió de algo que dijo uno de los diseñadores de Frontier, "si una feature no tiene seguimiento no se sigue trabajando en ella" (cita no textual, pero creo que cercana, si estoy equivocado, que alguien me corrija). A mi no me parece tampoco mal del todo que hagan así: si me parece mal que abandonen las features (sobre todo si es un abandono permanente), pero la repriorización por cosas más urgentes me parece perfecta... siempre que lo explicasen, que es algo en lo que frontier tiende a ser opaca.
Luego después, la filosofía de releases si que es distinta, porque Elite entrega, en general, versiones finales y funcionales (y muy pulidas, habitualmente) incrementales (muy propias de un modelo iterativo, efectivamente), y SC de momento tiene una alfa apenas funcional cuyas iteraciones no es que hayan expandido mucho lo que había, y lo que decían era que apuntaban a una versión final con todo. La 3.0 para mi de hecho marca más un viraje a un ciclo de releases más cercano a lo iterativo, más que nada, porque independientemente del conjunto de features que metan, a partir de la 3.0, EN TEORÍA, cada versión irá iterando sobre eso y añadiendo features más funcionales que hasta ahora (cosas como por ejemplo profesiones completas o versiones representativas de las mismas).
Todo esto en mi opinión, of course. Aparte, repito, creo que en el día a día ambos siguen metodologías ágiles. De frontier no he leído nada, pero supongo que sí, y en videos de CIG ya son unos cuantos donde oigo mención a Sprints y cosillas así, lo que sugiere SCRUM o algo parecido: bueno, o eso, o marketing para developers.
