Actualizaciones, un retraso en el juego?

[takola]

Originally Posted by Xephandor

No concuerdo. En los sistemas Unix lo que se da a conocer generalmente de una aplicación es su modo de uso y configuración, pero no siempre el funcionamiento interno... Eso es de los sistemas GNU. POSIX define un comportamiento.

Sep, en los privativos no se da informacion interna. En cambio se dan extensisimos manuales, APIs etc. Pero no me referia a ese parte ya que hablamos de un juego y no de una libreria de programacion o lo que sea. Me referia mas al tratamiento de bugs.

Aun cuando es habitual no dar informacion sobre ellos mientras no se parcheen suele haber Full Disclosures tras el parcheo, aviso de que fallaba y porque fallaba y como solucionarlo. En NGD se oculta incluso el hecho de haber solucionado bugs. Un ejemplo no grave y que ocurrio hace poco fue el del duplicado de nombres de clan. Kailer informo de que se estaba trabajando en ello, pero tras haberlo parcheado no hay informacion por ningun lado. Y lo mismo ocurre con muchisimos bugs, lo que crea una situacion de continua incertidumbre. Por ejemplo, esta introspectiva arreglado o no? Tras la 1.0 se reporto el problema, y si se quiere ver si se arreglo o no hay que probarlo tras cada parcheo ya que es muy habitual no informar sobre ese tipo de arreglos.

Supongo que es lo mismo que con Microsoft: cuando menos bugs reconozcamos mejor sensacion de seguridad y seriedad damos. Afirmacion con la que no concuerdo para nada. Lo unico que se consigue de esa forma es matener dudas e incertidumbres durante un tiempo indefinido en vez de acabar con ellos tajantemente al publicar que se resolvieron, a la vez que se da una pobrisima imagen de seriedad en cuanto se ve lo que ocurre.

Puede que a primera vista brille, pero al mirar debajo de la manta se ve toda la porqueria que hay.

Originally Posted by Xephandor

Los sistemas Unix requieren que algo esté estable para mandarlo a producción porque no son un juguete. Aclaré en mi anterior post que ese debería ser el modo (para mí) a adoptar.

Cualquier software con el que se pretende mantener un negocio deberia de requerir que lo que entre en produccion sea algo estable, aun siendo un juego y no el kernel de un controlador de misiles. Eso seria seriedad hacia el proyecto y hacia los usuarios. En NGD en cambio se prefiere perjudicar al usuario final mientras se testea en produccion. Es lo que ocurrio en la epoca pre 1.0 con toda la problematica que habia, ya sea de posicionamiento, de desbalances, de sistemas medio hechos como la supresion del chat global y el cambio de economia etc; y es lo que ocurre ahora con las invasiones.

La respuesta que se me dio al respecto fue tajante y poco seria: deja el juego unos meses y vuelve mas tarde. Eso nunca deberia de ser una respuesta hacia los clientes en un proyecto que pretende ser autosustentable, serio, y que jacta de tener un desarrollo que tiene en cuenta a la comunidad.

Se recurre una y otra vez que no vemos el tema globalmente, pero tampoco se tiene en cuenta la forma en la que ese desarrollo llega a los usuarios y los meses de impasse que se sufren a la hora de definir el modelo de desarrollo.

Originally Posted by Xephandor

Sí, y lo dije... Pero no me queda claro de dónde sacás lo de cliente maduro, porque creo que no lo mencioné en ninguna parte. Para mí esto es resultado de seis años de parcheo indiscriminado (típico de los MMORPG's).

En este punto no me referia precisamente a tu post, me referia a otros comentarios y si, debi especificiarlo

Originally Posted by Xephandor

Creo que sigue parecido, aunque hubo un par de cambios. No tengo wireshark instalado ahora. Ese es uno de los casos donde deberían refactorizar, pero te comento que no es tan simple como suena. Hacer una transferencia de datos no es tan trivial, y habrán motivos para no cambiarlo ahora.

Se muy bien que es complicado, y que hay que mantener muchisimos streams distintos a muchisimos users, darle a cada uno la informacion que toca y solo lo que toca etc, y bastante merito tienen con que el sistema funcione . Pero este detalle supone tambien que el lag no es solo cuestion de las ISPs, que hay mucho ancho de banda desperdicidado y que hay trabajo que hacer en este aspecto.

En cambio aqui ocurre la actitud de NGD es la misma. Nada mas salir las invasiones chilko posteo diciendo que el server se la bancaba perfectamente y que si teniamos problemas de lag nos quejaramos a nuestras ISPs. En parte es cierto, en parte el tiempo a demostrado que lo de que el server se la banca sera cuando estan 100 users conectados.

Originally Posted by Xephandor

Ese "algo raro" creo que se debe más a que la mezcla de lua, c, c++ y assembler es un cóctel explosivo y muy fácil de romper... No a un rollback específico (no lo puedo confirmar sin el código). Estamos en la misma.

Es un detalle que no tuve en cuenta. Cualquiera que haya programado en este tipo de entornos conoce los quebraderos de cabeza que puede llegar a dar C++ al portar prototipados scripting a el. Aun y todo los prototipados en si nunca deberian de llegar a produccion, ya que son eso, prototipados. Otra cosa distinta es el caso de ports que en principio iban a ser en full scripting a C++ por temas de rendimiento.

Pese a todo, sigue sin convencerme como explicacion para todos los rebrotes de bugs, pero es una posibilidad y seguramente muchas habran sido debido a eso.

Originally Posted by Xephandor

Yo no le daría pelota, al menos porque ese tracker era un despelote para los usuarios... No me quiero imaginar para los administradores. Prefiero un sistema de tickets como SimpleTicket (aunque esté en Ruby), que sea abierto al público para ver los bugs disponibles y milestones.

Si, debia ser un engorro tremendo y tuvo que sufrir un flood increible ese sistema de bugtraquing, y supongo que por eso se saco el boton. Pero aun y todo hoy en dia sigue siendo accesible via web. Si no se ha usado en años o no se va a usar es facil borrar simplemente un link en la web y punto.

Originally Posted by Xephandor

El error está más por el lado de Jellsoft por hacer el login case-insensitive. Igualmente, ya estás hilando fino.

Eso pense al principio yo tambien, y mande un mail a Kailer indicandole el posible problema. Pero el caso de Killer demuestra que no es solo un problema de comparacion case sensitive, ya que habia dos usuarios con el mismo exacto nombre de usuario, en caracteres puramente ASCII, por lo que tampoco puede ser algo de charsets. Quiza hubiera un chequeo, pero el unico problema no fue la comparacion case sensitive que daba falsos negativos.

Saludos

EDIT:
@nicolas_11: pense que se referia a mi al venir justo detras de mi post. Si no es asi perdon por la agria respuesta
@Xephandor: discutir es bueno, flamear no :P Dejemos los flames para otras cosas

[ArcticWolf]

Originally Posted by takola

Sep, en los privativos no se da informacion interna. En cambio se dan extensisimos manuales, APIs etc. Pero no me referia a ese parte ya que hablamos de un juego y no de una libreria de programacion o lo que sea. Me referia mas al tratamiento de bugs.

Ok, ok... Me fui un poco por las ramas tal vez. Considero que el mal tratamiento de bugs está dado por una mezcla de un sistema caduco con usuarios que no tienen ni idea (ni ganas de aprender) cómo se reporta un error o se pide un enhancement. El foro no me resulta la herramienta más simple para desarrollo, y es un ancla que puede frenarlo.

El libro de quejas, a mi parecer, debería estar separado por completo de soporte, errores y sugerencias. Cumplen dos propósitos distintos con una sola herramienta, y es ineficiente.

Pasate por la sección de linux (sé que lo hacés) y vas a ver que los cuatro problemas fundamentales con el juego son: drivers no instalados, consumo de memoria ram en exceso, problemas de conexión y carga de recursos... Sin embargo, la gente va y abre nuevos. Un sistema de tickets está para evitar eso y ayuda en el bug-tracking (bugzilla es otro conocido y bueno).

Originally Posted by takola

Aun cuando es habitual no dar informacion sobre ellos mientras no se parcheen suele haber Full Disclosures tras el parcheo, aviso de que fallaba y porque fallaba y como solucionarlo. En NGD se oculta incluso el hecho de haber solucionado bugs. [...]

No sé cómo funcionará el sistema de desarrollo internamente, pero si trabajan con un sistema de repositorios parecido al svn podrían hacer un script para tomar los logs de commit y generar un changelog (debería hacer eso para rolgps :P). Tal vez eso ayude a monitorizar la solución a los bugs. Otra es que si se implementa un sistema de tickets tomen todos los que se cerraron como FIXED desde la última actualización y armen un changelog extendido (como opción del sistema de tickets).

Originally Posted by takola

Supongo que es lo mismo que con Microsoft: cuando menos bugs reconozcamos mejor sensacion de seguridad y seriedad damos. Afirmacion con la que no concuerdo para nada. [...]
Puede que a primera vista brille, pero al mirar debajo de la manta se ve toda la porqueria que hay.

Tampoco lo comparto, pero creo que es más por una falta de costumbre de comentar y documentar los cambios. A la larga los usuarios se dan cuenta y de todas maneras se comenta en el juego o en los foros.

Originally Posted by takola

Cualquier software con el que se pretende mantener un negocio deberia de requerir que lo que entre en produccion sea algo estable, aun siendo un juego y no el kernel de un controlador de misiles. Eso seria seriedad hacia el proyecto y hacia los usuarios. En NGD en cambio se prefiere perjudicar al usuario final mientras se testea en produccion. Es lo que ocurrio en la epoca pre 1.0 con toda la problematica que habia, ya sea de posicionamiento, de desbalances, de sistemas medio hechos como la supresion del chat global y el cambio de economia etc; y es lo que ocurre ahora con las invasiones.

Es una visión un poco apocalíptica, porque no considero que sea voluntad de NGD perjudicar a los usuarios directamente con cada update. Sí, deberían liberar con una barrera de bugs menor, pero también creo que están basándose en la cantidad de entrada-salida de jugadores según los cambios de contenido (lo cual lo veo como una estrategia peligrosa). Porque muchos se quejan de que no hay mejoras técnicas (pero sí artísticas o de contenido) se lanzan versiones no acabadas o con errores que se pasaron por alto.

Originally Posted by takola

Se muy bien que es complicado, y que hay que mantener muchisimos streams distintos a muchisimos users, darle a cada uno la informacion que toca y solo lo que toca etc, y bastante merito tienen con que el sistema funcione . Pero este detalle supone tambien que el lag no es solo cuestion de las ISPs, que hay mucho ancho de banda desperdicidado y que hay trabajo que hacer en este aspecto.

En cambio aqui ocurre la actitud de NGD es la misma. Nada mas salir las invasiones chilko posteo diciendo que el server se la bancaba perfectamente y que si teniamos problemas de lag nos quejaramos a nuestras ISPs. En parte es cierto, en parte el tiempo a demostrado que lo de que el server se la banca sera cuando estan 100 users conectados.

Con el sistema de comunicación entre plugins que estoy tratando de armar ya me lié con el tema de mensajes de control, sistema, etc... No me quiero imaginar el servidor y el protocolo que utiliza. El problema es ese, que tiene toda una teoría por atrás en cuanto al transporte de datos y la manera más eficiente de separar por grupos, funciones, destinatarios y establecer prioridades. Supongo que es la siguiente prioridad después de la estabilidad del servidor.

En cuanto a la prueba de usuarios: en teoría se lo bancaba, y en la práctica simple también. Ahora, el ambiente real probó ser bastante más complejo y pesado de lo que se esperaba... Aunque puedo asegurarte que soporta 500 personas bien (hace un año no llegaba a las 300 y se caía).

Otro problema es la carga de usuarios en un mismo lugar... Yo pondría una puerta inatacable hasta que una determinada cantidad de gente ocupe los fuertes tomados. Dicha cantidad está determinada por un máximo de gente que puede aguantar el server en un lugar.

Originally Posted by takola

Es un detalle que no tuve en cuenta. Cualquiera que haya programado en este tipo de entornos conoce los quebraderos de cabeza que puede llegar a dar C++ al portar prototipados scripting a el. Aun y todo los prototipados en si nunca deberian de llegar a produccion, ya que son eso, prototipados. Otra cosa distinta es el caso de ports que en principio iban a ser en full scripting a C++ por temas de rendimiento.

Usan assembler y C supongo que para el motor gráfico, C/C++ como lenguaje de pegamento, y lua está para el scripting de gameplay. Lua es muy customizable (awesomeWM lo usa por eso), pero no requiere acceso a todo el código fuente para modificaciones. Creo que no sería viable eliminarlo y usar puro C. Es más, si el juego está licenciado a Gamigo y ahora a la nueva compañía, ellos deben modificar sólo esos scripts.

Originally Posted by takola

Pese a todo, sigue sin convencerme como explicacion para todos los rebrotes de bugs, pero es una posibilidad y seguramente muchas habran sido debido a eso.

Claro, a veces habrán hecho un rollback o implementado alguna librería externa con un wrapper medio incompatible... Aunque también le atribuyo una mala repartición de tareas. Fijate que todavía sigue abierta la posición para engine programmer, y por la complejidad no creo que dos o tres personas puedan encargarse de tanto código sin pisar su trabajo.

Originally Posted by takola

Si, debia ser un engorro tremendo y tuvo que sufrir un flood increible ese sistema de bugtraquing, y supongo que por eso se saco el boton. Pero aun y todo hoy en dia sigue siendo accesible via web. Si no se ha usado en años o no se va a usar es facil borrar simplemente un link en la web y punto.

Sugerilo, tal vez se les pasó por alto (y ahora el encargado de eso es Kailer, pero se sacó antes de que entre según recuerdo).

Originally Posted by takola

Eso pense al principio yo tambien, y mande un mail a Kailer indicandole el posible problema. Pero el caso de Killer demuestra que no es solo un problema de comparacion case sensitive, ya que habia dos usuarios con el mismo exacto nombre de usuario, en caracteres puramente ASCII, por lo que tampoco puede ser algo de charsets. Quiza hubiera un chequeo, pero el unico problema no fue la comparacion case sensitive que daba falsos negativos.

Saludos

¿Hay algún tipo de test Unit para PHP? Puede que el problema haya sido no del código de comparación sino que de alguna variable que cambie el case-sensitive. Tuve el mismo problema en sqlite con librolgps y en mysql con el sitio de RegnumFest.

¡Saludos!

[keymod]

takola, xeph me dicen que estudian? asi ya se que es lo que no tengo planeado ni siquiera asomar la cabeza

[ArcticWolf]

Originally Posted by keymod

takola, xeph me dicen que estudian? asi ya se que es lo que no tengo planeado ni siquiera asomar la cabeza

Ingeniería en Informática... Te recomiendo Licenciatura en Matemática.