Dlaczego gry lat 90. wyglądają i „czują się” inaczej niż dzisiejsze
Epoka przejściowa: od Amigi i DOS‑a do Windows i 3D
Lata 90. to okres, w którym gry PC przeszły drogę od prostych, dwuwymiarowych produkcji do pełnego 3D. Większość dekady zdominował DOS, dopiero druga połowa to rosnąca rola Windows 95 i pierwszych wersji DirectX. Do tego dochodziły komputery Amiga, które w Polsce i Europie mocno wpływały na wyobraźnię twórców – wielu z nich zaczynało właśnie od demosceny amigowej, a potem przenosiło doświadczenia na PC.
Standardowy schemat wyglądał tak: początek dekady to klasyczne 2D i gry kafelkowe, środek to „2.5D” – czyli wszelkie Doomopodobne silniki, gdzie świat był niby trójwymiarowy, ale technicznie mocno uproszczony, a końcówka to już prawdziwe 3D z wykorzystaniem akceleratorów graficznych. Ta ewolucja nie była jednak łagodna – każdy etap wymuszał zupełnie inny sposób myślenia o projektowaniu poziomów, sterowaniu, animacji czy nawet scenariuszu.
Gracze często wspominają gry lat 90. jako bardziej „surowe”, ale zarazem spójniejsze. Wynikało to z tego, że całość – mechanika, grafika, muzyka – była projektowana pod bardzo konkretne ramy techniczne. Dziś gra ma skalować się od laptopa po konsole nowej generacji, wtedy liczył się np. „PC z 486DX2 i kartą VGA”. To poczucie „innego klimatu” często nie jest efektem nostalgii, tylko bezpośrednim skutkiem sztywnych ograniczeń sprzętowych i systemowych.
Sprzęt dyktował projekt: 386, 486, pierwsze Pentium i Voodoo
Typowy gracz z pierwszej połowy dekady korzystał z 386 lub 486 z 4–8 MB RAM, kartą VGA 256 kolorów i głośniczkiem PC Speaker lub Sound Blasterem, jeśli miał szczęście. Twórcy gier programowali często na nieco mocniejszych konfiguracjach, ale musieli zakładać, że gra zadziała na dużo słabszym sprzęcie. Oznaczało to twarde decyzje:
- liczba wrogów na ekranie – nie tyle decyzja designu, ile limit wydajności CPU,
- rozdzielczość 320×200 zamiast 640×480 – bo pamięć wideo i przepustowość magistrali,
- prostsze animacje, mniej klatek, skrócone cut‑scenki – bo zabrakłoby miejsca na dyskietce.
Przełomem były pierwsze karty Voodoo 3Dfx. Umożliwiły wreszcie sensowne teksturowanie i płynne 3D w wyższych rozdzielczościach. Z perspektywy projektowej oznaczało to jednak konieczność podzielenia gry na dwa światy: „software rendering” dla mas i „3Dfx” dla entuzjastów. W praktyce wiele zespołów musiało utrzymywać dwie ścieżki rozwoju renderera, co przy małych kadrach było poważnym obciążeniem.
Od gier pisanych „pod konkretny PC” do współczesnych multiplatform
Dzisiaj standardem jest projektowanie z myślą o wielu platformach i gotowych silnikach. W latach 90. była odwrotna logika: gra była pisana „pod” konkretną konfigurację i system. Nie chodziło tylko o kompatybilność, ale o wykorzystanie każdego cyklu procesora i każdego kilobajta pamięci. Programista pisał kod tak, by idealnie wpasował się w to, co oferował sprzęt. Ta bliskość z „metalem” sprawiała, że nawet drobne zmiany w specyfikacji gracza mocno wpływały na wrażenia – stąd np. kultowe „Doom chodził płynnie dopiero na 486DX2”.
Współczesne rady typu „użyj gotowego silnika i nie przejmuj się niskopoziomowymi detalami” miałyby wtedy ograniczoną wartość. Ogólny silnik często byłby zwyczajnie za ciężki dla maszyny docelowej, a dodatkowa abstrakcja odbierała kontrolę nad optymalizacją. Twórcy pisali więc własne „mini‑silniki” skrojone do jednego tytułu, maksymalnie dopasowane do planowanego hardware’u.
Kultura twórców: od „garażowców” do rosnących studiów
Wielu kultowych twórców gier lat 90. nie miało formalnego wykształcenia z „game designu”, bo taki kierunek po prostu nie istniał. Programiści uczyli się z książek, magazynów, przykładowych listingów i z własnych porażek. Graficy często byli samoukami, którzy wcześniej tworzyli pixel art do demoscenowych produkcji. Muzycy – scenowi „trackerzy”, którzy przeszli z Amigi na PC.
Małe studia przypominały raczej start‑upy bez inwestorów i bez struktur. Procesy były chaotyczne: minimalna dokumentacja, decyzje zapisywane w notatnikach lub po prostu w głowach kluczowych osób, ciągłe zmiany koncepcji w trakcie produkcji. Ten chaos bywał destrukcyjny (projekty się rozjeżdżały, terminy przepadały), ale z drugiej strony dawał sporą swobodę eksperymentowania. Dzisiaj podobną elastyczność mają raczej mikro‑studia indie niż duże firmy.
Mity „złotej ery” kontra rzeczywistość produkcji
Popularny obraz lat 90. mówi o „złotej erze, kiedy liczyła się kreatywność, a nie budżety”. To tylko część prawdy. Owszem, wiele pomysłów można było przepchnąć w małym zespole, ale każdy pomysł musiał przejść przez bardzo ciasną bramkę ograniczeń technicznych. Zbyt ambitna mechanika potrafiła zabić projekt, bo nie dało się jej zrealizować na docelowym sprzęcie.
W praktyce „wolność” często kończyła się tym, że wizja była obcinana miesiąc po miesiącu. Długi render filmiku? Nie, bo nie zmieści się na płytach lub transfer jest zbyt wolny. Wielkie otwarte lokacje? Nie, bo przekraczały pamięć konwencjonalną. System skomplikowanej fizyki? Nierealny przy wydajności 486. Dlatego w latach 90. często zwyciężały pomysły sprytne, ale wykonalne, a nie te najbardziej szalone.
Ciekawy kontrast: dziś ograniczeniem najczęściej jest budżet i czas. W latach 90. barierą bywała przede wszystkim czysta fizyka sprzętu i systemu operacyjnego. Bez akceptacji tych granic nawet najbardziej utalentowany zespół zatrzymywał się w połowie drogi.
Sprzęt i technologia: jak wyglądało środowisko pracy twórcy w latach 90.
Co realnie miał na biurku twórca gry PC
Standardowy komputer developera w połowie lat 90. nie był luksusową stacją roboczą rodem z dzisiejszych materiałów marketingowych. To był często PC klasy 486 lub pierwsze Pentium z 8–16 MB RAM, dyskiem 170–540 MB, kartą VGA/SVGA i Sound Blasterem 16. Dopiero pod koniec dekady bardziej zamożne studia mogły sobie pozwolić na kilka naprawdę mocnych maszyn, np. Pentium II z 64 MB RAM.
Z dzisiejszej perspektywy najbardziej uderzają dyski. Kilkaset megabajtów na cały projekt, narzędzia, system operacyjny i inne pliki. Dziś pojedynczy folder „build” gry potrafi zajmować dziesiątki gigabajtów. W latach 90. sam fakt dodania kilku minut nagranych dialogów czy wyższej jakości tekstur stanowił strategiczną decyzję produkcyjną, a nie jedynie punkt na liście „do dorzucenia, jeśli będzie czas”.
Drugim kluczowym elementem były karty dźwiękowe i graficzne. Zwykły PC Speaker oferował podstawowe „bipnięcia”, Sound Blaster i AdLib – syntetyczne dźwięki FM i prosty odtwarzacz sampli. Po stronie grafiki, standard VGA (320×200, 256 kolorów) był w praktyce ramą projektową. Dodanie trybów SVGA (640×480 i wyżej) wymagało więcej pamięci i CPU, więc nie każdy tytuł mógł sobie na to pozwolić.
Standardy: VGA, SVGA, Sound Blaster, pierwsze akceleratory 3D
Brak jednolitych standardów oznaczał dla twórców kolejne problemy. Gry musiały wykrywać, jaki sprzęt ma gracz, i odpowiednio się do niego dostosować. Powszechne były zewnętrzne konfiguratory, w których wybierało się:
- typ karty dźwiękowej (Sound Blaster, AdLib, Gravis Ultrasound, inne),
- adresy I/O i przerwania (IRQ),
- tryb video (VGA, konkretne odmiany SVGA, czasem osobne sterowniki VESA).
Dla studia oznaczało to setki dodatkowych testów oraz niekończące się zgłoszenia błędów od graczy, którym „gra nie widzi karty dźwiękowej”. Jednocześnie brak jednego, wysoko poziomowego API do grafiki (jak dzisiejsze DirectX czy Vulkan) zmuszał programistów do bezpośredniego grzebania w pamięci video, co dawało ogromną kontrolę, ale zwiększało koszty utrzymania kodu i krzywą wejścia.
Gdy pojawiły się pierwsze akceleratory 3D, doszła kolejna matryca decyzji: wspierać je czy nie? Część gier wypuszczała osobne, dedykowane wersje z obsługą np. 3Dfx (słynne dopiski „Glide” lub „3Dfx patch”), inne dodawały opcjonalny tryb. Powstała więc dodatkowa warstwa testów, a małe studia musiały balansować między byciem „na czasie” a realnymi możliwościami zespołu.
Praca bez internetu, Stack Overflow i GitHuba
Dzisiejszy twórca gry ma dostęp do dokumentacji online, forów, Stack Overflow, tutoriali wideo, repozytoriów na GitHubie i gotowych bibliotek do praktycznie każdego problemu. W latach 90. support wyglądał następująco:
- książki o programowaniu (często w języku angielskim, trudno dostępne),
- magazyny komputerowe z listingami i krótkimi artykułami,
- dyskietki lub płyty CD z przykładowym kodem,
- lokalne grupy userów, demoscena, kontakty „po znajomości”.
Internet istniał, ale był powolny, drogi i często ograniczony do uczelni lub firm. Dostęp do zagranicznych grup dyskusyjnych nierzadko oznaczał ściąganie treści godzinami przez modem. W praktyce wielu twórców było zmuszonych do samodzielnego odkrywania rozwiązań, które komuś innemu dawno już udało się opisać, ale informacja po prostu do nich nie docierała.
Brak systemów kontroli wersji w dzisiejszym rozumieniu (Git, SVN) powodował, że projekty wersjonowano ręcznie: katalogi z datami, kopiowanie całego projektu na inny dysk, trzymanie „backupów” na taśmach lub płytach. Z perspektywy 2020+ może to wyglądać archaicznie, ale to w takim środowisku powstawały gry, które dziś uznaje się za kultowe.
Cykl tworzenia: dyskietki, nocne kompilacje i debugowanie „na żywo”
Przesyłanie danych w zespole często odbywało się… na dyskietkach. Wspólne serwery plików były luksusem większych firm. Jeśli grafik pracował w innym mieście, wysyłał pliki pocztą lub przywoził na weekend pendrive’ów wtedy jeszcze nie było. To oznaczało długie opóźnienia między powstaniem assetu a jego włączeniem do gry.
Kompilacje dużych projektów trwały długo, nawet kilkadziesiąt minut. Dlatego wiele zespołów przyjęło strategię „nocnych buildów”: developer uruchamiał pełną kompilację przed wyjściem z biura, a rano sprawdzał, czy się powiodła. Błędy wykrywane po wielu godzinach wymuszały ostrożność wprowadzania zmian – stąd nacisk na przemyślane, spójne modyfikacje zamiast dzisiejszego „spróbujmy, najwyżej zrobimy rollback z Gita”.
Debugowanie często odbywało się „na żywo” w samej grze. Programiści wstawiali do kodu ukryte skróty (cheaty), które pozwalały skakać po poziomach, włączać tryb „noclip”, logować informacje na ekranie. Było to na tyle praktyczne, że wiele takich narzędzi trafiało niechcący do wersji finalnej i stawało się legendarnymi kodami dla graczy.
Gdy brakowało 2 MB RAM: decyzje, które zmieniały gry
Są opowieści z tamtych czasów, w których całe mechaniki lub rozdziały gry wyleciały z projektu z powodu… braku dodatkowych 2 MB RAM u przeciętnego gracza. Decyzje typu „celujemy w 8 MB RAM czy 16 MB RAM” były kluczowe dla rynku. Zbyt wysokie wymagania – mniejsza sprzedaż. Zbyt niskie – konieczność kompromisów. Programiści potrafili liczyć pamięć niemal co do bajta, planując, ile miejsca będzie zajmować mapa, ile przeciwnicy, a ile efekty dźwiękowe.
Dzisiaj powszechna rada brzmi: „optymalizuj na końcu, gdy gra działa”. W latach 90. optymalizacja była częścią projektowania od pierwszego dnia. Jeśli już na starcie błędnie oszacowano użycie pamięci, po kilku miesiącach produkcji odkrywano, że gra nie działa na sprzęcie docelowym i jedyną opcją było cięcie zawartości. Nie było też łatwej ścieżki patchowania: wielu graczy nie miało internetu, więc wersja pudełkowa musiała być maksymalnie stabilna i dopracowana.
Dlatego tak istotne jest, aby analizując stare gry, pamiętać: część dziwnych decyzji projektowych nie wynikała z braku wyobraźni, ale z twardych limitów sprzętowych, o których dzisiaj mało kto myśli.
Języki, narzędzia i silniki: od assemblera do pierwszych „game engine’ów”
Assembler jako codzienność, nie egzotyka
Współcześnie porada „zostaw optymalizację kompilatorowi” jest rozsądna. W latach 90. często kończyła się katastrofą. Kompilatory C były dużo słabsze, a procesor musiał wykonywać mniej instrukcji, inaczej gra zwalniała do kilku klatek na sekundę. Dlatego kluczowe fragmenty kodu – pętla renderująca, obsługa kolizji, dekodowanie dźwięku – pisano ręcznie w assemblerze.
Typowy workflow wyglądał tak: logika gry w C, krytyczne ścieżki w asemblerowych modułach .ASM włączanych do projektu. Programista musiał znać architekturę x86 na poziomie rejestrów, trybów adresowania i cykli zegara, bo każda dodatkowa instrukcja naprawdę bolała. Nawet prosty wybór: „czytać z pamięci czy trzymać w rejestrze?” – przekładał się na płynność animacji na 486DX2.
Paradoksalnie, ta bliskość metalu wpływała też na projektowanie gry. Jeśli widać, ile kosztuje każde obliczenie, inaczej myśli się o „fajnych bajerach” w gameplayu. Dodanie skomplikowanej trajektorii pocisków oznaczało nie tylko nową funkcję, ale policzenie, czy starczy mocy CPU, gdy na ekranie będzie kilkunastu przeciwników.
Jeśli chcesz pogłębić temat i zobaczyć więcej przykładów z tej niszy, zajrzyj na więcej o gry komputerowe.
C i C++: wygoda z domieszką ryzyka
Wyższe języki nie były nieznane – C i C++ były podstawą większych produkcji PC. Różnica w porównaniu z dzisiejszym C++? Brak rozbudowanych bibliotek standardowych, brak gotowych frameworków, słabsze debugery, a wiele rzeczy (np. obsługa łańcuchów, struktur danych) tworzono w studiu od zera.
Tu pojawia się pierwsza „popularna rada”, która wtedy łatwo prowadziła w ślepą uliczkę: „projektuj silnie obiektowo, wszystko w klasy”. Ambitne zespoły próbowały przenosić podręcznikowe wzorce projektowe 1:1 do gier. Szybko wychodziło na jaw, że zbyt rozbudowane hierarchie klas generują narzut, robią się trudne do debugowania i wpadają w spiralę zależności. Przy słabych kompilatorach C++ i ograniczonej mocy CPU „czystość” architektoniczna bywała luksusem, na który nie każdy mógł sobie pozwolić.
Alternatywą był hybrydowy styl: prosty, proceduralny kod C jako „szkielet”, a C++ tylko tam, gdzie realnie pomaga – np. do zarządzania zasobami czy tworzenia modularnych systemów broni. Ten kompromis często wygrywał z pełnym OOP, bo dawał kontrolę nad wydajnością, a jednocześnie ułatwiał rozwój projektu.
Własne narzędzia zamiast gotowego edytora
Dziś standardem jest: „użyj Unity/Unreal, nie buduj silnika”. W latach 90. ta rada w ogóle nie miała zastosowania. Komercyjnych, uniwersalnych silników było bardzo mało, a ich licencjonowanie było drogie i formalnie skomplikowane. Dlatego niemal każde studio tworzyło własne narzędzia – często bardzo surowe, ale idealnie dopasowane do konkretnej gry.
Edytory poziomów potrafiły być prostymi aplikacjami w DOS-owym trybie tekstowym, gdzie projektant wpisywał współrzędne ręcznie lub przesuwał znaczniki strzałkami. Bardziej „luksusowe” narzędzia działały pod Windows 3.1 lub 95, ale i tak miały daleko do dzisiejszych, wizualnych edytorów z podglądem na żywo. Export do gry oznaczał zazwyczaj konwersję do wewnętrznego formatu binarnego, a każdy błąd w danych mógł zawiesić całą aplikację.
To prowadziło do zjawiska, które dziś rzadko się widzi: silnik i narzędzia rosły razem z grą. Nie istniał „gotowy foundation layer”, który po prostu się podłączało. Zespół musiał wybierać: czy teraz rozwijamy edytor (żeby szybciej tworzyć poziomy), czy dokładamy nową funkcję do samej gry? Zbyt ambitne rozbudowy narzędzi mogły zatrzymać produkcję na tygodnie, więc każdy przycisk w edytorze był skutkiem dyskusji, a nie „zróbmy wszystko, bo może się przyda”.
Pierwsze silniki 3D: między technologicznym popisem a praktyką
Na końcówkę dekady przypada wysyp pierwszych rozpoznawalnych silników: Quake Engine, Unreal Engine, różne wewnętrzne rozwiązania inspirowane id Software. W teorii kusząca była rada: „kup licencję, skup się na kontencie”. W praktyce licencje były kosztowne, wymagały kontaktów i negocjacji, a integrowanie cudzego kodu wcale nie było łatwe.
Silniki tworzone przez „demoscenowych” programistów potrafiły wyglądać spektakularnie na prezentacjach – dynamiczne światła, korytarze 3D, skomplikowane efekty. Problem pojawiał się, gdy trzeba było na nich zbudować grę z AI, skryptami, systemem sejwów i narzędziami dla grafików. To, co było genialnym popisem umiejętności technicznych, niekoniecznie było wygodną bazą produkcyjną.
Przez to w wielu studiach stosowano podejście kontrariańskie wobec mody: zamiast gonić za pełnym 3D, inwestowano w dopracowany pseudo-3D (np. „2.5D”, sprite’y w środowisku 3D) lub rozsądnie rozbudowane 2D. Dzięki temu projekt był do udźwignięcia przez zespół i sprzęt graczy, a czas produkcji nie rozjeżdżał się w nieskończoność.
Gra jako wynik walki z ograniczeniami: grafika, dźwięk, pamięć
Grafika: kiedy każdy piksel był decyzją
W epoce VGA 320x200x256 kolorów piksel nie był „surowcem darmowym”. Artyści myśleli w kategoriach siatki 8×8 lub 16×16, bo w takich blokach działały kafelki i sprite’y. Animacje projektowano, mając w głowie surowe liczby: ile klatek można sobie pozwolić na jednego wroga, ile obiektów naraz zmieści się w pamięci video.
Do tego dochodziła paleta. Gry często korzystały z jednej globalnej palety 256 kolorów, współdzielonej przez tła, postacie, interfejs. Dodanie jednego nowego odcienia niebieskiego mogło oznaczać konieczność usunięcia innego koloru używanego w UI. Dlatego tworzono „palety tematyczne” – zestawy kolorów zoptymalizowane pod konkretne klimaty: nocne misje, pustynie, wnętrza baz. Artyści nauczyli się wyciskać maksimum z ditheringu i sprytnego cieniowania, żeby symulować większą liczbę barw.
Styl graficzny często wynikał więc z matematyki, a nie tylko estetyki. Ograniczona rozdzielczość wymuszała czytelne, proste kształty, mocny kontrast i charakterystyczne silne kontury. To nie była tylko moda „pixel artu” – to był warunek, żeby postać była rozpoznawalna na ekranie 14-calowego monitora przy 320×200.
Dźwięk: od „bipnięć” do małych orkiestr
Po stronie audio walka szła na dwóch frontach: formaty i kanały. Muzyka MIDI była lekka i elastyczna, ale brzmiała różnie w zależności od karty dźwiękowej gracza. Sampli (WAV) można było użyć oszczędnie, bo zajmowały mnóstwo miejsca na dysku i w pamięci. Każde „przycięcie” długości dźwięku czy obniżenie częstotliwości próbkowania było realną oszczędnością.
Kluczowe pytanie brzmiało: „ile kanałów audio utrzymamy, zanim CPU padnie?”. Próba stworzenia gęstej, filmowej ścieżki dźwiękowej kończyła się chrupaniem i spadkami płynności na słabszych maszynach. Dlatego wiele gier stawiało na dobrze zaprojektowane motywy melodyczne w MIDI (lekkie, ale nośne) i zestaw krótkich sampli efektów, powtarzanych w przemyślany sposób.
W tym miejscu przyda się jeszcze jeden praktyczny punkt odniesienia: Najlepsze mody do klasycznego Quake’a.
Ciekawy paradoks: im bardziej ograniczone możliwości, tym większa dbałość o kompozycję. Kompozytor nie mógł „zalać” sceny orkiestrą i liczyć, że się obroni klimatem. Motyw musiał być natychmiast rozpoznawalny, nośny i działać na słabym brzmieniowo sprzęcie.
Pamięć: projektowanie mechanik zamiast „doklejania funkcji”
Większość graczy kojarzy ograniczenia pamięci z teksturami czy długością poziomów. Bardziej bolesne były jednak koszty logiki gry: AI, skrypty, stany obiektów. Rozbudowany system interakcji wymagał przechowywania dodatkowych danych – flag, timerów, zmiennych. Każdy „int” i każdy wskaźnik się liczył.
Tu obnażała się rada „dodajmy system X, skoro mamy już Y”. W latach 90. takie „dorzucanie” mechanik łatwo rozwalało budżet pamięci. Złożony ekwipunek z unikatowymi właściwościami przedmiotów? Oznacza dodatkowe struktury danych i logikę aktualizującą je w czasie rzeczywistym. Zaawansowana fizyka pocisków? To nowe pola w obiektach, które trzeba wczytać, śledzić i zapisać w sejwie.
Zamiast tego część zespołów wybierała mechaniki, które tworzą złożoność z prostych zasad: kilka typów przeciwników, ale dobrze zaprojektowane zachowania; skromny ekwipunek, lecz z realnymi konsekwencjami każdej decyzji. Taka „oszczędność mechaniczna” nie wynikała z lenistwa, tylko z liczenia bajtów i cykli procesora.
Streaming danych i sztuka ładowania w tle
Przy bardzo ograniczonej pamięci RAM pojawił się inny problem: jak w ogóle zmieścić duże poziomy? Część gier stosowała podział na mniejsze sekcje i klasyczne ekrany ładowania. Bardziej ambitne tytuły próbowały streamingu – doczytywania części danych z dysku w tle.
To nie był jednak „open world” w dzisiejszym sensie. Streaming danych w DOS-ie czy wczesnym Windows wymagał ręcznego kontrolowania buforów, przewidywania, gdzie pójdzie gracz, i ukrywania doczytywania za drzwiami, windami, długimi korytarzami. Jeśli projektant przesadził z „nieliniowością” poziomu, silnik nie był w stanie nadążyć z doczytywaniem tekstur i geometrii.
Konsekwencją były charakterystyczne „blokady” w projekcie poziomów – wąskie gardła, które wymuszały określoną trasę, choć na pierwszy rzut oka wszystko wyglądało swobodnie. Niejeden „genialny trik level designu” był tak naprawdę plasterkiem na rany po archaicznym dysku twardym.
Organizacja pracy: małe zespoły, role łączone i chaotyczne procesy
Zespół pięć osób kontra dzisiejsze setki
W latach 90. pełnoprawną grę PC potrafił stworzyć zespół, który dzisiaj mógłby uchodzić za pół działu QA. Programista-szef projektu, grafik 2D/3D, ktoś od audio, czasem dedykowany projektant – i już. Często role mieszano: grafik robił też UI i animacje, programista pisał edytor, narzędzia konwersji danych, a przy okazji system sejwów i skrypty.
Z jednej strony było to błogosławieństwem: mało osób, krótkie ścieżki decyzyjne, spójna wizja. Z drugiej – rygor procesowy praktycznie nie istniał. Gdy kluczowa osoba się rozchorowała albo odchodziła z zespołu, całe obszary wiedzy znikały z dnia na dzień. Dokumentacja bywała szczątkowa, bo „wszyscy i tak wiedzą, jak to działa”.
Brak formalnego designu i dokumentacji – plus czy minus?
Popularna dzisiaj rada „pisz obszerne GDD, wszystko dokumentuj” w realiach lat 90. była w dużej mierze niewykonalna. Czas spędzony na dopieszczaniu dokumentu oznaczał godziny, których brakowało na pisanie kodu czy rysowanie grafiki. Zmiany wymuszane przez hardware (np. obcięcie pamięci docelowej) i tak wywracały projekt do góry nogami co kilka miesięcy.
Wiele zespołów stosowało więc „living design”: luźne notatki, szkice na kartkach, krótkie listy zadań na tablicy lub w pliku tekstowym. Projektant był raczej „nosicielem wizji” niż autorem encyklopedii o grze. Decyzje zapadały w rozmowach przy biurku, a nie w formalnych review.
To nie znaczy, że pełna dokumentacja nie ma sensu. Przy większych, wieloletnich projektach mogłaby uratować mnóstwo nerwów. Problem w tym, że zespoły zwyczajnie nie miały zasobów, by ją prowadzić, a tempo zmian technologii czyniło wiele zapisów nieaktualnymi po kilku miesiącach. Lepiej sprawdzało się krótkie, aktualizowane na bieżąco „minimum opisowe” niż gruby, martwy GDD.
Chaotyczne procesy produkcyjne i „zarządzanie kryzysem”
Metodyki zwinne, sprinty, stand-upy – to wszystko przyszło później. Produkcję gier w latach 90. można było często opisać jednym słowem: improwizacja. Terminy wyznaczał wydawca („musi być na święta”), a zespół próbował dowieźć cokolwiek działającego w tym oknie czasowym.
Popularna strategia „zróbmy MVP, potem iterujmy” miała mało sensu w świecie pudełkowych wydań. Nie dało się szybko wypuścić patcha czy łatki balansującej. Stąd obsesja na punkcie „feature complete” przed wejściem w finalne testy: gdy gra szła do tłoczni, praktycznie nie było już odwrotu. Wydawca rzadko zgadzał się na przesuwanie premiery, bo oznaczało to utratę okna sprzedażowego i miejsca na półce sklepowej.
Debugowanie bez luksusów i „magia” niskiego poziomu
Kto dziś zaczyna od podłączania debuggera do gołego sprzętu, ten prawdopodobnie robi oprogramowanie dla satelitów albo urządzeń medycznych. Twórcy gier PC lat 90. byli bliżej tego świata niż współczesnych silników AAA. Źródłem prawdziwego stresu nie były błędy logiczne w stylu „tu jest + zamiast -”, ale awarie w stylu: „czasem po 23 minutach gry ekran robi się czarny, dźwięk zawiesza się na ostatniej próbce, a komputer wymaga twardego resetu”.
Przyczyna? Nadpisana pamięć, niezwolniony zasób, konflikt z TSR-em albo sterownikiem karty dźwiękowej. Debuggery istniały, ale ich używanie na pełnoekranowej grze DOS-owej nie było tak proste jak odpalanie narzędzia w Visual Studio. Często posługiwano się domową telemetrią: zapisywaniem logów do pliku tekstowego, wyświetlaniem ukrytych overlayów z licznikami FPS, użyciem specjalnych „kodów debugowych” wywołujących małe panele diagnostyczne.
Stąd popularne wtedy „tryby magiczne” – kombinacje klawiszy, które pokazywały dodatkowe informacje: współrzędne gracza, listę aktywnych obiektów, wykorzystanie pamięci. Niby narzędzie dla twórców, ale czasem zostawało w wersji finalnej i po latach fani odkrywali „ukryte menu debugowe”. To nie był easter egg planowany dla graczy, tylko pozostałość po chaotycznym procesie testowania.
Testowanie bez automatyzacji i rola wydawcy jako „filtra jakości”
Automatyczne testy, continuous integration, telemetryczne raporty z zachowania tysiąca graczy – to luksusy późniejszej epoki. W latach 90. jakość gry opierała się na mieszaninie manualnych testów, intuicji zespołu i oczach wydawcy. Ten ostatni często pełnił rolę nie tylko finansującego, ale także quasi-działu QA.
Duży wydawca miał własnych testerów, którzy „męczyli” build w typowy sposób: przejście wszystkich misji, próby rozbijania się o ściany, sprawdzanie, czy gra wstaje na kilku popularnych konfiguracjach sprzętowych. Nie istniała jednak gęsta sieć telemetryczna, która dziś rejestruje każdy crash. Jeżeli tester nie trafił na błąd – istniała spora szansa, że gra wyjdzie z nim na rynek.
Konsekwencją było inne podejście do ryzyka technicznego. Dziś popularna rada „wprowadzajmy śmiałe innowacje, najwyżej załatamy po premierze” brzmi rozsądnie w kontekście cyfrowej dystrybucji. W latach 90. była przepisem na katastrofę – krytyczny bug w pudełkowej wersji mógł pogrzebać reputację studia na lata, bo patcha wielu graczy po prostu nigdy nie zainstalowało. Alternatywną strategią było ograniczanie innowacji technicznych do obszarów, które dało się przetestować ręcznie w skończonym czasie, a eksperymenty mechaniczne prowadzić tam, gdzie awaria nie zabijała całej sesji (np. w pojedynczych misjach, nie w systemach zapisów).
Relacja z wydawcą: między partnerstwem a dyktatem
Fizyczna dystrybucja, marketing w prasie i w sklepach oraz produkcja pudełek wymagały kapitału. Dlatego większość zespołów była uzależniona od wydawcy w znacznie większym stopniu niż dzisiejsze niezależne studia publikujące na platformach cyfrowych. Wydawca dostarczał nie tylko pieniądze, ale i „projektowe założenia rynkowe”: ile godzin rozgrywki, jaki poziom trudności, jakie platformy docelowe.
Do kompletu polecam jeszcze: Pamiętasz Quake’a z okładki CD-Action? — znajdziesz tam dodatkowe wskazówki.
Część porad, które dziś powtarza się zespołom indie – „słuchajcie tylko własnej wizji, nie ulegajcie presji rynku” – w realiach tamtej dekady często kończyła się brakiem finansowania. Alternatywą była twarda gra negocjacyjna: zgoda na kilka „komercyjnych” wymagań (łatwiejszy poziom normal, samouczek, tryb multiplayer), w zamian za wolną rękę w obszarach kluczowych dla tożsamości gry. Niektórzy twórcy wykorzystywali przewagę technologii: jeśli tylko ich zespół potrafił wycisnąć z VGA czy Sound Blastera coś, czego konkurencja nie umiała, wydawca był bardziej skłonny odpuścić ingerencje w design.
Kultura „crunchu” i realia pracy nad deadlinem pudełkowym
Cykl pudełkowy oznaczał nieprzesuwalne terminy: slot w drukarni, okno sprzedażowe, umowy z dystrybutorami. Gdy projekt się opóźniał, nie ratowano się cięciem scope’u po premierze, tylko nadgodzinami przed nią. Crunch nie był wtedy formalnie nazwanym zjawiskiem – po prostu normą w branży.
Popularne dziś hasło „planuj od razu bez crunchu” ma sens, gdy proces jest stabilny, a silnik i platformy są dobrze znane. W latach 90. zbyt ambitny plan techniczny praktycznie gwarantował serię niespodzianek: konflikt sterowników, nieprzewidziane zachowanie konkretnej karty graficznej, zmiany w systemie operacyjnym. Bez buforów czasowych i bez aktualizacji scope’u trudno było uniknąć ostatnich tygodni spędzanych w biurze po nocach. Kontrariańska reakcja części studiów polegała nie na udawaniu, że crunchu nie będzie, tylko na świadomym budowaniu go jako wymiennego zasobu: „tu tniemy zakres, żeby ten etap zamknąć bez weekendów, a tu celowo trzymamy rezerwę ludzi na ostatnią prostą”.
Dystrybucja i kontakt z graczem: od dyskietek do pierwszych łat
Dyskietki, CD i kompromisy projektowe wynikające z nośnika
Nośnik fizyczny nie był neutralnym elementem. Gra na kilku dyskietkach wymuszała spiralę kompromisów: krótsze nagrania audio, mniej grafik przerywnikowych, agresywną kompresję. Przesiadka na CD otwierała nowe możliwości – pełne ścieżki audio, filmowe cutscenki, bogatsze tła – ale jednocześnie dokładała kolejne problemy techniczne: wolny napęd, opóźnienia przy odczycie, głośne „mielenie” podczas dogrywania danych.
Dlatego część zespołów świadomie zostawała przy „uboższych” rozwiązaniach nawet wtedy, gdy płyty były już standardem. Rozbudowane wideo FMV brzmiało świetnie w prezentacji dla wydawcy, ale realnie zabierało czas na dopieszczanie rdzenia gry. Alternatywą było wykorzystanie CD głównie jako nośnika kompresowanych danych gameplayowych i wysokiej jakości muzyki audio, zamiast pakowania na siłę filmów, które szybko się starzały.
Patch na płycie w czasopiśmie i kultura „gold mastera”
Gdy gra trafiła do tłoczni, powstawał tzw. gold master – wersja, która szła w tysiące egzemplarzy. Błąd w tej wersji oznaczał realne straty: zwroty, niezadowolenie graczy, złą prasę. Czasem wydawcy decydowali się na wypuszczenie patcha, ale dystrybucja wyglądała inaczej niż dzisiaj. Plik trafiał na serwer FTP, a szeroki zasięg zdobywał dopiero, gdy magazyny komputerowe dorzucały go do swoich płyt lub dyskietek.
Model „wypuśćmy, najwyżej potem załatamy” działał wyłącznie dla gier, które miały aktywną społeczność gotową szukać patchy w sieci i magazynach. Dla znacznej części odbiorców gra pozostawała w takim stanie, w jakim wyszła z pudełka. To wymuszało inny balans między terminem a jakością: niektóre studia wolały spóźnić się z premierą w jednym kraju, aby uniknąć fatalnych recenzji, nawet jeśli oznaczało to napięte relacje z wydawcą.
Demo jako główne narzędzie marketingu i testu rynku
Zamiast rozbudowanych kampanii reklamowych online istniało proste, lecz skuteczne narzędzie: demo dołączane do czasopism lub dostępne na BBS-ach. Dobrze zaprojektowane demo pełniło kilka ról naraz: przyciągało uwagę graczy, testowało stabilność na szerokiej gamie konfiguracji i dawało zespołowi realny feedback na etapie, gdy istniała jeszcze pewna elastyczność w projekcie.
Popularna rada „nie rób demo, bo zjada czas” nie sprawdzała się w tamtej epoce. Oczywiście pochłaniało to zasoby, ale bywało jedynym kanałem dotarcia do tysięcy potencjalnych nabywców. Kontrariańskie podejście nie polegało na rezygnacji z dema, tylko na jego świadomym „cięciu”: zamiast osobnego mini-projektu tworzono fragment gry, który i tak musiał istnieć, z lekkimi modyfikacjami pod kątem prezentacji. Kluczem było, aby wersja demo nie wymagała osobnej ścieżki produkcyjnej, bo tę trudno potem utrzymać przy zmianach w pełnej wersji.
Kontakt ze społecznością: listy, BBS-y i wczesne fora
Zamiast natychmiastowych recenzji na platformach cyfrowych twórcy otrzymywali feedback w znacznie wolniejszym rytmie. Listy papierowe, wiadomości na BBS-ach, później pierwsze fora internetowe – to był główny kanał reakcji graczy. Taka opóźniona informacja zwrotna miała zaskakujący efekt uboczny: pozwalała zespołom myśleć o kolejnej grze bardziej strategicznie, zamiast reagować na każdy pojedynczy komentarz.
Z drugiej strony, brak szybkiego kontaktu oznaczał większe ryzyko rozmijania się z oczekiwaniami rynku. Rada „słuchaj użytkowników, iteruj na podstawie danych” miała ograniczone zastosowanie, bo dane przychodziły z dużym opóźnieniem i była ich garstka. Zespoły kontrariańskie szukały więc innych źródeł informacji: obserwowały, jak ludzie grają na targach, zbierały uwagi recenzentów prasowych, porównywały własne rozwiązania z konkurencją. Spisy z BBS-ów czy wycinki recenzji wieszano dosłownie na ścianie biura jako stałe przypomnienie, co zadziałało, a co spaliło na panewce.
Projektowanie mechanik a realia sprzętu: kiedy pomysł musi ustąpić pamięci
Ambicje symulacyjne kontra twarda ściana wydajności
Lata 90. były czasem zderzenia dwóch przeciwstawnych impulsów: chęci tworzenia coraz bardziej „prawdziwych” światów oraz brutalnych limitów CPU i RAM. Wielu projektantów marzyło o rozbudowanych symulacjach ekonomii, ekologii czy zachowań społecznych NPC-ów, ale każdy dodatkowy system oznaczał cykle procesora zużyte na coś, czego gracz nawet nie widzi na ekranie.
Stąd charakterystyczne kompromisy: zamiast złożonego łańcucha produkcji w strategii – kilka prostych typów budynków; zamiast szczegółowych osobowości mieszkańców miasta – proste flagi „szczęśliwy/neutralny/zbuntowany”. Popularna rada „projektuj od razu jak najgłębsze systemy, potem je upraszczaj” często kończyła się frustracją programistów, którzy musieli przepisywać połowę kodu, gdy okazywało się, że CPU nie wyrabia. Skuteczniejszym podejściem bywało odwrócenie kolejności: zacząć od prymitywnej symulacji, obserwować, co generuje ciekawą złożoność, i tylko te elementy rozbudowywać, które realnie dawały efekt „wow” na ekranie, a nie tylko w dokumencie designu.
Balans trudności przy braku telemetrycznych danych
Dzisiejsze gry często opierają balans na danych: średni czas przejścia poziomu, procent zgonów na danej arenie, popularność konkretnych buildów postaci. W latach 90. takich statystyk po prostu nie było. Trudność ustawiano głównie „na wyczucie” zespołu i kilku testerów, ewentualnie korektami w kolejnych wersjach krajowych.
Tu pojawia się ciekawa sprzeczność z dzisiejszymi zaleceniami. Rada „testuj na możliwie szerokiej grupie, aż rozkład trudności się wypłaszczy” jest sensowna, gdy można łatwo zebrać i przetworzyć dane. W tamtych realiach bardziej pragmatyczne bywało celowanie w wyraźnie określoną publiczność: „hardkorowych” graczy, fanów symulatorów, młodszych odbiorców. Zamiast próbować zadowolić wszystkich, projektanci ustawiali poprzeczkę tam, gdzie sami ją czuli – i przyjmowali, że część osób odbije się od gry. To ryzykowne podejście, ale dawało tytułom charakter i rozpoznawalny profil, czego część współczesnych produkcji, wygładzonych przez telemetrykę, czasem już nie ma.
Level design jako odpowiedź na ograniczenia, a nie tylko pole ekspresji
Projektanci poziomów w latach 90. byli jednocześnie architektami doświadczenia i strażnikami budżetu technicznego. Każda duża otwarta przestrzeń oznaczała więcej widocznych obiektów, co wprost przekładało się na FPS. Każda skomplikowana ścieżka AI wymagała dodatkowych testów i pamięci na stany przeciwników. Dlatego wiele kultowych poziomów ma zaskakująco „ekonomiczną” strukturę: pętle, zawijasy, powroty do tych samych miejsc z innymi celami.
Dzisiejsza rada „unikaj backtrackingu, gracze nie lubią chodzenia po tych samych lokacjach” bywa nadużywana. Gdy projektant świadomie wykorzystuje powrót, aby pokazać ten sam fragment mapy w innym kontekście – z nowymi przeciwnikami, innym oświetleniem, odblokowanymi drzwiami – zyskuje zarówno na pamięci, jak i na dramaturgii. W latach 90. takie zabiegi były często wymuszone sprzętem, ale najlepsi twórcy potrafili przekuć je w atut, tworząc poczucie „znajomego, ale zmienionego” świata.
Interfejs i czytelność przy niskiej rozdzielczości
UI-owcy z tamtej dekady mieli inny zestaw problemów niż współcześni. Rozdzielczość 320×200 czy nawet 640×480 oznaczała bardzo ograniczoną przestrzeń na ekranie, a tekst musiał być czytelny na niedużych, często kiepsko skalibrowanych monitorach. Rozbudowane HUD-y czy wielokolumnowe ekrany ekwipunku, które dziś uważa się za standard w RPG-ach, były wtedy ryzykowne – zbyt małe, by dało się z nich wygodnie korzystać.
Najczęściej zadawane pytania (FAQ)
Dlaczego gry z lat 90. mają „inny klimat” niż współczesne produkcje?
Gry z lat 90. były projektowane pod bardzo konkretne konfiguracje sprzętowe: np. „PC z 486DX2, VGA, 8 MB RAM”. Cała mechanika, grafika i muzyka były szyte na miarę tych ograniczeń. Dziś gra musi działać od taniego laptopa po mocną konsolę, więc projekt jest bardziej uśredniony.
Odbieramy ten „inny klimat” nie tylko przez nostalgię, ale przez spójność wymuszoną techniką. Mniejsza rozdzielczość, mniej klatek animacji, charakterystyczne palety kolorów i dźwięk kart Sound Blaster tworzyły konkretny zestaw bodźców, który trudno odtworzyć w nowoczesnych, bardzo złożonych środowiskach.
Jak ograniczenia sprzętowe wpływały na projektowanie gier PC w latach 90.?
Większość decyzji projektowych wynikała wprost z wydajności 386/486 i pierwszych Pentium. Limit liczby przeciwników, prostsze AI, krótsze cut‑scenki czy rozdzielczość 320×200 to nie była kwestia gustu, tylko tego, co procesor i karta graficzna były w stanie uciągnąć.
Efekt uboczny był ciekawy: wiele mechanik upraszczano, ale za to szlifowano do bólu. Zamiast dokładać kolejne systemy, zespoły wyciskały maksimum z kilku podstawowych pomysłów, bo każdy dodatkowy ficzer kosztował cenne cykle CPU i kilobajty pamięci.
Czym różniły się gry 2D, „2.5D” i pełne 3D w latach 90.?
Na początku dekady dominowało klasyczne 2D i gry kafelkowe – silniki były proste, ale bardzo szybkie. W połowie pojawiło się „2.5D” (silniki doomopodobne): świat wyglądał trójwymiarowo, lecz technicznie był mocno uproszczony (brak prawdziwych wysokości, ograniczone kąty, sztuczne perspektywy).
Dopiero końcówka lat 90. to pełne 3D oparte na akceleratorach pokroju Voodoo. Zmieniło się praktycznie wszystko: sposób tworzenia poziomów, animacji, kamer, ale też wymagania sprzętowe. Popularna rada „rób grę 3D, bo to przyszłość” często kończyła się katastrofą, jeśli zespół chciał obsłużyć jeszcze słabsze maszyny – wtedy lepszą decyzją bywał dopracowany „2.5D” zamiast słabego, chrupiącego 3D.
Jaką rolę odegrały karty Voodoo 3Dfx w rozwoju gier PC?
Pojawienie się kart Voodoo umożliwiło sensowne teksturowanie, płynne modele 3D i wyższe rozdzielczości. Z punktu widzenia gracza różnica była dramatyczna: ta sama gra potrafiła wyglądać jak z innej epoki po włączeniu trybu 3Dfx.
Dla twórców oznaczało to jednak dodatkową złożoność. Często musieli utrzymywać dwa renderery: software’owy dla większości graczy oraz sprzętowy dla posiadaczy Voodoo. Przy małych zespołach bywało to zabójcze dla terminu – ambitne „podwójne” wsparcie miało sens tylko wtedy, gdy rynek docelowy faktycznie miał wystarczająco dużo użytkowników kart 3D.
Jak wyglądała praca twórcy gier PC w latach 90. od strony sprzętu i narzędzi?
Typowy developer siedział przy 486 lub pierwszym Pentium z 8–16 MB RAM i dyskiem rzędu kilkuset megabajtów. Ten sam dysk musiał pomieścić system, kompilatory, grafiki, dźwięki i kolejne buildy gry. Dodanie kilku minut nagranych dialogów było decyzją strategiczną, a nie prostym „dograniem plików”.
Standardem były karty VGA/SVGA oraz Sound Blaster/AdLib. Brak ujednoliconych interfejsów w rodzaju DirectX zmuszał programistów do ręcznego wykrywania sprzętu i bezpośredniego „grzebania” w pamięci wideo. To dawało ogromną kontrolę i optymalizację, ale też generowało całą masę błędów, zwłaszcza na nietypowych konfiguracjach.
Czy w latach 90. naprawdę było więcej kreatywności w grach niż dziś?
Popularny obraz „złotej ery” jest mocno uproszczony. Faktycznie łatwiej było przeforsować nietypowy pomysł w kilkuosobowym zespole, ale każdy pomysł musiał przejść przez bardzo ciasne sito sprzętu. Zbyt skomplikowana fizyka, ogromne otwarte mapy czy długie filmowe cut‑scenki często lądowały w koszu, bo zwyczajnie nie było jak ich uruchomić na docelowym PC.
Kreatywność miała więc inny charakter: liczyły się pomysły sprytne, mieszczące się w twardych limitach CPU, RAM i nośnika. Dziś ograniczeniem częściej jest budżet i czas, wtedy barierą bywała goła fizyka sprzętu. Ta różnica dobrze tłumaczy, dlaczego wiele prostych mechanicznie gier z lat 90. wciąż wydaje się wyjątkowo „dopieszczonych”.
Skąd brali się twórcy gier w latach 90. i jak wyglądała kultura pracy w studiach?
Większość twórców była samoukami. Programiści uczyli się z książek i magazynów, graficy często wywodzili się z demosceny, a muzycy z trackerów amigowych. Kierunku „game design” praktycznie nie było, co paradoksalnie ograniczało schematyczne podejścia – nikt nie próbował na siłę powielać „podręcznikowych” procesów.
Studia przypominały raczej garażowe start‑upy: małe zespoły, mało formalnych procedur, decyzje podejmowane „przy biurku”. Taki chaos dawał ogromną elastyczność, ale miał cenę – projekty potrafiły się rozjechać. Dziś wiele osób idealizuje tę swobodę, tymczasem w praktyce najlepiej radzili sobie ci, którzy łączyli luz z choćby minimalną dyscypliną: proste narzędzia, podstawowy harmonogram i jasny zakres gry zamiast niekończącego się dokładania nowych pomysłów.
Co warto zapamiętać
- Gry lat 90. miały wyraźny, „surowy” klimat głównie dlatego, że były projektowane pod ściśle określony sprzęt (np. 486DX2 + VGA), a nie pod dziesiątki konfiguracji – wszystko, od grafiki po muzykę, musiało idealnie zmieścić się w tych ramach.
- Ewolucja od 2D przez „2.5D” do pełnego 3D nie była płynna: każdy etap wymuszał całkowicie inny sposób myślenia o level designie, sterowaniu i narracji, a część pomysłów po prostu nie dawała się przenieść między tymi światami technicznymi.
- Sprzęt dyktował projekt bardziej niż wizja twórcy – liczba wrogów, rozdzielczość, długość cut‑scenek czy złożoność animacji wynikały z limitów CPU, pamięci i nośników, a nie z „czystej” decyzji designera.
- Wejście kart 3Dfx Voodoo otworzyło drogę do sensownego 3D, ale jednocześnie rozbiło produkcję na dwa równoległe światy (software rendering i wersja akcelerowana), co dla małych zespołów oznaczało podwójną pracę nad tym samym tytułem.
- Zamiast uniwersalnych silników dominowało pisanie wyspecjalizowanego kodu „pod jedną grę i jeden target hardware”; powszechna dzisiaj rada „weź gotowy silnik i nie martw się niskim poziomem” byłaby wtedy często zabójcza dla wydajności.
