Te resumo lo que ha sido la rueda de prensa. Por ejemplo, hubo varios cuelgues que arrojaron la demo al escritorio, el sistema de ofertas daba fallo, los sueldos no tenían ni pies ni cabeza, el mecanismo de generación de equipos creó una plantilla sin delanteros para alinear, algunas pantallas cargaban con excesiva lentitud y, para redondear, el modo "Chapas" de visualización de partidos no funcionaba, al menos en esta versión. Las frases por parte de Prats como "me está dando vergüenza" u "os juro que esto no me había pasado nunca" empezaban a acumularse mientras crecían sus nervios. Y por supuesto, dijo primero que saldría la semana que viene y después de estos fallos ha dicho que no da fecha. En fin, lo de este tío sí que es estafa y no lo de LLADOS. 😂
@@KaKaRoT-YoKuRa , jajajaja. Son errores de novato de desarrollador, pero bastante típicos. He visto hacer cosas parecidas, con mucha menos repercusión. Pero generó tanta expectación que ahora se le vuelve en contra, pues la gente lo anda mirando con lupa, empezando por los de las preventas, continuando por la prensa y siguiendo por nuestro amigo. Ja, ja.
Cada cambio en el código, o líneas de código añadidas tiene que tener sus tests correspondientes que las cubran. Para empezar, ahí tienes muchas opciones de detectar errores sobre cada cambio de manera automatizada. Además si tienes tests unitarios, tests de integración entre componentes y si además añades tests de mutación, lo de los errores aleatorios... ya no cuela tanto. En cuanto al código mismo, si se siguen una serie de normas de clean code, una buena arquitectura y diseño, una nomenclatura adecuada, cualquier desarrollador con cierta experiencia puede hacerse con el código de manera más o menos rápida, al menos para poder situarse e ir sacando desarrollos y corrigiendo bugs. Con todo esto, si no sabes encontrar un error de ninguna manera, ni eres capaz a estas alturas de saber qué te queda por hacer, qué funciona y qué no funciona... ahí hay un problema grave. En cuanto lo de los comentarios, vuelvo a recalcar, un código bien organizado, con buena nomenclatura, que siga ciertas reglas/convenciones no necesita grandes comentarios para entenderse. Sí quizás para explicar casuísticas muy concretas. Soy fan de pcfutbol desde pcfutbol2 y soy el que más ganas tiene de que salga una versión del juego que mantenga la esencia de los antiguos, y admiro a la gente que se ha atrevido a intentar sacar esto adelante. Pero me da la sensación de que la calidad del equipo de desarrollo y de la gestión del proyecto deja mucho que desear.
me da bastante pena Hector, lo cierto es que no debe dar fechas y decir " señores cuando esté se enviará" no sé si sera 1 mes o 3 meses, lo que necesite el juego para poder disfrutarlo, añadele que diga algo como si para noviembre de 2024 no está se devuelve todas las precompras y por lo menos lo hemos intentado
Este vídeo es el que tendría que haber visto el responsable de PC Fútbol antes de empezar el proyecto. Al final, cuando vas tan ajustado en todo: tiempo, conocimientos, dinero, que no te puedes permitir fallos, el riesgo a fracasar crece exponencialmente. Ahora se ve que está cambiando de estrategia y siendo mucho más transparente, pero quizás sea tarde porque es muy difícil recuperar la confianza. Hay críticas justas y otras que han sido muy ofensivas. Ojalá que pueda conseguir resolver mágicamente todos los problemas y poder sacar un juego aceptable, porque en definitiva el límite entre la genialidad y la locura es muy fino. Es como aquel que dijo: "...antes del final de la década pondremos un hombre en la luna...", y lo lograron, pero barato, precisamente no les salió, ni tampoco fue rentable.
@@JorgeMartinez-zl6ci , van a tener que echarle mucho trabajo de noche. En programación esa «magia» se consigue echando más horas que un panadero. Pero como dice el dicho: «trabajo hecho, venta espera». Ya puede decir misa quien sea: «FINIS CORONAT OPVS» (el buen trabajo obtiene su recompensa).
EStá claro que encontrar un error es muy difícil y en un equipo cambiante más.Especialmente si no se comenta el estilo de programación que se está llevando, si no se hacen librerías, si las dependencias están mal planteadas y el más mínimo cambio obliga a recompilar TODO....creo que en este proyecto, por inexperiencia del GD, está pasando todo esto A LA VEZ
@@singletonjohn7339 , así es. Ésa sensación me dio a mí también. Es un problema de inexperiencia que se le ha venido encima sumado a un nombre de una franquicia con mucho peso y carga detrás que genera mucha expectación y comidilla.
Una máxima de desarrolladores: si tienes una entrevista, demo o feria, no cambies el código estable!!!Llévate el ULTIMO BUILD ESTABLE del control de versiones (si lo tienes, claro)
No estoy de acuerdo con los errores aleatorios. Es decir, no me refiero a que no se produzcan, al contrario, me refiero a usar este error como excusa. Si encuentras este caso, la solución es MUY compleja de resolver y parchearlo o intentarlo controlar es MUY difícil, el problema es de base. Lo mejor, en estos casos, es repensar la arquitectura del componente afectado y rehacerlo. Bajo mi experiencia, es la única solución viable para que no vuelva a pasar.
Os lanzo una pregunta a todos, viendo lo MUCHO que les lleva compilar y las carpetas que aparecen en el build: creéis que se está usando un control de versiones...o por lo menos, se ESTA USANDO BIEN el control de versiones? Mi opinión al respecto está clara: NO SE ESTA USANDO UN CONTROL DE VERSIONES...o si se está usando (que lo dudo) se publica todo y se hace merge a todo de manera automática...si no, los errores estarían más aislados y controlados
Tiene pinta de que no se está usando, @@singletonjohn7339 . De que van a salto de mata zangoleteando dentro del mismo código y volviendo a compilar cada vez, sobreescribiendo el compilado anterior.
@@RodMerida eso es la mejor manera de suicidarse (electrónicamente hablando).....y cuando tienes poco tiempo, mucha presión y cero paciencia...ufffff...al mínimo error muerte asegurada
Yo entiendo todas las vicisitudes del desarrollo de videojuegos porque he desarrollado profesionalmente por mas de diez años (he trabajado casualmente en un juego de futbol en Switch) y también he hecho algunas cosas retro. Pero la sensación de descontrol y poca profesionalidad ha sido tal que no daba la sensación de estar viendo una rueda de prensa, sino una reunión de amiguetes. Para enseñar el juego necesitas tener una build ya preparada y testeada de días antes, no una buid diaria del momento. Nadie debe enterarse de los últimos bugs aparecidos ni puedes hacer la build en directo.
Si tienes el código organizado (pero de verdad) encuentras lo que buscas en segundos. Por experiencia, como persona que ha pasado del caos absoluto al orden más repugnantemente estricto.
Es todo una patraña absurda y ridicula. Un ejemplo perfecto de una mala gestión, un mal trabajo, una chapuza. Al ceo de esta compañía hay que darle unas clases de gestión de proyectos, eso para empezar. No se puede vender un proyecto como algo espectacular y luego demostrarse que hay un equipo de trileros. Donde está la documentación? Las pruebas? Requisitos? Comentarios? Que metodología de desarrollo está siguiendo este equipo? Nada, nada y nada. Ese juego jamas se terminará al nivel que se había prometido. Ningún proyecto sale adelante con tantas carencias de base como en este caso. Es cuestión de tiempo, se cancelará. Todo es difícil. La industria del software se enfrenta a proyectos muy complejos y salen adelante. Pero hay una dirección profesional y buenos profesionales. Aquí no hay nada. Que sigan compilando ese truño hasta el infinito.
No te falta razón. Pero, después de ver la rueda de prensa y analizar a fondo el caso de PC Futbol... mi conclusión no es que sean churros o estafa por parte de Héctor. Más bien lo que yo vi fue la cara de una persona sobrepasada por algo que es incapaz de gestionar por falta de capacidades intelectuales. El proyecto, desde que empezó, era demasiado grande para una persona inexperta y, en mi humilde opinión, flipada, que se pensaba que esto de hacer juegos es cosa de 3 días y 4 duros. Mal cálculo en todos los sentidos: presupuesto, equipo técnico, marketing... Todo mal.
@@juanperezleal , muy de acuerdo con ese análisis. Hay programadores que además de inexpertos no tienen la cabeza lo bastante estructurada, es decir, lo bastante bien amueblada en tanto que programadores sistemáticos para acometer sin la suficiente ayuda un proyecto de estas características y envergadura o incluso para coordinar a los distintos programadores que van metiendo mano en el código junto con él. Sumado a eso, hay programadores fulleros, adanes, a los que luego a la hora de la verdad, cuando faltan pocos días para la fecha de entrega o la rueda de prensa y encima toca compilar, se empiezan a encontrar todos esos errores que se han ido dejando espurriados y que es como querer barrer metiendo la roña debajo de la alfombra o del sofá. Al final eso sale. Muy de acuerdo con ese análisis.
Existen instrucciones de control de excepciones (try/catch), justamente para capturar errores que sean difíciles de controlar y obtener su origen. Si eso no existe en un proyecto, probablemente estés perdiendo parte de buenas prácticas. No creo en los errores aleatorios. Lo mismo si estamos teniendo errores de race condition, es porque se están cometiendo errores básicos. Por el resto, buen video explicativo.
@@pablo_palma , estoy de acuerdo, aunque en los lenguajes antiguos en que desarrollé mis juegos retro a menudo no había nada de eso o no era fácil de usar porque en el editor el juego no va a la velocidad que debe, y come mucha más RAM, y cuando el juego ya tenía un tamaño ya ni iba si no era compilado, xD, claro, que siempre podías imprimirte alguna cadena de texto en pantalla cada media vuelta de scroll o sacarla en forma de fichero de texto sencillo, lo que se llama un archivo de registro o «log». Héctor Prats tiene unos medios a su alcance que ni se lo cree, pero quizá por ir a salto de mata, con tanta bulla y gente entrando y saliendo, no les esté sacando todo el partido que debiera, por «no complicarse», y a veces ir «a lo rápido» acaba siendo lo lento. Me ha pasado también.
@@RodMerida Totalmente. Ahora tenemos herramientas de sobra para poder controlar todo, pero como bien decís, si no hay una gerencia técnica clara, no hay mucho por hacer. A Hector le comenté varias veces sobre race conditions para evitar estas cosas y sobre la arquitectura que logré implementar para que no hayan cosas hechas a como de lugar de cada desarrollador. Hay más de 8 meses de trabajo y en ello se genera una paradoja: Hay mucho hecho pero a su vez poco sirve y es como si no hubiera nada. Ya sabemos lo costoso que es remontar un proyecto de meses y ver qué sirve y que no.
Spinecard ha analizado las imágenes de PC Futbol 8 y lo ha hecho muy bien. Tu estas intentando defender lo que no se puede defender y lo haces muy mal.
@@pacochales9507 , es absurdo analizar un desarrollo inacabado, que está en proceso. Eso es una falacia desde todo punto de vista posible por el que lo mires. Demagogia se llama, en filosofía. Pero dale, seguid con el tole tole, hasta que os dure.
El problema aqui ha sido 1.- pedir perras 2.- "sale el lunes, ya esta terminado". Este segundo error es tipico del jefe de proyectó que no tiene ni puta idea de desarrollo y se pilla los dedos con los plazos. No soy quien para catalogar algo de estafa pero si de irresponsable. Muy probablemente(y por mi experiencia) jefe narcisista rodeado de programadores junior o sin posibilidad de opinar y parar los pies al que fija plazos.Trabajo en desarrollo en incidencias y no paro de solucionar cada dia mierdas de este tipo. Saludos.
Técnicamente el jefe del proyecto es desarrollador. Pero es desarrollador de Software hasta donde yo sé. Es muy distinto organizar y mandar en un desarrollo de videojuego que programar como parte de un engranaje de una web o una app.
@@josublancoortiz9824 estoy de acuerdo en lo que comentas, incluso diferente trabajar con distintas tecnologías/lenguajes. Comentaba casos, como dije por mi experiencia, que me encuentro. No obstante, está claro que la columpiada en plazos es irresponsable, sobre todo cuando es una constante, es decir, no puedes fijar varias veces una fecha de salida cuando claramente queda un mundo por desarrollar. Entonces, bajo mi punto de vista se juntan dos cosas, no tienes idea y además nadie de alrededor te dice/se atreve/ le haces caso para decir "para cojones". Me recuerda a cuando mi abuela ve un corte pelo raro y dice "no tiene amigos o familia que le digan que así no?". Saludos
@@domingogil3311 , en efecto, el problema parte de que está mal asesorado, o mejor dicho, no está asesorado en absoluto, como dices, lo que se suma a que es muy impulsivo haciendo cábalas de plazos y muy optimista con el tiempo que cree que le queda, algo por otro lado muy típico en desarrolladores de videojuegos novatos. A mí me pasó también las primeras veces que hice juegos homebrew (menos mal que los hice por hobby y no para reflotar una franquicia comercial archifamosa de un juego simulador / estrategia archicomplejo, con el mato de parámetros, xD). Así aprenderá. Pero para nada veo voluntad de estafar ni veo vendehúmo. Es incontestable que trabajo hecho, hay.
Las explicaciones técnicas están muy bien, pero no hace falta ir tan lejos. Es decir, ya se intuía desde el día 1 de la preventa del juego. Es más importante parecer la mujer del César que serlo. Viendo la web promocional y anuncios cutres salchicheros no, sino lo siguiente. El vocabulario tan parco y pueril para justificar los sucesivos retrasos. Etc. etc. ya se podía imtuir que muy fiable el tema PC Fútbol no parecía.
Pero si tú tienes un "desarrollo" no lo vendes como un juego nuevo, listo para el cliente y lo VENDES que es lo más grave. Acaso a nadie le importa el cliente? Cuando se dice *Juego nuevo en 2025* No se empieza a cobrar durante todo 2024.
@@yjvm , creo que es un error hacer reservas al comienzo del proyecto. Percibo que éstas se concibieron como una forma de crowdfunding, o financiación colectiva, por parte del equipo. Pero no todos los que las han hecho parecen verlo de ese modo, y cada uno es de su padre y de su madre. La gente además es muy influenciable.
bro literal es lo que se lleva haciendo hace años con los famosos "early access"...es venderte un juego que esta en desarrollo. Y muchos hacen pre-compras de juegos que no han salido, el problema no es eso. El problema es que tristemente el PC Futbol ha generado una expectacion en base a los anteriores PC Futbol, es relativamente facil cuando tienes los codigos fuentes de los anteriores juegos, pero cuando tienes que hacer todo desde 0 ahi hacer la base es lo mas dificil, o sea, hacer la parte no jugable todavia, metele ahora añadir la jugabilidad. Hacer un juego asi minimo dos-tres años, para que salga decente.
@@jacklogan6754 , es mucho lo que tiene hecho, pero en el compilado da ciertos fallos al azar. Si hay suerte se puede jugar una partida entera y si no la hay se producen cuelgues en distintos puntos. Seguramente nunca había llegado a compilarlo, y lo habían probado todo este tiempo en el entorno de desarrollo, también llamado editor, en forma interpretada en tiempo real, y no compilada: es decir, con el ordenador interpretando el código fuente en lugar de ejecutar un ejecutable. Y sí, dar fechas así es un fallo de desarrollador de videojuegos novato. Es muy típico. A todos los que hemos empezado a hacer juegos (aunque sea como pasatiempos, como en mi caso) nos ha pasado. Te animas viendo que la cosa va saliendo, te flipas, te crees que lo que queda por hacer se va a hacer antes pero cualquier error que surge te tiene casi todo el día liado y se malgasta de tiempo a veces lo más grande. Cuando ya has sufrido lo que es trabajar bajo presión del tiempo es cuando te lo piensas dos veces y no lo haces xD (salvo que te obligue tu jefe a cumplir un plazo arbitrario, en cuyo caso estás puteadísimo). No le deseo trabajar así ni a mi pero enemigo. Porque donde él está yo ya he estado.
Te resumo lo que ha sido la rueda de prensa.
Por ejemplo, hubo varios cuelgues que arrojaron la demo al escritorio, el sistema de ofertas daba fallo, los sueldos no tenían ni pies ni cabeza, el mecanismo de generación de equipos creó una plantilla sin delanteros para alinear, algunas pantallas cargaban con excesiva lentitud y, para redondear, el modo "Chapas" de visualización de partidos no funcionaba, al menos en esta versión. Las frases por parte de Prats como "me está dando vergüenza" u "os juro que esto no me había pasado nunca" empezaban a acumularse mientras crecían sus nervios.
Y por supuesto, dijo primero que saldría la semana que viene y después de estos fallos ha dicho que no da fecha.
En fin, lo de este tío sí que es estafa y no lo de LLADOS. 😂
@@KaKaRoT-YoKuRa , jajajaja.
Son errores de novato de desarrollador, pero bastante típicos. He visto hacer cosas parecidas, con mucha menos repercusión. Pero generó tanta expectación que ahora se le vuelve en contra, pues la gente lo anda mirando con lupa, empezando por los de las preventas, continuando por la prensa y siguiendo por nuestro amigo. Ja, ja.
Cada cambio en el código, o líneas de código añadidas tiene que tener sus tests correspondientes que las cubran. Para empezar, ahí tienes muchas opciones de detectar errores sobre cada cambio de manera automatizada. Además si tienes tests unitarios, tests de integración entre componentes y si además añades tests de mutación, lo de los errores aleatorios... ya no cuela tanto. En cuanto al código mismo, si se siguen una serie de normas de clean code, una buena arquitectura y diseño, una nomenclatura adecuada, cualquier desarrollador con cierta experiencia puede hacerse con el código de manera más o menos rápida, al menos para poder situarse e ir sacando desarrollos y corrigiendo bugs. Con todo esto, si no sabes encontrar un error de ninguna manera, ni eres capaz a estas alturas de saber qué te queda por hacer, qué funciona y qué no funciona... ahí hay un problema grave. En cuanto lo de los comentarios, vuelvo a recalcar, un código bien organizado, con buena nomenclatura, que siga ciertas reglas/convenciones no necesita grandes comentarios para entenderse. Sí quizás para explicar casuísticas muy concretas. Soy fan de pcfutbol desde pcfutbol2 y soy el que más ganas tiene de que salga una versión del juego que mantenga la esencia de los antiguos, y admiro a la gente que se ha atrevido a intentar sacar esto adelante. Pero me da la sensación de que la calidad del equipo de desarrollo y de la gestión del proyecto deja mucho que desear.
me da bastante pena Hector, lo cierto es que no debe dar fechas y decir " señores cuando esté se enviará" no sé si sera 1 mes o 3 meses, lo que necesite el juego para poder disfrutarlo, añadele que diga algo como si para noviembre de 2024 no está se devuelve todas las precompras y por lo menos lo hemos intentado
Este vídeo es el que tendría que haber visto el responsable de PC Fútbol antes de empezar el proyecto. Al final, cuando vas tan ajustado en todo: tiempo, conocimientos, dinero, que no te puedes permitir fallos, el riesgo a fracasar crece exponencialmente. Ahora se ve que está cambiando de estrategia y siendo mucho más transparente, pero quizás sea tarde porque es muy difícil recuperar la confianza.
Hay críticas justas y otras que han sido muy ofensivas. Ojalá que pueda conseguir resolver mágicamente todos los problemas y poder sacar un juego aceptable, porque en definitiva el límite entre la genialidad y la locura es muy fino. Es como aquel que dijo: "...antes del final de la década pondremos un hombre en la luna...", y lo lograron, pero barato, precisamente no les salió, ni tampoco fue rentable.
@@JorgeMartinez-zl6ci , van a tener que echarle mucho trabajo de noche. En programación esa «magia» se consigue echando más horas que un panadero. Pero como dice el dicho: «trabajo hecho, venta espera». Ya puede decir misa quien sea: «FINIS CORONAT OPVS» (el buen trabajo obtiene su recompensa).
EStá claro que encontrar un error es muy difícil y en un equipo cambiante más.Especialmente si no se comenta el estilo de programación que se está llevando, si no se hacen librerías, si las dependencias están mal planteadas y el más mínimo cambio obliga a recompilar TODO....creo que en este proyecto, por inexperiencia del GD, está pasando todo esto A LA VEZ
@@singletonjohn7339 , así es. Ésa sensación me dio a mí también. Es un problema de inexperiencia que se le ha venido encima sumado a un nombre de una franquicia con mucho peso y carga detrás que genera mucha expectación y comidilla.
Una máxima de desarrolladores: si tienes una entrevista, demo o feria, no cambies el código estable!!!Llévate el ULTIMO BUILD ESTABLE del control de versiones (si lo tienes, claro)
No estoy de acuerdo con los errores aleatorios. Es decir, no me refiero a que no se produzcan, al contrario, me refiero a usar este error como excusa. Si encuentras este caso, la solución es MUY compleja de resolver y parchearlo o intentarlo controlar es MUY difícil, el problema es de base. Lo mejor, en estos casos, es repensar la arquitectura del componente afectado y rehacerlo. Bajo mi experiencia, es la única solución viable para que no vuelva a pasar.
Estoy totalmente de acuerdo.
Un último comentario: los errores aleatorios suelen ser WARNINGS no atendidos o un estilo de programación realmente desastroso
Muy de acuerdo.
Así uno puede llegar a entender a dónde puede llegar un trabajo de programación. 👌
Os lanzo una pregunta a todos, viendo lo MUCHO que les lleva compilar y las carpetas que aparecen en el build: creéis que se está usando un control de versiones...o por lo menos, se ESTA USANDO BIEN el control de versiones? Mi opinión al respecto está clara: NO SE ESTA USANDO UN CONTROL DE VERSIONES...o si se está usando (que lo dudo) se publica todo y se hace merge a todo de manera automática...si no, los errores estarían más aislados y controlados
Tiene pinta de que no se está usando, @@singletonjohn7339 . De que van a salto de mata zangoleteando dentro del mismo código y volviendo a compilar cada vez, sobreescribiendo el compilado anterior.
@@RodMerida eso es la mejor manera de suicidarse (electrónicamente hablando).....y cuando tienes poco tiempo, mucha presión y cero paciencia...ufffff...al mínimo error muerte asegurada
Yo entiendo todas las vicisitudes del desarrollo de videojuegos porque he desarrollado profesionalmente por mas de diez años (he trabajado casualmente en un juego de futbol en Switch) y también he hecho algunas cosas retro. Pero la sensación de descontrol y poca profesionalidad ha sido tal que no daba la sensación de estar viendo una rueda de prensa, sino una reunión de amiguetes. Para enseñar el juego necesitas tener una build ya preparada y testeada de días antes, no una buid diaria del momento. Nadie debe enterarse de los últimos bugs aparecidos ni puedes hacer la build en directo.
Si tienes el código organizado (pero de verdad) encuentras lo que buscas en segundos. Por experiencia, como persona que ha pasado del caos absoluto al orden más repugnantemente estricto.
@@kamealex , lo sé.
Es todo una patraña absurda y ridicula. Un ejemplo perfecto de una mala gestión, un mal trabajo, una chapuza. Al ceo de esta compañía hay que darle unas clases de gestión de proyectos, eso para empezar. No se puede vender un proyecto como algo espectacular y luego demostrarse que hay un equipo de trileros. Donde está la documentación? Las pruebas? Requisitos? Comentarios? Que metodología de desarrollo está siguiendo este equipo? Nada, nada y nada. Ese juego jamas se terminará al nivel que se había prometido. Ningún proyecto sale adelante con tantas carencias de base como en este caso. Es cuestión de tiempo, se cancelará.
Todo es difícil. La industria del software se enfrenta a proyectos muy complejos y salen adelante. Pero hay una dirección profesional y buenos profesionales. Aquí no hay nada. Que sigan compilando ese truño hasta el infinito.
Hola! Existe alguna forma de contactar contigo? Nos dices, un saludo!!
@@carrildeltres , sí, claro. Al correo electrónico: crackowia@gmail.com .
No te falta razón. Pero, después de ver la rueda de prensa y analizar a fondo el caso de PC Futbol... mi conclusión no es que sean churros o estafa por parte de Héctor. Más bien lo que yo vi fue la cara de una persona sobrepasada por algo que es incapaz de gestionar por falta de capacidades intelectuales. El proyecto, desde que empezó, era demasiado grande para una persona inexperta y, en mi humilde opinión, flipada, que se pensaba que esto de hacer juegos es cosa de 3 días y 4 duros. Mal cálculo en todos los sentidos: presupuesto, equipo técnico, marketing... Todo mal.
@@juanperezleal , muy de acuerdo con ese análisis.
Hay programadores que además de inexpertos no tienen la cabeza lo bastante estructurada, es decir, lo bastante bien amueblada en tanto que programadores sistemáticos para acometer sin la suficiente ayuda un proyecto de estas características y envergadura o incluso para coordinar a los distintos programadores que van metiendo mano en el código junto con él. Sumado a eso, hay programadores fulleros, adanes, a los que luego a la hora de la verdad, cuando faltan pocos días para la fecha de entrega o la rueda de prensa y encima toca compilar, se empiezan a encontrar todos esos errores que se han ido dejando espurriados y que es como querer barrer metiendo la roña debajo de la alfombra o del sofá. Al final eso sale. Muy de acuerdo con ese análisis.
Existen instrucciones de control de excepciones (try/catch), justamente para capturar errores que sean difíciles de controlar y obtener su origen. Si eso no existe en un proyecto, probablemente estés perdiendo parte de buenas prácticas. No creo en los errores aleatorios. Lo mismo si estamos teniendo errores de race condition, es porque se están cometiendo errores básicos. Por el resto, buen video explicativo.
@@pablo_palma , estoy de acuerdo, aunque en los lenguajes antiguos en que desarrollé mis juegos retro a menudo no había nada de eso o no era fácil de usar porque en el editor el juego no va a la velocidad que debe, y come mucha más RAM, y cuando el juego ya tenía un tamaño ya ni iba si no era compilado, xD, claro, que siempre podías imprimirte alguna cadena de texto en pantalla cada media vuelta de scroll o sacarla en forma de fichero de texto sencillo, lo que se llama un archivo de registro o «log». Héctor Prats tiene unos medios a su alcance que ni se lo cree, pero quizá por ir a salto de mata, con tanta bulla y gente entrando y saliendo, no les esté sacando todo el partido que debiera, por «no complicarse», y a veces ir «a lo rápido» acaba siendo lo lento. Me ha pasado también.
@@RodMerida Totalmente. Ahora tenemos herramientas de sobra para poder controlar todo, pero como bien decís, si no hay una gerencia técnica clara, no hay mucho por hacer. A Hector le comenté varias veces sobre race conditions para evitar estas cosas y sobre la arquitectura que logré implementar para que no hayan cosas hechas a como de lugar de cada desarrollador. Hay más de 8 meses de trabajo y en ello se genera una paradoja: Hay mucho hecho pero a su vez poco sirve y es como si no hubiera nada. Ya sabemos lo costoso que es remontar un proyecto de meses y ver qué sirve y que no.
Spinecard ha analizado las imágenes de PC Futbol 8 y lo ha hecho muy bien. Tu estas intentando defender lo que no se puede defender y lo haces muy mal.
@@pacochales9507 , es absurdo analizar un desarrollo inacabado, que está en proceso. Eso es una falacia desde todo punto de vista posible por el que lo mires. Demagogia se llama, en filosofía. Pero dale, seguid con el tole tole, hasta que os dure.
El problema aqui ha sido 1.- pedir perras 2.- "sale el lunes, ya esta terminado". Este segundo error es tipico del jefe de proyectó que no tiene ni puta idea de desarrollo y se pilla los dedos con los plazos. No soy quien para catalogar algo de estafa pero si de irresponsable. Muy probablemente(y por mi experiencia) jefe narcisista rodeado de programadores junior o sin posibilidad de opinar y parar los pies al que fija plazos.Trabajo en desarrollo en incidencias y no paro de solucionar cada dia mierdas de este tipo. Saludos.
@@domingogil3311 , lo has clavado con tu comentario.
Técnicamente el jefe del proyecto es desarrollador. Pero es desarrollador de Software hasta donde yo sé. Es muy distinto organizar y mandar en un desarrollo de videojuego que programar como parte de un engranaje de una web o una app.
@@josublancoortiz9824 estoy de acuerdo en lo que comentas, incluso diferente trabajar con distintas tecnologías/lenguajes. Comentaba casos, como dije por mi experiencia, que me encuentro. No obstante, está claro que la columpiada en plazos es irresponsable, sobre todo cuando es una constante, es decir, no puedes fijar varias veces una fecha de salida cuando claramente queda un mundo por desarrollar. Entonces, bajo mi punto de vista se juntan dos cosas, no tienes idea y además nadie de alrededor te dice/se atreve/ le haces caso para decir "para cojones".
Me recuerda a cuando mi abuela ve un corte pelo raro y dice "no tiene amigos o familia que le digan que así no?". Saludos
@@domingogil3311 , en efecto, el problema parte de que está mal asesorado, o mejor dicho, no está asesorado en absoluto, como dices, lo que se suma a que es muy impulsivo haciendo cábalas de plazos y muy optimista con el tiempo que cree que le queda, algo por otro lado muy típico en desarrolladores de videojuegos novatos. A mí me pasó también las primeras veces que hice juegos homebrew (menos mal que los hice por hobby y no para reflotar una franquicia comercial archifamosa de un juego simulador / estrategia archicomplejo, con el mato de parámetros, xD). Así aprenderá.
Pero para nada veo voluntad de estafar ni veo vendehúmo. Es incontestable que trabajo hecho, hay.
Las explicaciones técnicas están muy bien, pero no hace falta ir tan lejos. Es decir, ya se intuía desde el día 1 de la preventa del juego. Es más importante parecer la mujer del César que serlo. Viendo la web promocional y anuncios cutres salchicheros no, sino lo siguiente. El vocabulario tan parco y pueril para justificar los sucesivos retrasos. Etc. etc. ya se podía imtuir que muy fiable el tema PC Fútbol no parecía.
Pero si tú tienes un "desarrollo" no lo vendes como un juego nuevo, listo para el cliente y lo VENDES que es lo más grave. Acaso a nadie le importa el cliente? Cuando se dice *Juego nuevo en 2025* No se empieza a cobrar durante todo 2024.
@@yjvm , creo que es un error hacer reservas al comienzo del proyecto. Percibo que éstas se concibieron como una forma de crowdfunding, o financiación colectiva, por parte del equipo. Pero no todos los que las han hecho parecen verlo de ese modo, y cada uno es de su padre y de su madre. La gente además es muy influenciable.
bro literal es lo que se lleva haciendo hace años con los famosos "early access"...es venderte un juego que esta en desarrollo.
Y muchos hacen pre-compras de juegos que no han salido, el problema no es eso. El problema es que tristemente el PC Futbol ha generado una expectacion en base a los anteriores PC Futbol, es relativamente facil cuando tienes los codigos fuentes de los anteriores juegos, pero cuando tienes que hacer todo desde 0 ahi hacer la base es lo mas dificil, o sea, hacer la parte no jugable todavia, metele ahora añadir la jugabilidad. Hacer un juego asi minimo dos-tres años, para que salga decente.
@@XaviIntheHouse , muy de acuerdo contigo.
si solo tenia hecho lo que ha presentado por que pone fechas?
@@jacklogan6754 , es mucho lo que tiene hecho, pero en el compilado da ciertos fallos al azar. Si hay suerte se puede jugar una partida entera y si no la hay se producen cuelgues en distintos puntos. Seguramente nunca había llegado a compilarlo, y lo habían probado todo este tiempo en el entorno de desarrollo, también llamado editor, en forma interpretada en tiempo real, y no compilada: es decir, con el ordenador interpretando el código fuente en lugar de ejecutar un ejecutable.
Y sí, dar fechas así es un fallo de desarrollador de videojuegos novato. Es muy típico. A todos los que hemos empezado a hacer juegos (aunque sea como pasatiempos, como en mi caso) nos ha pasado. Te animas viendo que la cosa va saliendo, te flipas, te crees que lo que queda por hacer se va a hacer antes pero cualquier error que surge te tiene casi todo el día liado y se malgasta de tiempo a veces lo más grande. Cuando ya has sufrido lo que es trabajar bajo presión del tiempo es cuando te lo piensas dos veces y no lo haces xD (salvo que te obligue tu jefe a cumplir un plazo arbitrario, en cuyo caso estás puteadísimo). No le deseo trabajar así ni a mi pero enemigo. Porque donde él está yo ya he estado.