Reflexion sobre los procesos

[necro_vampire]

Primero que nada, hablare sobre este texto, aunque se encuentre en un estado muy primitivo.
El propositivo del mismo es documentar, el resultado de varias discusiones y criticas.
Al hacer publico este texto, estoy invitando a cual lector a dar su opinion al respecto, incluso
a reservarsela si lo considera conveniente; a discutir, inclusive a destruir mi opnion si se hace
criticamente.

He notado que todo lo que escribo, no alcanza a satisfacerme, en especial como programador.
Que puede ser mejorado, en otras palabras visto desde diferentes siempre se puede optimizar en algun
punto, ya sea en reducir lineas de codigo, en el espacio y tiempo de acceso que utilizen los datos
que intervengan, solo por nombrar algo. Esto me lleva a buscar otras formas de aproximacion
a la hora de realizar un mismo procedimiento, en la medida que mi razon me lo permite, aunque
siempre me he decantado por la solucion equilibrada entre simple y uso de recursos, considerando
que si alguien que no entiende de programacion puede entender la solucion, entonces es simple.

Esto me ha llevado a pensar una forma de trabajar con los procesos en los lenguajes divlike.
El hecho de considerar a un proceso como un ente, el cual reacciona dependiendo del entorno
que lo rodea (principalmente otros procesos, graficos, etc), el ambiente externo "de su ecosistema"
(lease Sistema operativo, interaccion con el usuario), me ha llevado a idear una forma de ver
estas relaciones, mediante la colocacion de interfaces. Llendo a un ejemplo mas concreto,
un proceso que avanza moviendose horizontalmente por un plano, (si le afecta o no la gravedad, no
cambiaria el ejemplo, porque siempre en ningun momento se ve afectado por movimientos verticales)
generalmente, el codigo que decide en que direccion y cuanto se mueve, esta fuertemente ligado al
proceso (lease esta codificado dentro del mismo proceso), en otras palabras ese mismo proceso no
podria usarse tanto para interctuar con IA como con un usuario, es decir se tienen que programar
dos procesos distintos uno para ser controlado por la IA y otro para se controlado por el o los usuarios.
Al aplicarle una interface a dicho proceso, se desacopla dicho proceso. por lo tanto se programara solo
la interfaz particular para cada caso (usuario/s, IA, etc), dejando al proceso dependiente de dicha
interfaz. Aqui el problema de la comunicacion de dicha interfaz con el proceso, lo cual puede solucionarse
de multiples maneras, por ejemplo mediante la utilizacion de datos globales, punteros a estructuras de datos,
datos en los procesos, combinaciones de estos. Aplicando esto, se puede dejar un proceso generico capaz
de ser reutilizado. En el ejemplo anterior, el proceso se moveria una cantidad, tiempo y sentido determinados,
inducidos por la interfaz, independientemente en el sentido en que sea o si esa cantidad se ha sido
producida por IA o por ordenes del usuario. Claro que teniendo en cuesta el gasto de recursos por parte
de esa interfaz, se obtiene algo mas generico y reutilizable. Siendo sincero, no he probado esto a gran escala
Aunque apostaria a que aun en ese contexto puede ser usado.

Con todo esto no trato de obligar al lector a usar mi vision, sino a darle una alternativa mas, un punto de
vista, que espero, sea diferente al suyo. Claro que lo invito a probar esta idealizacion y si es posible a
tomar y/o descartar lo que crea necesaria de la misma.


Esta obra está licenciada bajo una Licencia Creative Commons Atribución 3.0 Unported.

[erkosone]

Hola Necro_vampire, me permito opinar sobre esto, pues veo la buena fe del sistema que planteas, pero quizá no esté totalmente de acuerdo con el.

- Primero: Para programar de forma eficiente poco importa si el código es sencillo para otros, lo único que importa es que esté minimamente documentado para ti y que sea lo mas eficiente posible.
Creo que después de tantos años programando, aunque tengo muchos errores de diseño en base a la eficiencia, me doy cuenta de que las cosas no se pueden hacer de cualquier manera.. y mucho menos en juegos complejos donde un novato utilizaría 30 procesos por poner un ejemplo para crear algunas partículas como nieve o lluvia en un juego, esto todos sabemos que se hace con draw_graphic () y un solo proceso, porque necesita menos memoria, por que creas menos código a cada frame, y por mas cosas, pero seguro que si alguien lo ve programado así.. se va a llevar las manos a la cabeza al ver un proceso de 400 lineas..
Por eso que, para conseguir eficiencia, solo me preocupo de conseguirla, independientemente de la modularidad del código.

- Segundo: Crear la comunicación entre procesos "tontos" e interfaces como tu las llamas es simple, esto mediante la declaración de varios datos locales es muy sencillo, pero hasta la salida del nuevo tipo de dato que permite declarar solo estas variables a determinados TYPE de procesos mejor no abusar.. el consumo de memoria sube bastante.

En mi opinión, para hacer un ejemplo, un manual o algo así, si que estoy contigo al 100%, es buena idea lo del código reutilizable, pero para juegos de verdad esto vale hasta cierto punto.

- Yo creo que no estoy muy desencaminado cuando te afirmo que:
* A menos procesos simultaneos, mas performance.
* Usar collision() cuando de verdad es necesario, para todo lo demás usar siempre overlap().
* JAMAS caer en la tentación de comprobar colisión u overlap con 'TYPE' a menos que sea estrictamente necesario.
* Si se han de comprobar 2 collisión hacia un mismo ID, guardar el retorno de collision en un INT y usar el INT para el control de colisión, no poner mas de 1 linea que compruebe lo mismo..
* Si un proceso solo va a calcular datos, recordar añadirle VISIBLE=FALSE; esto es muy importante.
* Usar LET_ME_ALONE() lo mínimo posible, es una buena costumbre para saber que procesos están vivos y tener un mejor control de los mismos.
* Las funciones están para usarlas, parte de código que se repite una y otra vez dentro de varios bucles de diferentes procesos han de programarse en una función aparte, no tener un programa en el que se repiten mil veces lo mismo en varios sitios.
* Si no se usa un scroll o mode_7 a pantalla completa, acordarse de modificar el refresco del background a 'partial_restore', muy importante.
* El sistema de sonido está para usarlo leches! acordarse de reservar los canales de audio especificos para cada sonido que se repite durante el juego, hay que saber trabajar con esto, es muy importante.
* Aprender a trabajar a resoluciones apropiadas, 320x200 es mas que suficiente para cualquier proyecto que se haga sin gráficos originales, para las guarradas que solemos hacer vaya, que no son ni juegos ni nada, son autentica mierda a resoluciones ingentes XD..
* Aprender a trabajar a 30 FPS, no seteando tasas mas elevadas por toda la cara.. cuando no hace falta para nada.

Podría seguir hasta el infinito.. pero no viene a cuento XD..

No comprendo por que no te satisface tu código, si explicas mas concretamente a lo que te refieres siempre podemos hacer entre todos una guia de como alcanzar el máximo rendimiento, que yo hablo mucho, pero soy el primero en cagarla a lo bestia en las cosas mas estúpidas jeje.

[necro_vampire]

Erkos, con esto no pretendia meterme en el codigo en si, sino en el diseño de los procesos y hacerlos mas faciles de enterder para cualquier persona...
En si me centro mas en el proceso de desarrollo tanto en la administracion del proyecto, mas que en el codigo producido, por lo tanto tambien debo preveer que el resto del equipo de desarrollo (lease musicos, grafistas, etc) tambien entienda lo que se hace, para facilitar el trabajo a todas las partes...

El hecho de tener documentacion, es hacer que sea entendible para cualquier otra persona del proyecto, ya sea que sepa programacion o no, si llegado el caso los graficos se generan en base a las "acciones" de los procesos personajes, y dichas acciones son complejas...

en el caso de la nieve o la lluvia, tendrias un unico proceso controlador de cada copo, gotas y todos reaccionarian ante los estimulos del proceso controlador...
en lineas de codigo serian 40-60 lineas de codigo para todo, exagerando un poco...
Supongo que estare aplicando un poco del trabajo en el mundo OO...

[erkosone]

Suena muy bonito, pero no lo comparto.

- Los programas han de ser eficaces, y para nada importa si el músico no los entiendo jeje.
- Lo estás enfocando desde el punto de vista de "colegas", y está bien, pero desde el punto de vista profesional en una soberana perdida de tiempo.

[SimulatorOne]

a mi ya me gusta como esta las cosas...
cada uno programa a su manera, con mas o menos codigo, mas o menos performance...
un usuario novato se extresaria conocer la manera mas apurada de hacer el mejor codigo para ganar el maximo performance.

[TYCO]

La idea no es mala, es como el timón de abordo que traen algunos coches, ya ni acelerar tienes que hacer o marchas automáticas, es simplificar un poco lo que contiene un Process y que esté más modulado para reutilizar partes en otros Process, pero al igual que en un coche o una casa domótica no siempre son ventajas esto y tiene sus contras.

Lo mejor para está reflexión es crear un ejemplo práctico y a pequeña escala y luego otro a gran escala y ver diferencias. Vamos es como hacer una Tesis... pero llevándola a ejemplos prácticos.

[necro_vampire]

Suena muy bonito, pero no lo comparto.

- Los programas han de ser eficaces, y para nada importa si el músico no los entiendo jeje.
- Lo estás enfocando desde el punto de vista de "colegas", y está bien, pero desde el punto de vista profesional en una soberana perdida de tiempo.

erkos si tienes que armar algo que se tenga imagenes sincronizadas con audio, rogaras que el musico entienda que quieres hacer, incluso para hacer musica para determinada escena tiene que saber que sucede alrededor o que evoca la misma...

SimulatorOne, si vieras las formas de sacar performance con algunos algoritmos raros que pocos llegan a comprender xDDD
en fin, la idea es armar algo que documente un proceso de desarrollo software, basado en divlike, que sea facil de entender (por esto lo de que cualquiera entienda) y facil de programar...
incluso tambien documentar a travez de UML o algo similar...

TYCO, pense en lo del ejemplo, en cuanto tenga tiempo armare uno, pero como dije hay mas de una forma de hacer lo mismo, aunque seria ideal tener las variables locales publicas
vere si mna puedo hacer algo...

[kozka]

mira no entiendo muy bien que pides.
todo codigo es mejorable logicamente

te aconsejo hacer bibliotecas de funciones depurarlas y depurarlas ,a las que puedas llamar desde cualquier programa

[CicTec]

Hola necro,

La idea que planteas no esta mal, pero hay que tener en cuenta que cada uno programa de su forma y a veces podria costar mucho usar un estilo que otro.
Mi sugerencia es que sigas con esto, armando todos los ejemplos y la DOC para una optimal forma de utilizacion de los procesos y asi de paso vamos a discutir entre todos los pasos que se podrian mejorar/cambiar y los que estan bien, para dar una GUIA de estilo optimal generica (aunque en principio para los novatos podria ser dificil).

Animo con ello.

[erkosone]

+1 a esto, si redactas un documento explicando de que se trata y que método has utilizado puede ser un buen anexo para la sección recursos, siempre es interesante encontrar cosas así para el novato que entra y no sabe que hacer, si se dedica a leer documentos un par de días cuando ya tiene las bases claras seguro que mejorará en muchas cosas.

Aunque como dice CicTec, este no es un doc muy para los nuevos.