Star Citizen #HG

RECORDATORIO:

ESTE HILO ES PARA SEGUIR EL DESARROLLO Y AVANCE DE STAR CITIZEN. PARA CRITICAR EL DESARROLLO; P2W, FECHAS DE LANZAMIENTO, BUGS Y DEMÁS, PODÉIS IR A ESTE.

En caso contrario el castigo puede conllevar un Punish.

¿Diferencias de un hilo u otro?

  • Este hilo es para hablar de temas ceñidos a la actualidad del juego, noticias, dudas, etc. Y aunque el debate sano siempre es bienvenido, la intención es dejar el hilo limpio para tal propósito. Por lo tanto la moderación en este hilo será más estricta.
  • El hilo de Off-Development está para soltarse más, donde la moderación será menos estricta y se permite tocar, criticar o debatir temas que eran fruto de discusiones que ensuciaban el principal objetivo de este hilo, incluyendo todo aquello relacionado con el desarrollo. Allí vale más "todo", exceptuando faltas de respeto y las normas generales de Mediavida.

DATOS DE INTERÉS (Actualizado 15/11/2018)

PINCHA PARA DESPLEGAR
X

#27384 Hombre, para ser justos, eso tiene pinta de ser una herencia del CryEngine.

Se supone que para la 3.0 ya tendremos un Launcher decente.

RaNGo

Claro, yo pienso tmb que una vez tengan ya el Launcher, los parches no tardarán tanto en venir... por eso querrán dejarlo todo ya arreglado xD

Rigal01

6 2 respuestas
Resa

#27393 En cualquier proyecto tienes ese tipo de problemas y para eso hay gente que se dedica exclusivamente a hacer schedules.

Los estimates no son fechas que dices a ver si cumples, tal y cono dice ahi, los estimates son compromisos que te marcas con el cliente (cosa que no aplica en este juego) y con todo el resto de partes de tu equipo. Esto ultimo incluye desde asignar recursos economicos (gente y subcontrataciones), interconexion con otros equipos que se dedican a otras cosas y programacion de tareas futuras.

Respecto a que no se puede saber cuanto se puede tardar en resolver un bug, eso es una patraña. Hasta este momento se han resuelto seguramente miles de bugs, y de ahi se pueden extraer estadisticas fiables de cuanto vas a tardar en funcion de su gravedad, cosas a las que afecta, facilidad de duplicarlo... Por supuesto siempre habra alguna bomba que te joda la vida y el planning, pero eso es que en algun bug (muy pocos conparados con el total) te jode el planning, no que los bugs por ser bugs son inexcrutables.

Todo esto es para decir que lo mas seguro es que manejen un planning interno realista y a la gentw le enseñen el mundo de la piruleta.

Es imposible que internamente manejen el planning que tienen en la web, ya que sin un plan minimamente fiable estas desperdiciando millones de euros en descoordinaciones internas y quiero creer que los managers no sean tan incompetentes.

7 1 respuesta
LimiT-SC

A todos los productores de juegos expertos en schedules que pululan últimamente por el foro. A toda esa gente que sabe como planificar las tareas y hacer juegos, os recuerdo que en la web de Cloud imperium buscan productores.

Animo!

https://cloudimperiumgames.com/jobs

4 1 respuesta
Resa

#27395 Gracias pero ya trabajo en planificacion y control de costes en una empresa que se dedica a algo que me apasiona mas que hacer juegos (me encanta jugar, pero la informatica no me atrae mucho). Cuando he puesto todo el tocho de antes es porque algo se del tema.

Independientemente de mi experiencia profesional, como argumento tu post no es gran cosa.

7
General1492

#27394 Pues de planificación sabrás, pero de programación se ve que no tienes ni idea cuando dices: "Respecto a que no se puede saber cuanto se puede tardar en resolver un bug, eso es una patraña."
Yo si me dedico a la programación, y te digo que puedes hacer las estadísticas que quieras, que no vas a acertar cuanto se tarda en resolver un bug.

2 2 respuestas
eimdal

#27397 Pues no debes de ser muy buen programador la verdad, porque hacer una estimación aproximada de cuantos vas a durar en resolver un bug es parte del trabajo (Y las estimación si eres buen programador se suelen cumplir).

1 1 respuesta
Resa

#27397 Antes de nada gracias por haber tomado mi post en serio y argumentar tu respuesta.

En 10 minutos buscando en google:
https://www.google.es/url?sa=t&source=web&rct=j&url=http://citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.83.1086%26rep%3Drep1%26type%3Dpdf&ved=0ahUKEwillPadqrHVAhVCL1AKHdRBBQkQFggcMAA&usg=AFQjCNGPPNDTZqK9jnRl9VMmBswdQogRtQ

Basicamente es el enfoque estadistico que comentaba antes aplicado a informatica. Como he dichi antes ,claro que un bug se puede salir de la estadistica, ya que es estadistica, no ver el futuro.

E incluso si los bugs no se amoldan a una estadistica, se tendria que aplicar algun enfoque para su gestion y no decir, se solucionara cuando se solucione

#27398 Tampoco hay que faltar. Puede dedicarse a la programacion, ser un gran tecnico y no dedicarse a gestionar recursos y ser un gran profesional.

6 1 respuesta
Carrefour

Normal que en su web busquen productores, los actuales no dan una con mas de 8 meses de retrasos.

clethaw

Para todo lo demás, usaremos el esto no se había hecho nunca o los famosos estándares de calidad :D

kappa

2
X

#27393 Me parece genial todo eso, pero no exculpa nada.

Estoy cansado de leer lo difícil que es hacer una estimación de una tarea.
Antes que nada, decir que si tan difícil es estimar una tarea, que no saquen estimaciones públicas. Y con esto no me refiero a los calendarios de tiempos que están sacando desde hace unos meses, sino a Roberts diciendo que "la 3.0 esperan sacarla a finales de año". Sin esa dichosa frase, todo este jaleo no existiría, porque lo que le jode a la gente no es que se retrase dos meses, es que se retrase dos meses después de "retrasarse" 5. La gente piensa que le toman el pelo. Si en vez de eso, Roberts hubiera adoptado la táctica Blizzard o Valve de "estará cuando esté" mientras enseñan progreso en los ATV, la gente estaría más tranquila. Pero claro, eso hubiera hecho que se vendieran menos naves durante la GC del año pasado.

Dicho esto.

Estimar tareas es complicado, sí. Pero no es imposible como parece serlo viendo la agenda de producción. Dentro de la propia metodología SCRUM, que es la que se supone que usa CIG internamente hay mecanismos para ir afilando las estimaciones. Hay mecanismos para evitar que una estimación se salga de madre. Hay mecanismos para preveer un desvío importante en una estimación de una tarea y "atacar" ese problema a tiempo. Hay mecanismos incluso para tener la calidad de estimación de tareas de cada equipo, y adaptar las estimaciones futuras de ese equipo en base a esa calidad.

"Estimar el arreglo de bugs es imposible"
Esto directamente es risible.

Obviamente siempre hay algo concreto que se te puede ir de madre. Un bug que pensabas que era algo simple y lo estimas un día, se te va a una semana. Un desarrollo que esperabas tener una semana, se te va a un mes. Pero no es lo normal, o no debería de serlo. Si a mi equipo, el trabajo que hemos estimado en 3 meses se nos va a 8, directamente nos despiden.

7
Drasiel

Creo que el tema de los bugs es una discusión algo irrelevante bajo mi punto de vista.
Para mi lo vital de la situación es que el proyecto el año pasado por estas fechas estaba sufriendo muchas críticas por la falta de avances. Entonces por agosto de 2016, creo recordar, Chris Roberts saca el famoso ingame de la futura 3.0, todos alucinamos, más cuando nos dice que podremos jugarla para finales de año.

Estoy totalmente seguro que Roberts sabía que era imposible sacarlo en esos plazos y porque mentir entonces? por el vil metal evidentemente, durante muchos meses el nivel de defensores volvió a subir y las críticas ya no tenían base.

Tenemos a una persona la que no le importa mentir de la forma más descarada si con eso piensa que puede mantener el proyecto a flote. Ademas es algo que ya ha hecho de forma reiterada (Star Marine)

Puede que sea un grandísimo diseñador y programador de videojuegos, pero como gestor y director del proyecto para mi lo esta haciendo rematadamente mal. Alguien que ya ha mentido varias veces consecutivas porque le vamos a creer nada de lo que diga de ahora en adelante?

2 1 respuesta
Postmortem
#27403Drasiel:

gestor y director del proyecto para mi lo esta haciendo rematadamente mal

Tal vez su tarea sea mentir para que Star Citizen pueda ser una realidad en los aún largos años que nos quedan.

Si un buen gestor dijera la verdad, tal vez no habría más juego que desarrollar.

1 respuesta
eondev

#27404 No. Yo hubiese preferido un "Estará cuando tenga que estar" que mentir, aunque reconozco que mentir tiene sus partes positivas como todo. Al final supongo que habrá escogido la opción que más les ha convenido y punto.

Lo importante ahora es que hay HYPE por fliparsela por algún cañón con la nave joder, GANACAS

A

Que nos están mintiendo desde el primer Kickstarter es algo que sabemos los que tenemos un mínimo de mundo recorrido, por mucho que los CM de postal quieran maquillar por aquí.

Cualquiera que haya trabajado en una empresa medio sería que se dedique a la producción de algo y que no sea el panadero de la esquina sabe que se mide todo, vamos se hacen kpis hasta para cargar, ellos controlan los tiempos reales si no un proyecto que arrastra a tanta gente seria ingobernable e irrealizable.

1 1 respuesta
Adamanter

Con tanto "productor" que hay por aquí no sé a qué esperan para enseñarle a Chris Roberts a hacer videjuegos en lugar de perder el tiempo repitiendo loa mismas tonterías sin sentido desde 2012.

Salu2 :)

3 1 respuesta
B

#27407 No esperábamos menos de ti, que calificar de "tonterias sin sentido" las experiencias y opiniones de otros compañeros del foro. Muy digno.

8
grafito

¿Hace cuanto que no habláis de STAR CITIZEN?

Digo HABLAR DEL JUEGO.
No intentar demostrar al mundo la razón que tenéis.
Lo mucho que nos engañan.
Lo bien que lo haríais vosotros.
La poca razón que tienen los demás.
VUESTRA SUPERIORIDAD.

¿Hace cuanto que no habláis de STAR CITIZEN?

3 2 respuestas
eondev

#27409 Cuando haya algo nuevo ;/

6 1 respuesta
B

#27406 El que no ha trabajado en nada serio eres tú. KPI.. Tu si tienes un buen hit ratio basado en tu kpi.. 1 tontería por cada post.. Ni me molestó.. en fin... NO.

CaLaTa

Así, rebatiendo con argumentos.

SkullraiN

Lo del schedule se os ha ido de las manos.
we ALWAYS extend timelines, significa os voy a timar cada viernes.

Y ya los coders que saben cuanto van a tardar en reparar un bug , aún antes de encontrarlos, haciendo medias estadísticas de tiempo...
Lo mismo tardas en leer 1000 lineas de código que 10.
Lo mismo tardas en repasar 10 vértices que 100.
Una chapuza de cálculos me vas a perdonar.

Dejar de generalizar vuestra experiencia en una fabrica de chocolate con la creación de vídeojuegos por favor...

Argumentos? Lleváis 100 páginas con lo mismo, leer atrás.

3
X

#27409 Lo mismo que #27410

Por lo demás, a mí lo sí que me apasiona es la gente que parece tener una experiencia brutal en ingeniería del software para decir mamarrachadas. Por mi parte, ya he discutido bastante. Nos vemos en la 3.0.

N3j0

Me flipa mucho la peña que dice que el arreglo de bugs en desarrollo e implantación es previsible. Por favor, a esa gente que me mande un privado y me digan en la PRACTICA como se hace, porque la teoría yo también me la se, y ya te digo que, o no se cumple o los plazos que te dice la teoría son tan exageradamente altos, que el proyecto se hace inviable.
En mi caso se trabaja con estimaciones, calculadas en base a una teoría y ajustadas para hacer viable el proyecto. Si todo va bien y la tecnología es conocida, es raro que se produzcan retrasos, ahora bien, si estas desarrollando algo nuevo y no probado, es sumamente complicado acertar en la estimación, más que nada por que si aplicas la teoría a raja tabla los tiempos de finalización hacen el proyecto inviable, y, o no realizas el proyecto o "te arriesgas" con la estimación.
La gente que está trabajando en SC está desarrollando algo increíble e impensable....incluso para ellos cuando empezaron el proyecto y nosotros, con nuestro dinero, les estamos dando la oportunidad de poder hacerlo. Lo he dicho más de una vez....disfruten del camino y parafraseando a Gloria Fuentes "La gente tiene prisa, porque no sabe dónde va, la que sabe dónde va, va despacio, para paladear el ir llegando"
Saludos.

6 1 respuesta
X

#27415 Normalmente, y hablando de un proyecto que conozcas, cuando te asignan un bug no "intuyes" a qué módulo(s) puede afectar y de dónde podría venir el problema? Con un par de horas con él no puedes intuir si va a ser más o menos complejo de arreglar?

Y en un sprint utilizando SCRUM no tenéis un porcentaje de puntos/horas totales asignadas a los defects justamente para no interferir en las propias tareas de este?

Y ojo, ya estoy discutiendo por discutir, que, repito, el principal problema no son las agendas de producción, es el bocachancla de Roberts.

1 respuesta
Kretaro

Yo si no he entendido mal el problema no radica en lo que se tarda en resolver los bugs, que es de lo que estais hablando, sino en lo dificil que estimar el numero de bugs que aparecen, dicen que la 3.0 ha traído un NUMERO de errores mayor del que esperaban, La verdad que en mi caso los retrasos no me afectan, desde que apoye el proyecto desde el inicio entiendo que pague por un proyecto no por un producto asi que para mi es mas importante el proceso del proyecto que el producto en si. Me gusta ver que el proyecto es ambicioso y entiendo que eso conlleva problemas y retrasos.No puedo negarle que desde que empezo el proyecto yo solo he visto mejoras, mejoras de comunicacion, mejoras en la forma de trabajo, mejoras en el equipo, no soy un esceptico, por eso apoye a CR, creo que Chris ROberts se lo cree, cree en su juego y no en elaborar conspiraciones con cientos de millones.

1
D

Ami lo único que me jode es el tema del lti y lo de los ccu ,por lo de mas cuando compre el juego ya sabía donde me metía y lo que se puede llegar a tardar en un proyecto y mas como este ,me gustaría que fuera todo mas rápido como a todo el mundo .

N3j0

#27416 Si claro, y como tu dices sabes a que te va a afectar, pero el problema es cuantificar ese "mas o menos" que mencionas. Siempre en un proyecto tienes previsto ese tipo de incidencias y asignas previamente recursos a ellas. Pero , como digo, cuando trabajas con tecnologías no conocidas, no es nada nada sencillo acertar en esa previsión y si aplicas la teoría, los recursos asignados a esas incidencias (ocurran o no) serian tan elevados que no hacen rentable el proyecto...por eso se ajustan a ese "mas o menos"...pero ya te digo que no es nada sencillo acertar.

SkullraiN

Habláis de los bugs como si se supieran de sobra cuales son, te haces la previsión y a ver si hay suerte y nos acercamos.
Enserio explicarme como podéis hacer una estimación de lo que vais a tardar en corregir un error que aún ni se ha producido.

La única manera de hacer una estimación es sabiendo a que te enfrentas, y señores, eso solo ocurre cuando falla.

1