[Multi] Proyectos grandes || proyectos pequeños?

saulotmalo escribió:pues eso, me gustaría saber las preferencias de la gente sobre proyectos, digamos voy a poner aplicaciones o juegos grandes 50.000 o +, o por otro lado aplicaciones simples de 5.000 lineas + o -

No entiendo muy bien a que te refieres: si te refieres a si uno prefiere embarcarse en proyectos pequeños o grandes, está claro que la preferencia va a ser proyectos pequeños porque es mas facil que se obtenga resultado de ellos y los proyectos grandes, se hacen porque no es posible hacerlos como proyectos pequeños

Sobre el tema de las lineas que tenga un juego o proyecto, no tiene porque ser una medida especifica de la dificultad que tenga un proyecto, porque puede haber proyectos con relativamente pocas lineas y sin embargo ser proyectos bastante grandes porque requieren mucho trabajo de creacion de graficos y cosas asi.

Asi que no entiendo si es a nivel de preferencia a la hora de trabajar o que tu llamas a un proyecto grande por la cantidad de lineas de codigo que lleve y no por su dificultad a la hora de realizarlos por que requieren mucho trabjao u otras dificultades tecnicas (que para mi es la medida para calificarlo de grande)

Con seguridad, el proyecto con mas lineas en el que he trabajado y donde he tenido que resolver mas rompecabezas es el PS2Reality Mediaplayer y lo tiene todo: muchos miles de lineas de codigo y gran dificultad en su realizacion

es cierto, más que las lineas me refiero al tiempo empleado en el proyecto

pues pongamos 1 semana para los pequeños o 1 mes para los grandes.

a mi me ha costado decidirme porque los proyectos grandes tienen la ventaja de que cuando los encauzas y empiezas a ver que todo va bien es mucho más facil trabajar en ellos. los pequeños hasta que los tengas encauzados no se ve nada

Hombre, los proyectos que requieren mucho trabajo pero se pueden modularizar, se pueden ver como una sucesion de pequeñas tareas a realizar y se llevan mejor, pero en la practica, proyecto largo, proyecto que tiene un 90% de posibilidades de quedar aparcado por alguna razón, mientras que proyecto corto, posibilidad del 90% de alcanzar la consecucion.

Al menos, a nivel de programador amateur que hace esto para entretenerse y que prefiere hecer 50 cosas a centrarse en una sola que quiza no la consiga

quizas quería ir un paso más allá y pensar en nuestros trabajos (para los programadores ) a lo sque a veces llega el jefe y no nos deja elegir y nos hace leernos su código incomible de proyecto de infinitas lineas xD y eso...

pues la preguntita es cabroncilla eh?
Yo he votado a los proyectos grandes y aunque parezca una locura teniendo en cuenta lo poco que llevo programando, voy a argumentar mi voto:

En mi caso siempre pasa una de éstas 3 posibilidades:
a)Hacer un minijuego simple y adictivo
b)Hacer un juego largo y complejo
c)Hacer una estructura que me sirva para sacarlos luego cómo churros los de la modalidad a) y con más trabajo los de la modalidad b).

¿Qué es lo que pasa entonces?. Pues primero, quiero que sea un juego totalmente personal y por tanto, los gráficos tiene que ser de cosecha también, animaciones incluidas. Luego que sea totalmente innovador o contenga alguna particularidad única que lo haga original...
Hasta aquí bien, me meto una panzada a codear, rebuscar, adquirir práctica y conocimientos para que funcione a las duras y a las maduras y me harto a hacer bocetos, sprites... y mientras van apareciendo nuevas ideas de esas "originales" que normalmente hago en el momento que se ocurren, alargando más el proceso, y que además quizás envien a tomar por saco otra cosa o produzcan mil bugs

Y ahora viene lo bueno, ocurre una de dos o las dos:
a)Decido hacer el sistema lo más optimizado y preciso posible y suelo acabar recodeando la parte fundamental del juego o cambiando el tamaño de los personajes (que hace recodear bastante en según qué casos). Esto se come bastante de mi tiempo haciendome apartar de los gráficos.
b)No funciona sin motivo aparente el juego por alguna de esas ideas originales o por el supersistema revolucionario y me paso unos dias investigando hasta que acabo decidiendo cambiar de proyecto...

En resumen (para no leer todo lo anterior): empiezo con una idea clara y simple y la empiezo a complicar y a hacer más grande buscando la perfección en todos los puntos y como ya se sabe... "quien mucho abarca poco aprieta"

Y esto ya ocurre en mi último proyecto sólo dos dias después de empezarlo:
-He cambiado el sistema de sprites para ofrecer más personalización
-Voy a reescribir el sistema de disparos para que tengan 360 grados de movilidad en vez de solo 8 posibilidades
...
NUNCA APRENDERE!


EDITO: se me ha olvidado comentar que sólo hago programación estructurada (C puro y duro sin nada de C++)y que seguramente por no tocar nada de programación orientada a objetos es por lo que los proyectos se van hundiendo conforme se añaden enemigos, eventos, acciones...
Supongo que alguien dirá que le eche un ojo al C++ de una puñetera vez

zestt escribió:EDITO: se me ha olvidado comentar que sólo hago programación estructurada (C puro y duro sin nada de C++)y que seguramente por no tocar nada de programación orientada a objetos es por lo que los proyectos se van hundiendo conforme se añaden enemigos, eventos, acciones...
Supongo que alguien dirá que le eche un ojo al C++ de una puñetera vez

¿Y para que necesitas objetos para controlar/describir enemigos?

Lo que necesitas es utilizar bien las estructuras de datos desde C, solo eso

Hermes escribió:

¿Y para que necesitas objetos para controlar/describir enemigos?

Lo que necesitas es utilizar bien las estructuras de datos desde C, solo eso

estoy haciendo un par de juegos con c++ pero una librería rara que no permite la fácil orientacion a objetos y me está jodiendo mucho porque para controlar la entrada tengo que usar funciones en c los proyectos a la larga se hacen pesados sobretodo si no se estruccturan bien.

saulotmalo escribió:
estoy haciendo un par de juegos con c++ pero una librería rara que no permite la fácil orientacion a objetos y me está jodiendo mucho porque para controlar la entrada tengo que usar funciones en c los proyectos a la larga se hacen pesados sobretodo si no se estruccturan bien.

No se que tiene que ver esta respuesta a lo que yo le he contestado al otro .

Lo de las funciones en C, no se que problemas tienes con ellas: es facil encapsularlas y si el problema es de reentrada poco conveniente en la lectura del PAD llamala desde alguna parte (un hilo unido a un timer, por ejemplo) y pasa los datos en unas cuantas variables globales.

Es curioso tu punto de vista: en vez de decir que el problematico en este caso, es C++, le echas la culpa a las funciones en C

la culpa de todo siempre lo tiene la oposicion xD nada a ver que tampoco es que tenga toda la culpa c... pero amos que me ubiese gustado mas una librería que me permitiese en cada momento pues por ejemplo una funcion setEventReceiver no como tengo ahí una funcion event receiver que la pilla con el constructor y que "creo" que eso está así por culpa de que al que comenzó con el proyecto tenía habitos e c... ( pese a que la mayoría del motor está orientado a objetos ) ... no se

pd: yo tpc se porque había contestao eso xD me abré rayao entre tanto hilo jaajja

Eso de medir los proyectos "a peso"...Siempre me ha sonado a ver quien la tiene más grande

Para mi un proyecto corto es el que te puede llevar hasta 3 meses. Un proyecto que haces en una semana no llega ni a corto.

Y como bien dice hermes (para que no piense que nunca pienso lo mismo) depende de la complejidad y no del tamaño. Hay ocasiones en que 50 líneas pueden costarte sudor y lágrimas y en cambio metas 5000 como si fuera un dicatado.

Por mi parte, me dejan más satisfecho los proyectos de largo plazo, pero el desgaste es mayor y no se suelen quedar tan próximos a la idea pensada como lo puede hacer uno pequeño.

Pero independientemente de si proyecto corto o proyecto largo, la pregunta que tendríamos que hacer es, acabar proyecto o empezar otro cuando me aburra (que se da enseguida).

Considerando proyecto grande todo aquel que me lleve mas de 6 meses terminarlo programando yo solo prefiero grandes a pequeños, mas que nada porque al terminarlos la satisfacción en mushísimo mas grande ademas de que me lo paso mejor diseñando jerarquías y diagramas de clases y el juego en sí que programandolo directamente y en los proyectos pequeños este suele ser un paso menos interesante (aunque por supuesto hay excepciones).