Pensando la manera de jugar cierto juego (The Wizard's Castle, DOS, 1981) arriesgándose lo menos posible, y cómo describir eso, escribí esto:
Está incompleto, claro, mi lío para empezar es con los pisos. Normalmente se diría:
¿No?

¿Es posible dar esas instrucciones usando estados como puse antes, cómo, o no?

Estado 2: Te faltan ítems seguros y aún no has revisado todos los pisos.
La 2nda parte de eso es redundante, si te faltan no has revisado, pero de algún modo debo decir que debe irse a otros pisos cuando se tengan los ítems S del actual.

Lo reintento:

Estado 2: Te faltan ítems seguros (y aún no has revisado todos los pisos).

m, retry:

Estado 2: Te faltan ítems seguros del piso actual:
- Agarrarlos y luego ir al siguiente piso.

Estado 3: Has recorrido todos los pisos (ergo deberías tener todos los ítems S):

m, retry:

Estado 2: No has recorrido todos los pisos (ergo te faltan ítems S) y te faltan ítems seguros del piso actual:
- Agarrarlos e ir al siguiente piso.

Listo.

Es decir, parece que algo como:
Se convertiría en:
No me doy cuenta, puse cosas distintas.

Tenía:
Y se convierte en:
Estado 2: No has recorrido todos los pisos (ergo te faltan ítems S) y te faltan ítems seguros del piso actual:

¿Cual es la lógica, si es que la hay, tiene que ver una cosa suficiente con la otra o...?

A ver algo más simple:
Pero esto en realidad puede ser un sólo while con 2 condiciones... ¿lo mío también?


Ya... ¿entonces "programar" con estados es tan parecido a usar whiles, por qué al principio no parecía? 

A continuación 2 funciones iguales hasta la marca roja y que son usadas en un mismo programa:

Obviamente no se ve todo, pero no creo que importe, lo importante es que quiero convertir lo repetido (verde y amarillo) en una misma función, pero así como está termina (rojo) en medio de un if (que empezó en la zona amarilla, donde todo aún es igual). ¿Es posible hacer una función que incluya lo amarillo o debo conformarme con incluir sólo lo verde?

Por si a alguien le interesa, las diferencias entre los códigos son:
1- El izquierdo crea variables en ciertos casos, hasta llegar a 15, y el otro nunca.
2- El izquierdo en cierto punto deja de ejecutarse y ejecuta al otro. Ese cuando deja de ejecutarse da un mensaje y termina el programa.
Básicamente eso.

Luego miro mejor tu lenguaje (¿el link que has puesto ahora es a eso?), pero me parece que poco cambia entre poner
if (valores comparador(o valor que se convierta en comparador, creo que es posible) valores) {
o
si (condición)

Si logras que la máquina entienda lo 2ndo, bien, pero es como que estás diciendo que la gente es demasiado tonta como para programar normal, como si en el futuro uno pudiera escribir en la calculador * 8 5 y ella reacomode todo para que se haga la operación debida ¿es necesario, la gente no puede escribir algo tan simple?
Además ocurren ambiguedades, en este momento no se me ocurren pero... algo como "Quiero pan con queso o carne". Se puede interpretar como:
A- Dar pan y queso, o dar pan y carne.
B- Dar pan y queso, o dar carne.
Una coma cambia mucho: "Dame pan con queso, o carne", o un paréntesis: "Dame pan (con queso) o carne".

Quiero agua y jugo de naranja, y la máquina te trae un vaso que tiene agua y jugo de naranja mezclado ¿quién tiene la culpa?

Un vaso de plástico, ok. Uno de agua, te trae hielo con forma de vaso (vaso hecho con hielo) xD
Me fui por las ramas.

Algo que estaría bueno es por ejemplo "Modifica esta rom de modo que el jefe final sea Mega Man y actúe con mucha inteligencia", yo que sé, hay mucho que estaría bueno, pero si fuese tan fácil ya se hubiera hecho, aunque hay mucho secretismo en el tema, es decir, normalmente no se revelan códigos o se revelan de un modo que nadie los entiende. Otra podría ser "convierte este exe en un código de Python". Pero bueno, tampoco es que sea tan útil, la gente quiere más riqueza, mujeres, viajar, mejores casas, yo que sé, saber informática no implica saber resolver los problemas más reales me parece, a menos que te dediques específicamente a eso, pero yo lo hago en parte y a penas avancé xP
¿No consigues buen trabajo de algo relacionado con la Informática? Quizá te convenga estudiar otra cosa. Yo intentaría aprender otras cosas si pudiera, y de hecho lo intento, pero digo, no me voy a poner a hacer un curso de electricista por ejemplo, por varios motivos, pero sí he estado leyendo sobre los diodos por ejemplo. Si eres hábil aprendiendo cosas y puedes trabajar de eso, adelante.

No conocía el concepto, leí esto:
https://www.enter.co/especiales/dev/que-es-protestware-desarrolladores-saboteando-su-propio-codigo/
y me pareció incoherente pero no lo entendí del todo.

Si ware puede usarse como final de soft o hard, sustituir esos principios por protest no llega ni a dejar en duda si se refiere a hardware o software, porque al no estar la palabra completa no es algo de eso, es como decir demoprotesta o protescracia, no se puede interpretar como "protesta usando democracia", sí como "protesta usando un demo", "protesta usando a la mayoría", o "protesta usando un sistema de gobierno", no creo que sea lo mismo...

Pero existen conceptos o nombres como Freeware, Abandonware, Malware, y todos son software creo, o da igual, son cosas relacionadas con Informática. Protestware tendría sentido que sea "Software hecho para protestar", "Software que se volvió un medio de protesta", e incluso "Protestar con Software", pero dudo que tenga sentido llamar Protestware a borrar o limitar software como medio de protesta (a menos que eso haya sido con software). Una Tomatoprotest podría ser una protesta arrojando tomates (cosa poco ética por cierto, mejor comerlos y arrojar basura), no me parece lógico llamar Tomatoprotest a esconder los tomates, porque no se están usando tomates para protestar, al contrario, aunque sí, bueno xD

Ya no le veo el problema. Esconder una cosa es una forma de usar esa cosa.

Las palabras así sirven para llamar la atención y para resumir. Si no dices protestware deberías decir "protest using software" y no hay mucha necesidad de eso. No sé si existen palabras como Biciride, Motoride, Carrride, etc, pero también servirían de resumen. Hay muchos resúmenes similares que pueden hacerse.

Había olvidado que entiendes el concepto ¿cual es tu queja entonces?

Por lo que he visto en otros mensajes tuyos también, parece que crees que sabes suficiente de Informática y haber aportado suficiente como para haberte vuelto más o menos exitoso pero que debido a una conspiración de empresas, políticos y no sé qué más no has tenido éxito. Sabes más que yo probablemente, y más que la mayoría, pero no creo que sea tan simple como que la culpa la tiene una conspiración. Ser exitoso, nos guste o no, depende de hacer cosas que a la gente le gusten, salvo ciertas excepciones en que la vuelves dependiente de lo que haces, o incluso media esclava. Por ejemplo yo no creo que el fútbol sea gran cosa, es casi siempre lo mismo ¿es lógico que la gente pague tanto y se apasione tanto por ver más o menos lo mismo una y otra vez? Creo que no, pero lo hacen, y así los que se dedican al negoci del fútbol son exitosos aunque lo que hagan parezca algo bastante común y corriente, date cuenta que no hacen cosas especiales, eventos donde puedas jugar tú contra los profesionales por ejemplo, o al menos yo no sé de eso, lo que muestran en general son partidos, mi padre escucha sobre fútbol a cada rato y siempre es sobre lo más oficial, en fin, y sin embargo alguien que se esfuerce en mejorar algunas cosas puede que no reciba un peso porque no es apreciado, así es la vida, agradece que no te manden a la hoguera o cosas así como hacían antes. Pero quizá lo que has hecho no sea tan grandioso como crees, no sé de eso, me habías dado un link en que al inicio se veían insultos en mayúscula, no presté mucha atención al resto. Si presentas algo bueno así, creo que espantas antes de que llegue a verse lo bueno. La presentación o exposición es importante. La gente no entiende todo lo mismo que tú, una vez una muchacha me dijo "no me lo tires como si fuese un ladrillo", no des una página que cuesta entenderla, o al menos a mí me costó.
El éxito en muchos casos parece cuestión de suerte. Por ejemplo un tío se hizo viral porque cada día subía un video donde mostraba un dibujo de estilo anime, mostrando cómo iba aprendiendo, pero el tipo creo que ya sabía dibujar bien. Supuestamente aprendió muy rápido y además ya era muy conocido, un youtuber que hacía chistes. Pero es como que sólo por esa oavadita de hacer un dibujito al día y mostrarlo ganaba dinero. Yo tengo muchas libretas de muchas hojas llenas y YT no me dió un peso por eso ni me lo darían seguramente aunque las mostrara. Es cuestión de suerte: Si te gusta hacer chistes/dibujitos, ganas, si te gusta entender la realidad, ganarás si logras hacer algo indudablemente útil, sino sólo alégrate de haber avanzado o haber podido intentarlo. Por supuesto habrá gente que se dedica a hacer chistes o dibujar y aún así le va mal (en Japón literalmente los animadores se mueren trabajando), pero me parece que son campos en que es más probable ser apreciado.

Si tanto te interesa ser exitoso para estar económicamente normal en vez de estar tan mal como dices estar, podrías intentar hacer cosas que a la gente le guste, aunque a ti no, o buscar algo que guste suficiente a ellos y a ti. También podrías enfocarte en hacer cosas que gusten a la gente rica que querría pagar por lo que haces, porque tener a un montón de fans pobres piratas no sirve de mucho.

Los archivos de imagen, video, sonido ¡todos o casi! están escritos en un lenguaje que es difícil de entender por qué lo hicieron tan difícil de entender, no lo entiendo, y ya no tengo mucha esperanza en avanzar en eso, no me meto en eso.

No es para un juego sino una autobiografía que incluye imágenes. En cierto punto en el colegio, volví desde el recreo, vi que mi mochila estaba en el suelo y un tipo sentado en el asiento donde la había dejado, y un amigo suyo estaba sentado al lado. Cuando les pregunté qué pasó, el 1ero que comenté me dijo que cuando ellos llegaron estaba así, y el otro se reía. He aquí la representación, por ahora:

Veo que tiene transparencia, yo la pego en Word así que no lo noté, no importa. Vale decir que no sé ni me gusta dibujar, así que es lo que hay, no esperes mucho detalle en las imágenes o que representen fielmente el hecho xD

Hace poco hice un tema similar:
https://foro.elhacker.net/programacion_general/iquestcomo_los_numeros_se_producirian_mas_rapido_en_mflash_5-t520859.0.html
Pero este no es tanto sobre Flash, aquél más o menos ya lo resolví.

Este código produce dibujos negros y blancos:

   actions for fotograma 1
      PixelesdeLargo = 1;
      // En el frame 3 se repite:
      function Variar () {
         PixelaModificar = "ColordePixel"+Puntero;
         ColordePixelaModificar = eval(PixelaModificar);
         // ¿El pixel puede cambiar de color?
         if (ColordePixelaModificar<1) {
            // Sí, hacer los cambios:
            set (PixelaModificar, ColordePixelaModificar+1);
            Col = new Color("Pixel"+Puntero);
            Col.setRGB(parseInt(0, 16));
            // Para juzgar: ¿El dibujo es repetido?
            SumadePintados = SumadePintados+1;
            // ¿El píxel está en el extremo derecho o abajo, donde no había en una hoja más chica?
            if (Puntero/PixelesdeLargo == Math.floor(Puntero/PixelesdeLargo) or Puntero>MinPixelInferior) {
               // Sí, actualizar SumadePintadosNuevos:
               SumadePintadosNuevos = SumadePintadosNuevos+1;
            }
            // ¿El dibujo tiene píxeles donde no había en una hoja más chica...
            // y son al menos (PixelesdeLargo) píxeles?
            if (SumadePintadosNuevos>0 && SumadePintados>MinSumadePintados) {
               // Sí, hacer dibujo y dar tiempo para verlo:
               Puntero = MaxPosiciondePuntero;
               play ();
            } else {
               // No, el dibujo es repetido, no mostrarlo y hacer otro:
               Puntero = MaxPosiciondePuntero;
               Variar();
            }
         } else {
            // El pixel no puede cambiar de color, resetearlo:
            set (PixelaModificar, 0);
            Col = new Color("Pixel"+Puntero);
            Col.setRGB(parseInt("FFFFFF", 16));
            SumadePintados = SumadePintados-1;
            // ¿El píxel está en el extremo derecho o abajo, donde no había en una hoja más chica?
            if (Puntero/MaxPosiciondePuntero == Math.floor(Puntero/MaxPosiciondePuntero) or Puntero>MinPixelInferior) {
               // Sí, actualizar SumadePintadosNuevos:
               SumadePintadosNuevos = SumadePintadosNuevos-1;
            }
            // ¿Hay un pixel anterior?
            if (Puntero>1) {
               // Sí, apuntar a ese:
               Puntero = Puntero-1;
               // Continuar haciendo el dibujo:
               Variar();
            } else {
               // No, aumentar tamaño de hoja y reiniciar.
               gotoAndPlay (2);
            }
         }
      }
   actions for fotograma 2
      PixelesdeLargo = PixelesdeLargo+1;
      // Colocados:
      Pixeles = 0;
      DistanciaEntrePixeles = 384/PixelesdeLargo;
      PosicionX = 64-DistanciaEntrePixeles;
      EnlaFilaActual = 0;
      PosicionY = 0;
      MaxPosiciondePuntero = PixelesdeLargo*PixelesdeLargo;
      Puntero = MaxPosiciondePuntero;
      // Píxeles pintados:
      SumadePintados = 0;
      MinSumadePintados = PixelesdeLargo-1;
      MinPixelInferior = PixelesdeLargo*(PixelesdeLargo-1);
      // Píxeles pintados que no estaban en hojas de menos píxeles:
      SumadePintadosNuevos = 0;
      // Agregar píxeles en blanco:
      do {
         Pixeles = Pixeles+1;
         if (EnlaFilaActual<PixelesdeLargo) {
            EnlaFilaActual = EnlaFilaActual+1;
            PosicionX = PosicionX+DistanciaEntrePixeles;
         } else {
            PosicionX = 64;
            EnlaFilaActual = 1;
            PosicionY = PosicionY+DistanciaEntrePixeles;
         }
         trace ("El pixel "+Pixeles+" se colocó en "+PosicionX+", "+PosicionY);
         attachMovie("mPixel", "Pixel"+Pixeles, Pixeles);
         setProperty ("Pixel"+Pixeles, _x, PosicionX);
         setProperty ("Pixel"+Pixeles, _y, PosicionY);
         setProperty ("Pixel"+Pixeles, _width, DistanciaEntrePixeles);
         setProperty ("Pixel"+Pixeles, _height, DistanciaEntrePixeles);
      } while (Pixeles<MaxPosiciondePuntero);
      stop ();
   actions for fotograma 3
      stop ();
   actions for Vacío
      onClipEvent (enterFrame) {
         _level0.Variar();
      }
   actions for fotograma 4
      stop ();
   actions for fotograma 5
      gotoAndPlay (3);

La función se repite dentro de si misma, supongo que un do while sería mejor, no me di cuenta, pero ese no es el tema, el tema es que hago algo así:
Si ColordePixel4 puede colorearse, hacerlo y mostrar dibujo.
sino resetearlo. Si el 3 puede colorearse, hacerlo y mostrar dibujo.
sino resetearlo. Si el 2...
Y así hasta el 1.
Cuando hay más píxeles, eso se repite más veces.

¿Qué otro método más rápido sería mejor? ¿es posible, cómo? Me refiero a algo que varíe todo lo necesario sin tener que variar un puntero y repetir un while y estar reseteando 1 cosa a la vez...

Si un humano quiere escribir una lista así:
0001
0010
0011
0100
etc
No sé bien cómo se hace, pero es como que se mira dónde hay que sumar y si los valores a la derecha están al máximo se resetean. O sea, desde la izquierda se busca el 1er valor que no esté al máximo, se lo aumenta y se resetean los a la derecha suyo. Pero nosotros los humanos es como que no necesitamos mirar desde la izquierda, ya más o menos podemos anticipar en dónde estará el próximo número que debe aumentarse ¿o no?

No sé, a mí esa manera me resulta muy lenta, variando las cosas de a una, siento que debe haber algo mejor.

Una posibilidad sería hacer sumas normales y luego convertirlo en el valor que se precisa:
0 -> 0000
1 -> 0001
2 -> 0010
Hacer la conversión no creo que tarde mucho ¿pero si los posibles valores fuesen más de 9 o de 10? Por eso uso varias variables, no sólo 1. Uds supongo que usan arrays, pero creo que en el fondo es igual. Si son menos de 9 o 10 posibles valores la conversión es literal:
ColordePixel4 = Caracter4
ColordePixel3 = Caracter3
etc
Sino creo que se deben hacer operaciones matemáticas para cada uno y eso implica usar un do while...

Hay que inventar algo mejor o díganme qué hay que no sé xD

Para colmo, en el caso particular de los dibujos, tengo que variar unas variables y luego debo variar colores en base a ellas, creo que lo puedo hacer más rápido, pero el punto es que tendría que usar un do while también (edit: quizá no, probaré).

Tampoco es cuestión de estar haciendo los dibujos desde 0 en cada caso, yo intento que se varíen sólo los pixeles que deben variarse.

¿Ideas, info?

Asumiré que es imposible que funcione, aunque no sé la causa.

He visto que la posición del mouse llega a actualizarse en cada frame con framerate 120, así que ese número no sería el problema.

Y disminuyendo el framerate (no quiero) funciona bien, así que el código no es el problema.

 ¿Tal vez la posición sólo se actualiza rápido luego de que lleva un rato moviéndose? De momento no sé cómo ver eso. ¿Cómo podría? Debería poner un contador de tiempo y... ver si al inicio se actualizaba tan rápido como luego. Haré eso.

Edit: Confirmado que no sirve.

Totalmente, en Quora hay muchos que responden así o les dices "leer mi comentario" y en algunas respuestas que dan se nota que no lo leyeron y parece que hubieran usado un bot, nada de eso tiene sentido, es una pérdida de tiempo, se mira la respuesta para nada.


En cuanto a los foros, yo también me he quedado con la duda de qué ha pasado, no entiendo por qué Facebook es más exitoso (dicen). El problema de los foros probablemente son los trolls, eso hace que se desconfíe de cualquiera y ponen altas exigencias para participar o te banean por cualquier cosa, o quién sabe, a mí me han baneado de varios lados no sé por qué.

Ah, me habían recomendado Likedin, prueba eso. Yo no tengo mucha paciencia como para andar cambiando de sitios, es lioso aprender a usarlos.

- Casos de (dar una instrucción mediante presionar cierto botón o algo similar):
En general: Mide la velocidad promedio conque el jugador presiona cierto botón.
El conteo es pausado (me refiero a que sólo cuenta como "caso" el momento en que se presionó un botón o se movió el mouse; si se presionó o movió y no se dejó de hacerse sólo cuenta como 1 caso, debe haber una pausa entre los "casos").
Ejemplo en que más valor implica más habilidad: Veces que aprendió o se burló del oponente (asumiendo que mientras lo hace se pone a si mismo en riesgo).
Ejemplo en que más valor implica menos habilidad: Veces que recurrió a activar un escudo.

- 1er frame (frame = instante con cierta duración, es una forma de medir el tiempo) en que ocurrió un caso de:
General: Cuánto tardó en presionar cierto botón por 1era vez.
Conteo pausado.
Habilidoso: Qué tan rápido empezó a correr luego de la señal.
Negativo: Qué tan rápido tuvo que frenar antes de llegar a la meta.

- Último frame en que ocurrió un caso de:
General: Cuánto tardó en presionar cierto botón por última vez.
Conteo pausado.
Habilidoso: Cuánto tiempo resistió antes de escapar, o cuan cerca estuvo de presionar el botón en el último momento posible (en juegos de Golf suele haber algo parecido a eso).
Negativo: Cuánto tiempo tardó en presionar el botón de aprender (si sobrevivió).

- Frames en que ocurrió un caso de:
General: Tiempo en que se estuvo presionando algo.
Conteo normal: Diferencias con respecto a "Casos de":
1: Si se hace una misma cosa más de una vez en un mismo frame (lo cual es casi imposible porque los frames cambian muy rápido; es posible por ejemplo si lo que se mide son los botones diferentes presionados al mismo tiempo, porque en ese caso pueden ser más de 1 a la vez), sólo cuenta como 1.
2: Aquí dejar presionado 1 botón durante 5 frames, por ejemplo, cuenta como 5 casos, no se necesita presionar-soltar.
Habilidoso: Si mantener presionado el botón implica desactivar un escudo.
Negativo: Si implica activarlo.

- Mínima duración de un caso de:
General: Se explica solo.
Conteo normal.
Habilidoso: Es así generalmente, presionar y rápidamente tener listo el dedo para presionar otra cosa, pero podría ser especialmente positivo si se debe golpear algo lo más suavemente posible y depende de cuánto tiempo se haya presionado el botón.
Negativo: Similar a lo anterior, difícilmente resulta negativo, el ejemplo podría ser en un juego en que se deba dar mucha energía a algo (mantener el botón presionado un tiempo) y darle poca sea un desperdicio (en juegos de automóviles no vale mucho porque, incluso acelerar durante un poquito es mejor que no acelerar).

- Máxima duración de un caso de:
General: Parece igual que "Frames en que ocurrió un caso de" pero eso cuenta la duración total y esto la máxima antes de una pausa.
Conteo normal.
Habilidoso: Si mantener presionado el botón implica desactivar un escudo.
Negativo: Si implica activarlo.

- Por frames, mínimos casos de:
General: Mínima velocidad de presión. Para hacer esto, cuando hay un frame en que no hubo presión se empieza a contar en cuántos más seguidos no la hubo. El conteo que resulte mayor es X. El resultado será "0 casos en X frames". Si se presionara en absolutamente cada frame (lo cual se supone imposible como ya expliqué), el resultado sería "X casos en X frames", y si además de eso a veces se presionara varias veces por frame, sería "VECES casos en 1 frame". Todo esto puede ser confuso pero es la mejor forma que se me ocurrió de hacerlo.
Conteo pausado.
Habilidoso (como de costumbre: Mayor valor es mejor): Cuando presionar rápido un botón hace que un golpe sea más fuerte.
Negativo: Dar la misma orden varias veces (asumiendo que es innecesario).

- Por frames, máximos casos de:
General: Máxima velocidad de presión. Para hacer esto, cuando hay un caso se empieza a contar cuántos frames se tardó en ocurrir otro. El conteo que resulte menor es N. El resultado será "2 casos en N frames". Si el caso ocurriera en cada frame, sería "X casos en X frames", y si además de eso a veces el caso ocurriera varias veces por frame, sería "VECES casos en 1 frame".
Conteo pausado.
Los ejemplos de antes son válidos.

- Mínima/máxima distancia (en frames) entre 2 casos de:
Este es un método peor de medir la velocidad mínima/máxima de eventos, ya que uno podría ocurrir en un mismo frame más de 1 vez. No le veo sentido a usarlo.

- En un mismo frame mínimos/máximos casos de:
Por si mismo es poco útil pero es complementario de lo anterior, pero el método que puse más arriba combina ambos, ergo tampoco le veo sentido a usar este.

Luego hay relaciones como:
Mínima distancia (en frames) entre una instrucción A y una B (asumiendo que puede ser 0 si ambas ocurrieron en un mismo frame).

Condiciones como:
Casos de A mientras A<B
donde A es una instrucción (presión de botón, etc).
e B es un número fijo u otra instrucción.

Y lo podemos mezclar con propiedades, como:
Casos de A mientras el largo de A<B

...pero eso lo pensaré luego.

En resúmen es:
- Casos en que se da cierta instrucción (debe haber pausa).
- 1er momento en que se da.
- Último momento en que se da.
- Tiempo en que se da la instrucción.
- Mínima duración conque se repite.
- Máxima duración conque se repite.
- Mínima velocidad conque se repite (debe haber pausa).
- Máxima velocidad conque se repite (debe haber pausa).

¿Qué me falta?

Yo en general cuando sé respondo salvo que me parezca que quieren hacer malware o algo así, o si la pregunta me parece muy absurda (por ejemplo una vez uno preguntó qué pasa si martillaba una moneda a diario).

Ya sabes que mucha participación no hay, así que no tiene mucho sentido que te sorprenda que no te respondan, más si tus preguntas son difíciles de responder.