Gra Rubik, którą napisałem w roku 1998, nie wyróżniała się absolutnie niczym. Była słabo zbalansowaną i niezbyt ciekawą grą logiczną działającą w trybie tekstowym systemu MS-DOS. Dla mnie jednak ma szczególne znaczenie – po pierwsze zapewniła szóstkę z informatyki na świadectwie maturalnym, po drugie była moją pierwszą produkcją, która trafiła do masowego odbiorcy.
Jak to możliwe? Gra została opublikowana na cover CD miesięcznika PC World Komputer 7-8/98, wydanego w 130 tysiącach egzemplarzy. Ilu czytelników uruchomiło Rubika? Nie mam pojęcia. Czy ktoś zrobił to więcej niż raz? Nie sądzę. Ale i tak było fajnie.
Wygląd i gameplay
Oto ekran tytułowy, menu gry, instrukcja i plansza główna. Nie pytajcie, proszę, o markę „Darksoft” – kilkunastoletni Tomek użył pewnie pierwszej nazwy, jaka przyszła mu do głowy.
Gra polega na usunięciu z planszy wszystkich czerwonych prostokątów. Kliknięcie wybranego prostokąta skutkuje odwróceniem kolorów pola klikniętego oraz czterech sąsiednich. Celem gry jest wyczyszczenie planszy w takiej liczbie kroków, w jakiej dokonane było losowe mieszanie stanu początkowego – lub mniejszej.
Ktoś chce zagrać? W dzisiejszych czasach możliwe jest osadzenie emulatora systemu MS-DOS bezpośrednio w przeglądarce, oto Rubik online! Uwaga – wymagana jest mysz lub klawiatura, na komórce się nie da. W razie problemów proszę spróbować bezpośrednio na stronie archive.org.
Gra znudzi się każdemu najdalej po trzeciej rozgrywce, w jaki więc sposób tak mało angażująca pozycja trafiła na cover CD czasopisma? Proste – wysłałem grę do redakcji a redakcja ją opublikowała. To wszystko.
Czasopisma komputerowe na przełomie wieków
Lata 1998-2000 były złotą epoką polskich czasopism komputerowych. Dostęp do internetu był powolny i drogi zaś treści dostępnych po polsku było niewiele (oczywiście treści pisanych, wideo online nie istniało). Nasycenie komputerami klasy PC wzrosło jednak na tyle, że u wielu użytkowników pojawił się głód wiedzy oraz pragnienie eksploracji. Odpowiedzią wydawców prasy na pierwszy trend było zwiększanie objętości periodyków, na drugi – dołączanie płyt CD-ROM z oprogramowaniem.
Pamiętajmy – były to czasy, kiedy wydajność sprzętu wciąż jeszcze podwajała się co kilkanaście miesięcy. To pociągało konieczność regularnego kupowania nowych dysków, procesorów, kart graficznych, co z kolei napędzało rynek reklam. O ile dobrze pamiętam ówczesną ekonomię, dwie sprzedane strony reklam fundowały w miesięczniku trzy strony redakcyjne. W szczytowym okresie magazyn CHIP miał ponad 300 stron przy nakładzie osiągającym 150 tysięcy egzemplarzy.
„Okładkowe” płyty CD-ROM były odpowiedzią na zbyt wolny internet. Typowy użytkownik modemu był w stanie pobrać pliki rozmiaru kilku megabajtów, ale zasoby rozmiaru setek megabajtów (np. aktualizacje do Windows) pozostawały poza jego możliwościami. Czasopisma rywalizowały też między sobą atrakcyjnością programów zamieszczonych na cover CD, zwłaszcza pełnymi wersjami aplikacji. Zanim popularność zdobyły napędy DVD, normą było dołączanie do każdego numeru dwóch a czasem i trzech płyt CD.
Programy polskojęzyczne były cenione, bo interesowali się nimi czytelnicy nie znający angielskiego. To właśnie dlatego moja gra trafiła na płytę dołączoną do magazynu PC World Komputer – napisałem ją i wysłałem do redakcji w marcu 1998, cykl wydawniczy pozwolił umieścić ją na płycie A wakacyjnego numeru 7-8/1998.
Każdy może sprawdzić, że historia ta nie jest zmyślona. Serwis archive.org dysponuje kolekcją obrazów ISO, również płyta 7-8A/98 jest tam dostępna. Dodatkową wartość edukacyjną przyniesie zetknięcie z graficznymi launcherami aplikacji zawartych na płycie:
Kod źródłowy
Oryginalny plik wykonywalny Rubika ma dokładnie 13615 bajtów. Tyle wystarczyło, by pomieścić całą logikę rozgrywki, obsługę sterowania, animowane intro oraz menu z instrukcją.
Przez wiele lat sądziłem, że kod źródłowy gry zaginął, bo regularne backupy zacząłem robić dopiero po kupnie nagrywarki płyt CD-R. Okazało się jednak, że jakiś stary plik backup.zip zawierał wewnątrz plik programy.zip a w środku odnalazłem zaginione źródełka.
Co było w środku? Możecie sprawdzić sami – wszystkie pliki niezbędne do skompilowania gry znajdują się w repozytorium github.com/tomekziel/rubik/
Okazuje się, czego w ogóle nie pamiętałem, że kolorowe tła w trybie tekstowym ANSI powstały przy użyciu aplikacji The Draw – umożliwiała ona eksport do formatu używanego w języku Turbo Pascal.
Miałem już wówczas dostęp do kolekcji SWAG zawierającej zbiór różnorakich bibliotek i procedur Pascala. W grze wykorzystałem cudze funkcje pomocne przy:
- obsłudze myszki
- ukrywaniu mrugającego kursora
- płynnym przechodzeniu między ekranami
- obsłudze klawiszy funkcyjnych
- wykrywaniu środowiska Windows 3.x
Plik z logiką gry udowadnia, że składnia języka Pascal zestarzała się kiepsko, czytelności nie wzmaga też moje niekonsekwentne formatowanie i mieszane polsko-angielskie nazewnictwo zmiennych. Jestem jednak jak najdalszy od pouczania młodego siebie w temacie jakości kodu. Ważne, że dziś umiałbym to napisać lepiej. Wolę tak, niż odwrotnie.
Dlaczego kiedyś było trudniej, ale łatwiej
Programowanie na pececie w latach ‘90 było trudne. Środowiska programistyczne – np. popularny Turbo Pascal – onieśmielały początkującego liczbą opcji, pełnoekranowymi ściągawkami skrótów klawiszowych, trudnymi do zrozumienia komunikatami itp.
Dodajmy do tego, że ze znajomością języka angielskiego było dużo gorzej, niż dziś – szkoły dopiero chwilę temu przestały uczyć obowiązkowego rosyjskiego, drugim najpopularniejszym językiem był niemiecki. Mało kto miał szczęście trafić na angielski. Przy mojej klawiaturze leżał więc zawsze słownik angielsko-polski a ja raz po raz przekonywałem się, że terminy techniczne niekoniecznie pokrywają się z popularnym znaczeniem wielu słów („file” to przecież pilnik, co nie?).
Jeśli jednak spojrzymy na ośmiobitowce, bariera wejścia nie istniała. Włączałeś komputer – i już! Ćwierć sekundy od pstryknięcia wyłącznika można było wydawać komendy w języku BASIC. Programowanie różniło się jedynie tym, że przed komendą podawaliśmy numer wiersza programu. Sekwencja ponumerowanych komend była wykonywana po wydaniu polecenia RUN.
Jak sama nazwa wskazuje, BASIC był prosty. Łatwo było napisać w nim program działający w trybie tekstowym, złożoność języka była bardzo niska. Wczytywanie danych z klawiatury, obliczenia arytmetyczne, prosta grafika czy muzyka – to wszystko było przystępne nawet dla dziesięciolatka. Wystarczyła jedna książka objaśniająca kolejne słowa kluczowe i zasady konstruowania algorytmów. No ale właśnie, książka.
Dlaczego kiedyś naprawdę było trudniej
Kiedyś problemem był dostęp do wiedzy. Zwykłe biblioteki miejskie nie miały niczego o komputerach. Typowe księgarnie – zazwyczaj jedną półkę książek o losowym poziomie zaawansowania, od publikacji poradnikowych po książki kierowane do studentów kierunków technicznych. Gdy w domach pojawiły się Amigi i pecety, przez chwilę było nawet trudniej – języki C, Pascal, czy Amos były trudniejsze od Basica zaś narzędzia programistyczne dużo bardziej złożone. Nadal jednak głównym problemem było to, skąd czerpać wiedzę.
Księgarnie techniczne istniały tylko w dużych miastach. Głodnemu wiedzy czytelnikowi pozostawały czasopisma – z moim ukochanym Bajtkiem na czele. Czasopisma nie mogły jednak publikować tekstów zbyt hermetycznych, zbyt długich lub podzielonych na zbyt wiele odcinków. Pamiętam dokładnie, jak to było tkwić w tym miejscu – uczę się Pascala z jednej książki, dzięki drugiej umiem włączyć tryb graficzny VGA 13h (320×200, 256 kolorów) i rysować piksele oraz linie, ale mój kod jest za wolny do tworzenia animacji. Asemblera nie rozumiem. Grywam w gry i oglądam efekty, jakie sam chciałbym programować. Nie wiem tylko, jak tego dokonać. Nie znam nikogo, od kogo mógłbym się nauczyć ani nie mam odpowiednich materiałów.
W takiej samej sytuacji było bardzo wielu niedoszłych programistów gier – brak umiejętności tworzenia niskopoziomowego kodu nie pozwalał na realizację autorskich pomysłów na gameplay. To trochę tak, jakbyś chciał zbudować rower z nowatorską konstrukcją kierownicy, ale warunkiem wstępnym było samodzielne wytoczenie łożysk i rafinacja smarów.
Od tamtego czasu minęło 30 lat i wydarzyły się trzy wielkie przełomy.
Stawanie na ramionach gigantów
Przełom pierwszy, druga połowa lat ’90, to nagły dostęp do wiedzy z całego świata. Na początku nie chodziło nawet o internet, tylko o popularyzację napędów CD-ROM i niski koszt tłoczenia płyt. Nagle okazało się, że w świecie istnieją wielkie BBS-y a w nich gotowe kolekcje różnorakich bibliotek programistycznych, np. SWAG zawierająca kilka tysięcy gotowych do użycia fragmentów kodu źródłowego Pascala. Można się z nich było uczyć jak z najlepszej książki. A kolekcje takie zaczęły być legalnie wydawane na płytach CD.
To wtedy umiejętność tworzenia niskopoziomowego kodu przestała być potrzebna. Wystarczyło sięgnąć po bibliotekę FastGraf albo Allegro, by korzystać z gotowej obsługi duszków (sprites), płynnego scrollowania ekranu, podwójnego buforowania, procedur obsługi myszki itp.
Internet też się przydawał, ale pamiętajcie, że nie było wówczas sensownych wyszukiwarek zaś prędkość transferu była bardzo niska (w domu przez modem: kilobajt na sekundę, megabajt w kwadrans). Wędrówki po amerykańskich stronach uwzględnionych w katalogu Yahoo były kosztowne.
Atrakcyjność świetnych bibliotek programistycznych wiązała się też z nowym trendem – w przeciwieństwie do wcześniejszych komercyjnych odpowiedników, były one dystrybuowane na licencjach Open Source, a więc po pierwsze za darmo, po drugie – z kodem źródłowym. To pozwalało nie tylko na poznawanie różnych sztuczek, ale także wzbogacanie bibliotek o samodzielnie przygotowane funkcje.
To zaowocowało pierwszą falą gier typu „indie” czyli niezależnych produkcji bardzo małych zespołów, często jednoosobowych. Warto wspomnieć takie tytuły, jak Liero (1998), Soldat (2002), Cave Story (2004) czy World of Goo (2008). Ten ostatni bazował nie tylko na darmowym silniku graficznym SDL, lecz także otwartej bibliotece Open Dynamics Engine realizującej obliczenia fizyki świata gry.
StackOverflow i zmiana trendów
Przełom drugi nastąpił dekadę później, gdy w roku 2008 powstała witryna StackOverflow. Realizowała bardzo prostą koncepcję – każdy mógł zadać pytanie dotyczące programowania, każdy mógł na nie odpowiedzieć. Ciekawe pytania i trafne odpowiedzi podbijano głosowaniem, co zwiększało ich wagę w wynikach wyszukiwania.
Do interakcji zachęcał przemyślany mechanizm odpowiedzi i komentarzy do odpowiedzi, jak również system rang i odznaczeń przyznawanych aktywnym użytkownikom. Oba te aspekty pomagały szybko identyfikować wartościowe treści.
W odróżnieniu od grup dyskusyjnych, list e-mailowych i forów tematycznych, zespół moderatorów pilnował porządku oraz trzymania się tematu (zasady moderacji, wówczas pomocne, dekadę później przyspieszyły zgon serwisu). Ponieważ StackOverflow był jedyny w swoim rodzaju i korzystali z niego wszyscy, nawet najbardziej hermetyczne pytania z niszowych obszarów miały szansę na wartościową odpowiedź. Dla wielu osób medale i odznaki przyznawane za wyróżnione odpowiedzi stanowiły powód do chluby.
W tak zwanym międzyczasie zmieniały się mody i trendy, miejsce Pascala, Delphi i C++ zajęły Java i .NET, popularność zdobył Python, kompletnie nową platformą stały się smartfony zaś zastosowania webowe pochłonęły całą czasoprzestrzeń. Ten ostatni przypadek jest zresztą ciekawy – przeglądarki internetowe stały się najbezpieczniejszą, po wielokroć izolowaną i sandboxowaną metodą na uruchamianie na swoim komputerze kodu, któremu niekoniecznie gotowi bylibyśmy zaufać.
Nowoczesny frontend zjadł swój ogon kilkukrotnie, złożoność webowych frameworków osiągnęła i przekroczyła granice absurdu, a jednocześnie dekady kompatybilności wstecznej nadal pozwalają pisać HTML i towarzyszący mu Javascript w Notepadzie. Nie sposób jednak nie zauważyć, że specjalizacje sprzed dekady wypączkowały w podspecjalizacje, liczba funkcji, opcji, konfiguracji i pluginów we współczesnych środowiskach programistycznych eksplodowała w kosmos a już sama tylko mnogość możliwych kierunków rozwoju czyni początki dużo trudniejszymi, niż kiedyś.
Na szczęście dwa-trzy lata temu pojawił się…
ChatGPT i vibe-coding
Przełom trzeci czyli nauka programowania z asystą LLM-ów. Musimy tu jednak postawić dość wyraźną granicę – czym innym będzie nauka programowania z asystą czatbota, czym innym tzw. vibe-coding. Ten ostatni model to tworzenie programowania przez LLM, któremu użytkownik dostarcza wyłącznie polecenia i opisy w języku naturalnym. Efekty bywają różne, jednak da się dziś tworzyć programy bez umiejętności programowania.
Użycie czatbotów do pomocy w nauce kodowania jest zmianą, której znaczenia nie można przecenić. Każdy programista każdego dnia zmaga się z dziesiątkami malutkich problemów, które musi pokonać przy użyciu wiedzy, sprytu i wytrwałości. LLM uzupełni wiedzę, podsunie nowe triki i zapobiegnie zbyt szybkiemu wyczerpaniu wytrwałości.
Młodym programistom brakuje intuicji. Nawet, jeśli mają w pobliżu seniora, to prędzej czy później zirytuje go ciągłe przerywanie pracy. Tymczasem LLM odpowie ze stoicką cierpliwością na nieskończoną liczbę pytań. „Jak zrobić cośtam”. „Co oznacza ten komunikat błędu”. „Dlaczego ten kod robi X a nie Y”. „Napisz mi funkcję robiącą Z”. „Jak zoptymalizować ten kod”. „Czy taki pomysł zadziała”. Itd, itp. W programowaniu od zawsze dwoma najtrudniejszymi zagadnieniami było „jak podejść do problemu X” oraz „dlaczego moje podejście nie działa”, przy czym to drugie zawsze zżerało najwięcej czasu, energii i cierpliwości.
Jest jeszcze lepiej! LLM wygeneruje sensowne odpowiedzi na pytania „który sposób jest lepszy” albo „podaj pięć alternatywnych metod zrobienia czegoś”. Taka wiedza nie ma odpowiednika w książkach, zaś wyciągnięcie jej ze Stacka wymagało dużo czasu. Owszem, co jakiś czas LLM coś zmyśli albo zignoruje część istniejącej wiedzy. Ponieważ jednak LLM-ów mamy więcej niż jeden, możemy korzystać z nich równolegle albo kazać drugiemu twórczo skrytykować poradę pierwszego.
Fałszywe przełomy
Od wczesnych lat ‘80 ubiegłego wieku co jakiś czas słyszy się zapowiedzi, że oto ma miejsce rewolucja a zwykli ludzie będą programować na równi z profesjonalistami. Miał na to pozwolić język programowania Smalltalk. Potem Visual Basic for Applications w Excelu, Oracle Forms i Oracle Designer. Potem Frontpage, Lotus Notes, Google AppSheet, Airtable, Make.com i wiele, wiele innych produktów.
Do pewnego stopnia okazało się to prawdą – znaczenie VBA i programowalnych baz danych Microsoft Access była naprawdę duże. Niektóre kategorie narzędzi obiecywały więcej, niż dowoziły – o No Code / Low Code pisałem w artykule „No code, no woman, no cry”. Wielu power-userów daje się uwieść urokom automatyzacji realizowanej przy pomocy N8N czy make.com, by później odkryć, że złożoność zadań możliwych do zrealizowania jest mocno ograniczona.
Podobnie jest zresztą z vibe-codingiem czyli programowaniem (lub „programowaniem”) przy użyciu LLM-ów bez zaglądania do generowanego kodu. Początkowa efektywność takiej metody zachwyca, szybkość generowania kodu pozwala na realizację prywatnych projektów, na które zawsze brakowało czasu. Jest to idealna metoda do eksperymentów czy realizacji narzędzi do użytku wewnętrznego.
Bardzo niewielkie są jednak szanse na udane wdrożenie w ten sposób aplikacji produkcyjnej – vibe-koderzy odkrywają, że dostatecznie szczegółowa specyfikacja przypadków brzegowych nie różni się wiele od… ręcznie napisanego programu realizującego ich obsługę. Jeśli nie zaglądamy do kodu, nie będziemy też wiedzieli, jaki jest poziom bezpieczeństwa danych przetwarzanych przez aplikację modyfikowaną każdym kolejnym promptem.
Jak zacząć programować w 2026
Jeśli chcecie porady, jak w ogóle zacząć naukę programowania, proponuję Javascript osadzony w pojedynczej stronie HTML. Bariera wejścia – bliska zeru, przecież Notatnik i przeglądarkę już masz. Wciskasz klawisz F12 i środowisko programistyczne gotowe. W drugim okienku przeglądarki otwierasz ChataGPT i zaczynasz go promptować. „Napisz mi stronę zawierającą Javascript robiący cośtam”. „Nie, nie tak, trochę inaczej”. „Zrób ładniejsze kolory”. „I dodaj emotikonki”. „I logowanie zdarzeń do konsoli Javascriptu”.
Baza danych? Napisz, do czego ma służyć – LLM podpowie jak ją zaimplementować. Chcesz grafikę 2D? LLM podpowie, którą opcję wybrać. Chcesz grafikę 3D? Tu ja podpowiem: jeśli czerpiesz inspirację z tego artykułu, najpierw opanuj dobrze 2D. Chcesz wydajności? Masz WebAssembly.
Stara mądrość głosi: programowanie to aktywność, która niesie radość i sprawia ból, a w opinii wielu radość przeważa nad bólem. Wydaje mi się, że sentencja straciła sporo ze swej aktualności. Ból jest dziś dużo mniejszy. Owszem, nie zniknie nigdy, ale radości jest więcej i łatwiej ją osiągnąć.
Co dalej?
Nie wiem, czy i kiedy wydarzy się kolejny przełom, w mojej karierze byłby to już czwarty. Dwa pierwsze pozwoliły mi robić świetne rzeczy w towarzystwie niesamowicie uzdolnionych kolegów i koleżanek. Nie wiadomo jeszcze, jak na branżę wpłynie przełom trzeci. Póki co AI bywa wygodną wymówką uzasadniającą np. zwolnienia grupowe, choć wzrost produktywności wynikający z użycia LLM-ów jest trudny do uchwycenia obiektywnymi metrykami. Zawód programisty ewoluuje, ale wciąż wymaga ciągłej nauki – i to nie zmieni się nigdy.
O autorze: zawodowy programista od 2003 roku, pasjonat bezpieczeństwa informatycznego. Rozwijał systemy finansowe dla NBP, tworzył i weryfikował zabezpieczenia bankowych aplikacji mobilnych, brał udział w pracach nad grą Angry Birds i wyszukiwarką internetową Microsoft Bing.











4 odpowiedzi na “28 lat mojej gry Rubik”
Tez zaczynalem w tych czasach. Najpierw Amiga 1200 (na niej trochę pascala) potem Dos, Turbo Pascal, C/C++, trochę asemblera.
Pamietam czasy kiedy cała wiedza była z książek (po które trzeba było jechać do księgarni w mieście wojewódzkim).
Ale mam wrażenie że pod pewnymi względami programować było łatwiej.
Komputer pod DOS był jedno-aplikacyjny. Pod windows w sumie też jak się miało słaby komputer.
Jak się odpaliło to IDE to nie można było robić nic innego. Nie było internetu, komunikatorów, video online, portali społecznościowych. Co najwyżej muzykę z audioCD (potem z mp3) można było sobie puścić.
Na Archiwe są tylko iso CD/DVD, czy też PDFy samych gazet?
Gazety też są!
„Pamiętam dokładnie, jak to było tkwić w tym miejscu – uczę się Pascala z jednej książki, dzięki drugiej umiem włączyć tryb graficzny VGA 13h (320×200, 256 kolorów)”
Byłem tam, Gandalfie, 3000 lat temu.
Książka nr 1 – „Pascal nie tylko dla orłów”, Adam Majczak, wyd. 1996
Książka nr 2 – „Kompendium Wiedzy 2” Secret Service, a w niej rozdział „Jak napisać własną grę” autorstwa samego Adriana Chmielarza – stamtąd „pożyczyłem” wstawki assemblerowe do moich podstawówkowych i licealnych gierek :).
Czy którąś z nich miałeś może na myśli (mocno podejrzewam drugą)? 🙂
Reszta historii też brzmi znajomo, w czasach podstawówki miałem jednego (starszego) kolegę, który umiał programować i którego dziś w sumie postrzegam jako pierwszego mentora. Wyjaśnił mi na przykład, że dodawanie jest szybsze od mnożenia i żeby adres w pamięci, rysując sprite, obliczyć ze współrzędnych piksela dodawaniem, a nie mnożeniem. Później – odkrycie SWAGów (nie pamiętam już, jakim kanałem). Albo oglądanie zepsutego samolotu w Transport Tycoon Deluxe i w pewnym momencie olśnienie: ja rozumiem jak oni ten „ciągnący się” dym zrobili! Zrobię tak samo! (Tak, dla dzieciaka w podstawówce to naprawdę była eureka :D)
Dzięki za ten artykuł, na przykładzie Twojej drogi pozwala sobie uświadomić/przypomnieć jak wyboistą drogę przeszedł każdy z nas, zaczynających w tamtych czasach. Co jakiś czas biję się z myślą o odkopaniu swoich starych gierek i doprowadzeniu ich do działania we Free Pascalu (źródła mam, ale więcej tu początkowego szczęścia niż przemyślanej polityki backupów, ta przyszła dużo później). Świat jednak chyba nie jest gotowy na moje ówczesne wypociny 😀