Framsticks

Na razie staram się poznawać Framsticks i jestem dopiero w trakcie czytania jego głównego podręcznika. Opiszę może parę pewnych moich wrażeń, wyobrażeń, pomysłów, propozycji dotyczących głównych programów tego systemu.

---

Obecnym interpreterom światów trzeba wskazywać osobno różne pliki (o typach gen, expdef itd.), będące różnymi fragmentami całego programu świata. Wg mnie bardziej naturalne byłoby chyba, gdyby każdy (zapisany w dysku) świat (do wykonywania) był określony tylko przez jeden program, tzn. zapisany jako jeden plik, a więc z tylko jednym swoim identyfikatorem (nazwą pliku). Ten plik powinien oczywiście być zestawem wielu plików (m.in. o powyższych typach: expdef, gen, neuro itd.).
Tym plikiem programu świata mogłoby być:
- miejsce, gdzie jest tamten zestaw zwykłych plików
albo
- plik końcowy (w sensie poziomu SO), zawierający (pod)pliki w takim sensie, w jakim plik typu ZIP zawiera w sobie inne pliki, czy plik typu MDB (z MSAccess) zawiera swoje 'wirtualne' (pod)pliki różnych typów.

Wg tego, co czytałem, to dotychczasowe interpretery światów nie potrafią zapisać nie tylko aktualnego stanu wykonywanego świata (co byłby przydatne dla okresowego tworzenia kopii bezpieczeństwa wykonywanego świata, a więc możliwości kontynuowana świata po np. awarii zasilania komputera lub po przeniesieniu świata do innego komputera), ale nie potrafią też zapisać aktualnego stanu żyjącego tam stworzenia (jego fenotypu) – w tym stanu jego mózgu (sieci neuronowej), o być może zmienionej strukturze (w porównaniu do swojego stanu za/noworodkowego), powstałej w trakcie rozwoju osobniczego, w tym uczenia się. Do zapisu takiego fenotypu prawdopodobnie najbardziej nadawałby się (spośród opisanych języków) język f0. Taka możliwość byłaby przydatna dla skopiowania dorosłego stworzenia do innego (zgodnego) świata do innego komputera (np. innego użytkownika).

Co pewien czas (automatycznie-okresowo lub na życzenie użytkownika) interpreter świata powinien zapisywać (po chwilowym zatrzymaniu czasu tego świata) aktualny stan świata (jego 'kopię bezpieczeństwa') jako plik, aby można było potem w razie potrzeby wczytać go z dysku i kontynuować wykonywanie (programu) tego świata od momentu jego zapisania - dotyczy to szczególnie światów wykonywanych bardzo długo (dni, tygodnie).
Najlepiej by było, aby każdy obiekt świata (środowisko, stworzenia i ich wytwory (np. budowle, książki)) był tam (w pliku) zapisywany jako osobny obiekt. W zapisie stworzeń (aktualnego dokładnego stanu ich ciał) powinno chyba być dla każdej ich części: miejsce (współrzędne), ukierunkowanie, prędkość, kręt, a być może też odkształcenia, naprężenia i inne cechy. Dlatego do zapisu wszystkich obiektów świata najlepiej nadawałby się jakiś język zgodny z językiem (metodą), w którym zapisywane są wszystkie obiekty w świecie będącym w (wirtualnej) pamięci operacyjnej interpretera.

W drugiej (alternatywnej) metodzie zapisu (np. gdyby z poprzednią metodą zapisu obiektów były trudności) oprócz skopiowania startowej wersji programu świata (tzn. plików typów expdef, gen itd.) wystarczyłoby jako jeden z (pod)plików zapisać aktualną zawartość wirtualnej pamięci (operacyjnej) interpretera świata - chodzi tu o tę pamięć wirtualną (czy tę jej część), w której jest zapisany cały wykonywany świat i stan jego wykonywania (czyli wszystkie informacje potrzebne do kontynuowania wykonywania świata po wczytaniu go z pliku przez interpreter świata). Zakładając (nie znam metody zapisu (organizacji) świata w pamięci operacyjnej), że na poziomie wirtualnym (zorganizowanym przez interpreter (lub wyżej)) metoda zapisania świata (a przynajmniej jego rozumienia przez interpreter) jest dokładnie taka sama dla każdego interpretera w każdym systemie operacyjnym i w każdym typie komputera (np. PC, Amiga itd.).

---

Czytałem też, że jest tworzona jakaś nowa wersja sieciowa tego systemu (ale nie zrozumiałem tego dokładnie). Natomiast wg tego, jak próbowałem wyobrazić sobie ulepszone działanie takiego przyszłego systemu Framsticks, to mogłoby to wyglądać tak:
Główny interpreter światów (odpowiednik CLI) na początku wczytywałby program świata (startowy lub zapisany wcześniej jako kopia bezpieczeństwa) i go wykonywał.
Drugi główny program dla użytkownika (odpowiednik GUI) służyłby do obserwacji (podglądu), co się dzieje w takim wykonywanym świecie (tryb obserwacji), a w drugim trybie swojego działania (tryb ingerencji) mógłby też modyfikować świat, program świata i jego wykonywanie.
Ten program (GUI) sam nie byłby bezpośrednio interpreterem, lecz podłączałby się do interpretera, a poprzez niego do świata (lub tylko do wirtualnej pamięci operacyjnej interpretera, gdzie byłby świat - ale raczej tylko w trybie obserwacji (chyba że sam też zawierałby w sobie własny interpreter, co byłoby jednak może trochę 'nadmiarowe')).

Interpreterów światów (odpowiedników CLI) mogłoby być włączonych w komputerze dowolnie wiele - te interpretery (każdy ze swoim wykonywanym światem) mogłyby być też w innych komputerach - a drugi program (GUI) miałby do nich dostęp przez sieć lokalną i przez Internet.
Potrzebna byłaby więc trzecia metoda ("zewnętrzna") dostępu do tych interpreterów i światów. Ten program razem dodatkowym oprogramowaniem w sieci (we wszystkich komputerach z interpretatorami światów) służyłby do zarządzania wykonywaniem światów. Byłby to więc taki wirtualny (pod)system operacyjny do zarządzania wykonywaniem światów. Użytkownik mógłby te światy kopiować i przenosić przez sieć do innych komputerów, kolejkować, wznawiać i wstrzymywać ich wykonywanie (zachowując je w pamięci operacyjnej lub zapisując w dysku, aby ją zwolnić), tworzyć kopie bezpieczeństwa ('ręcznie' lub określając okres automatycznego jej tworzenia) itd...