Jailscript (I): Consideracions Prèvies

Aquest es el primer escrit d’una sèrie que repassarà el desenvolupament d’un llenguatge de programació amb el qual poder fer JailGames de forma ràpida i còmoda

Per què des de zero?

Des de la meua època en Gavina Games he estat pensant, planificant, aprenent... sobre la creació de llenguatges de programació, compiladors i màquines virtuals. En un principi vaig intentar usar llenguatges ja existents, com Lua, Squirrel o Angelscript. El problema es que ningun d’ells em resultava còmode d’usar. Al menys no més còmode que fer-ho tot en C. A més, la idea de crear jo tant el llenguatge com la màquina virtual encarregada de executar els programes creats amb eixe llenguatge era molt atractiva. Al cap i a la fi, tot açò ho faig per diversió i aprenentatge.

Respecte al compilador, existia la possibilitat de usar Bison i Flex, però a part de quasi morir d’avorriment perdia l’oportunitat d’aprendre com fer un compilador. Al menys vaig aprendre sobre gramàtiques lliures de context.

Per últim, podria haver usat la màquina virtual de, per exemple, Lua. Però de nou, m’agradaria tindre el control de l’execució del bytecode i la integració amb el programa amfitrió en C.

Objectius

El primer llenguatge de programació que vaig aprendre, ja fa més de 30 anys, va ser BASIC, així que te un lloc a la meua memòria inesborrable. Després, al llarg dels anys, he usat en diverses ocasions Visual Basic. Així que la meua idea per al llenguatge es un BASIC simple però modern.

Respecte al paradigma, ja no es una qüestió tan clara. La primera vegada que em vaig plantejar fer un llenguatge tenia en ment un paradigma fortament orientat a events, però això ha d’anar emparellat amb un sistema que poder controlar a base de events. Consistiria en tindre arbres de entitats (Escena -> Mapa -> Personatge) que generarien events (col·lisió, tecla polsada, x segons han passat...) i el codi estaria dins de cada event, sense bucle principal. El framework que me vaig crear durant Gavina Games funcionava de forma similar, inspirat per Cocos2D, Unity..., però tot en C++. Haver tingut un llenguatge de script amb el que treballar sense recompilar i enviar al iPhone haguera sigut genial.

Més avant, ja fora de Gavina Games, sempre he buscat simplificar el codi dels meus jocs al màxim. Vaig llegir algunes notes sobre SCUMM. Ja en l’època del C64 usava un llenguatge de script propi amb multitasca col·laborativa. O siga, tindre mini-programes executant-se a l’hora, cada un amb el seu propi codi que nomes es preocupa de lo seu, en compte de tots en el bucle principal mesclats. El meu Math Wars usa una aproximació similar (però de nou tot en C++). Vaig pensar de nou en usar Lua per a fer alguna cosa així, però no vaig trobar que Lua tinguera suport per a tornar el control a C en un cert moment i a la següent iteració continuar per on anava (un YIELD), encara que si que ho te per a les seues corutines. Ron Gilbert va fer algunes modificacions en Squirrel per a aconseguir exactament això per a Thimbleweed Park, i probablement es puga fer el mateix en Lua. Però de nou, quan mes aprenc d’aquestes coses més ganes em donen de fer-ho jo mateix.

Treball previ

Conforme van passant els anys, els projectes es van solapant i el que no pareixia tindre utilitat de repent pareix tindre-la. Fa uns anys vaig començar a treballar amb microcontroladors, i una de les coses que mes em frustra es que solen usar la arquitectura Harvard, i la part del programari no es modificable durant un us normal. O siga, tu pujes el programa des de l’IDE de Arduino, per exemple, i el programa es el mateix fins que no el tornes a connectar i “cremar” un nou programa.

NOTA: No es completament cert, la part del bootloader pot reprogramar la memòria Flash al inici. Es el que fa l’IDE de Arduino, enviant al bootloader per comunicació sèrie el nou programa per a que reprograme la flash. Però no es fàcil ni pràctic.

La qüestió es que açò limitava les possibilitats de fer una consola a la que connectar cartutxos amb jocs. Una forma de solventar-ho era el que ja vau vore per Telegram: Basat en https://youtu.be/APwnDlavXlw i en https://www.tinyjoypad.com/, la consola ho te tot... excepte el propi microcontrolador! Així, cada cartutxo el que porta es el microcontrolador sencer amb el joc ja “burnejat”. Tenint en compte que usava Attiny85, que costen menys d’1€, tampoc era tan descabellat.

L’altra opció era crear una màquina virtual que executara bytecode extern. El microcontroladors de ATMega poden funcionar, com a molt, a entre 16 i 20 MHz, així que potser podria fer funcionar alguna cosa similar a un Spectrum o MSX, però tenint en compte que volia generar una senyal PAL, amb una quarta part de la resolució. Duc amb eixe projecte a ratos des de fa anys. Així va naixer PaCO, la Paco Console. Amb PaCO vaig aconseguir acabar el meu primer llenguatge de programació. Basat en BASIC i tot això. Pero en aquest cas es un llenguatge no funcional. O siga, no hi ha funcions. Tot va a base de GOTO i GOSUB, com “antanyo”. Va ser, no obstant, una gran experiència d’aprenentatge. I, en part, va a ser la base de la que vaig a partir.

L’actualitat

De fa uns anys a ara han aparegut diverses “Fantasy Consoles”, com Pico-8 o Tic-80, que han canviat un poc els meus objectius. La veritat es que tindre els editors integrats pot ajudar molt a accelerar el desenvolupament. M’agradaria fer alguna cosa similar, encara que estic debatent-me fins a quin punt.

La qüestió es que, tornant al llenguatge en sí, el paradigma, les capacitats, la integració i altres coses no son estrictament imprescindibles ni inamovibles. Puc fer una versió simplement funcional del llenguatge, i mes avant fer una versió “++” amb suport per a classes. Puc integrar-ho en un sistema clàssic, o en un sistema de funció “loop”, o en un sistema de events, o en un sistema de entitat-component...

Així que, mans a l’obra. Aniré comentant sobre cada aspecte del desenvolupament que em parega interessant.