Studi Kasus - Membuat Doodle Google Stanisław Lem

Halo, dunia (yang aneh)

Beranda Google adalah lingkungan yang menarik untuk kode di dalamnya. Fitur ini hadir dengan banyak batasan yang menantang: fokus khusus pada kecepatan dan latensi, yang harus mengakomodasi semua jenis browser dan bekerja dalam berbagai situasi, dan... ya, kejutan dan kesenangan.

Yang saya maksud adalah doodle Google, ilustrasi khusus yang terkadang menggantikan logo kami. Dan meskipun hubungan saya dengan pena dan kuas telah lama memiliki rasa yang khas dari perintah penahan, saya sering berkontribusi pada tindakan yang interaktif.

Setiap coretan interaktif yang saya beri kode (Pac-Man, Jules Verne, World’s Fair)– dan banyak bantuan yang saya bantu – hampir sama-sama bersifat futuristik dan anakronistik: peluang besar untuk aplikasi fitur Web canggih yang luar biasa... dan pragmatisme yang jelas untuk kompatibilitas lintas-browser.

Kami belajar banyak dari setiap doodle interaktif, tak terkecuali game mini Stanisław Lem terbaru, dengan 17.000 baris kode JavaScript-nya yang mencoba banyak hal untuk pertama kalinya dalam sejarah orat-coret. Hari ini, saya ingin berbagi kode itu dengan Anda – mungkin Anda akan menemukan sesuatu yang menarik di sana, atau menunjukkan kesalahan saya – dan sedikit membahasnya.

Lihat kode doodle Stanisław Lem »

Hal yang perlu diingat adalah halaman beranda Google bukanlah tempat untuk demo teknologi. Dengan coretan, kami ingin merayakan orang dan acara tertentu, dan kami ingin melakukannya dengan menggunakan seni terbaik dan teknologi terbaik yang dapat kami kumpulkan – tetapi jangan pernah merayakan teknologi demi teknologi. Ini berarti memperhatikan dengan cermat bagian apa pun dari HTML5 yang dapat dipahami secara luas yang tersedia, dan apakah hal itu membantu kami membuat coretan menjadi lebih baik tanpa mengganggu atau membayanginya.

Jadi, mari kita amati beberapa teknologi Web modern yang menemukan tempatnya – dan beberapa yang tidak – dalam coretan Stanisław Lem.

Grafik melalui DOM dan kanvas

Canvas sangat andal dan dibuat untuk hal-hal yang ingin kami lakukan dalam doodle ini. Namun, beberapa browser lama yang menjadi perhatian kami tidak mendukungnya – dan meskipun saya benar-benar berbagi kantor dengan orang yang membuat excanvas yang sangat bagus, saya memutuskan untuk memilih cara lain.

Saya mengumpulkan mesin grafis yang memisahkan primitif grafis yang disebut "rects", lalu merendernya menggunakan salah satu kanvas, DOM jika kanvas tidak tersedia.

Pendekatan ini memiliki beberapa tantangan menarik – misalnya, memindahkan atau mengubah objek dalam DOM memiliki konsekuensi langsung, sedangkan untuk kanvas, ada momen tertentu saat semuanya digambar pada waktu yang sama. (Saya memutuskan untuk hanya memiliki satu kanvas, dan membersihkannya dan menggambar dari awal pada setiap bingkai. Terlalu banyak, secara harfiah, bagian yang bergerak di satu sisi – dan di sisi lain, tidak cukup kompleksitas untuk menjamin pembagian menjadi beberapa kanvas yang tumpang-tindih dan memperbaruinya secara selektif.)

Sayangnya, beralih ke kanvas tidak semudah mencerminkan latar belakang CSS dengan drawImage(): Anda kehilangan beberapa item yang tersedia secara gratis saat menyatukan berbagai hal melalui DOM. Yang terpenting adalah menambahkan indeks z dan peristiwa mouse.

Saya sudah memisahkan indeks z dengan konsep yang disebut “bidang”. Doodle mendefinisikan sejumlah bidang – dari langit yang jauh di belakang, hingga pointer mouse di depan semuanya – dan setiap aktor dalam coretan ini harus memutuskan terkait mana yang dimaksud (koreksi plus/minus kecil dalam sebuah bidang yang dimungkinkan dengan menggunakan planeCorrection).

Merender melalui DOM, bidang-bidang ini hanya diterjemahkan ke dalam indeks z. Namun, jika merender melalui kanvas, kita perlu mengurutkan persegi panjang berdasarkan bidangnya sebelum menggambarnya. Karena melakukan hal ini setiap saat akan memakan biaya, urutannya hanya dihitung ulang ketika seorang aktor ditambahkan atau ketika ia berpindah ke bidang lain.

Untuk peristiwa mouse, saya juga memisahkannya... semacam itu. Untuk DOM dan kanvas, saya menggunakan elemen DOM mengambang yang benar-benar transparan dengan indeks z tinggi, yang fungsinya hanya untuk bereaksi terhadap mouse over/out, klik, dan ketukan.

Salah satu hal yang ingin kami coba dengan doodle ini adalah menerobos dinding keempat. Mesin di atas memungkinkan kita menggabungkan aktor berbasis kanvas dengan aktor berbasis DOM. Misalnya, ledakan di final terjadi di kanvas untuk objek di alam semesta dan di DOM untuk halaman beranda Google lainnya. Burung yang biasanya terbang dan terjepit oleh topeng bergerigi kita seperti aktor lainnya, memutuskan untuk tidak keluar dari masalah selama pengambilan gambar, dan duduk di tombol Saya Lagi Beruntung. Cara yang dilakukan adalah saat burung meninggalkan kanvas dan menjadi elemen DOM (dan sebaliknya nanti), yang saya harap sepenuhnya transparan bagi pengunjung kami.

Kecepatan frame

Mengetahui kecepatan frame saat ini dan bereaksi saat terlalu lambat (dan terlalu cepat!) adalah bagian penting dari mesin kami. Karena browser tidak melaporkan kembali kecepatan frame, kita harus menghitungnya sendiri.

Saya mulai menggunakan requestAnimationFrame, kembali ke setTimeout lama jika yang pertama tidak tersedia. requestAnimationFrame dengan cerdas menyimpan CPU dalam beberapa situasi – meskipun kita melakukannya sendiri, seperti yang akan dijelaskan di bawah – tetapi juga memungkinkan kita mendapatkan kecepatan frame yang lebih tinggi dari setTimeout.

Menghitung kecepatan frame saat ini cukup sederhana, tetapi dapat mengalami perubahan drastis – misalnya, penghitungan kecepatan frame dapat turun dengan cepat ketika aplikasi lain memotong komputer untuk sementara waktu. Oleh karena itu, kami menghitung kecepatan frame “rolling” (rata-rata) hanya di setiap 100 tick fisik dan membuat keputusan berdasarkan hal tersebut.

Keputusan seperti apa?

• Jika kecepatan frame lebih tinggi dari 60 fps, kami akan membatasinya. Saat ini, requestAnimationFrame pada beberapa versi Firefox tidak memiliki batas atas pada kecepatan frame, dan tidak ada gunanya membuang-buang CPU. Perhatikan bahwa kami membatasinya pada 65 fps, karena error pembulatan yang membuat kecepatan frame sedikit lebih tinggi dari 60 fps di browser lain – kami tidak ingin memulai throttling secara tidak sengaja.

• Jika kecepatan frame lebih rendah dari 10 fps, kita cukup memperlambat mesin, bukan menurunkan frame. Ini proposisi kehilangan-kalah, tetapi saya merasa bahwa melewatkan frame secara berlebihan akan lebih membingungkan daripada hanya memiliki game yang lebih lambat (tapi masih koheren). Ada efek samping lain yang bagus dari hal tersebut – jika sistem menjadi lambat untuk sementara, pengguna tidak akan mengalami lompatan aneh karena mesin berusaha mengejar. (Saya melakukannya sedikit berbeda untuk Pac-Man, tetapi kecepatan frame minimum adalah pendekatan yang lebih baik.)

• Terakhir, kita dapat memikirkan untuk menyederhanakan grafis saat kecepatan frame menjadi sangat rendah. Kami tidak melakukannya untuk Lem doodle dengan pengecualian pointer mouse (selengkapnya di bawah), tetapi secara hipotesis kita dapat kehilangan beberapa animasi yang tidak relevan hanya agar doodle terasa lancar bahkan pada komputer yang lebih lambat.

Kami juga memiliki konsep {i> fisik tick<i} dan {i>logical tick<i}. Yang pertama berasal dari requestAnimationFrame/setTimeout. Rasio dalam gameplay normal adalah 1:1, tetapi untuk maju cepat, kami hanya menambahkan lebih banyak tick logis per tick fisik (hingga 1:5). Hal ini memungkinkan kita melakukan semua penghitungan yang diperlukan untuk setiap tick logis, tetapi hanya menetapkan yang terakhir untuk memperbarui item di layar.

Membuat tolok ukur

Asumsi dapat (dan memang sejak awal) dibuat bahwa kanvas akan lebih cepat daripada DOM setiap kali tersedia. Hal itu tidak selalu benar. Saat pengujian, kami menemukan bahwa Opera 10.0–10.1 di Mac, dan Firefox di Linux sebenarnya lebih cepat saat memindahkan elemen DOM.

Sesungguhnya, coretan akan secara diam-diam mengukur berbagai teknik grafis – elemen DOM dipindahkan menggunakan style.left dan style.top, menggambar di kanvas, dan bahkan mungkin elemen DOM dipindahkan menggunakan transformasi CSS3

– lalu beralih ke frame mana saja yang memberikan kecepatan frame tertinggi. Saya mulai menulis kode untuk itu, tetapi saya menyadari bahwa setidaknya cara benchmark saya cukup tidak dapat diandalkan dan membutuhkan banyak waktu. Saat ini, kami tidak memiliki waktu di halaman beranda – kami sangat peduli dengan kecepatan dan ingin agar doodle muncul seketika dan gameplay dimulai segera setelah Anda mengklik atau mengetuk.

Pada akhirnya, pengembangan Web terkadang bermuara pada tugas yang harus Anda lakukan. Saya menengok ke belakang untuk memastikan tidak ada yang melihat, dan kemudian saya melakukan hard code Opera 10 dan Firefox dari kanvas. Di kehidupan berikutnya, saya akan kembali sebagai tag <marquee>.

Menghemat CPU

Anda tahu, teman yang datang ke rumah Anda menonton season terakhir Break Bad, merusaknya untuk Anda, lalu menghapusnya dari DVR? Anda tidak ingin menjadi orang itu, kan?

Jadi, ini analogi terburuk yang pernah ada. Tapi kita juga tidak ingin doodle seperti itu – fakta kita diizinkan masuk ke tab browser seseorang adalah hak istimewa, dan menimbun siklus CPU atau mengganggu pengguna akan membuat kita menjadi tamu yang tidak menyenangkan. Oleh karena itu, jika tidak ada yang bermain dengan coretan (tidak ada ketukan, klik mouse, gerakan mouse, atau penekanan tombol), kita ingin menginjak layar pada akhirnya.

Kapan?

• setelah 18 detik di beranda (game arcade yang disebut ini mode tarik)
• setelah 180 detik jika tab memiliki fokus
• setelah 30 detik jika tab tidak difokuskan (misalnya pengguna beralih ke jendela lain, namun mungkin masih menonton corat-coret di tab yang tidak aktif)
• segera jika tab menjadi tidak terlihat (misalnya pengguna beralih ke tab lain di jendela yang sama - tidak ada gunanya membuang siklus jika kita tidak terlihat)

Bagaimana cara mengetahui bahwa tab saat ini memiliki fokus? Kita melampirkan diri ke window.focus dan window.blur Bagaimana kita tahu tab itu terlihat? Kami menggunakan Page Visibility API baru dan menanggapi peristiwa yang sesuai.

Waktu tunggu di atas lebih memaklumi dari biasanya. Saya mengadaptasinya ke coretan khusus ini, yang memiliki banyak animasi ambien (terutama langit dan burung). Idealnya, waktu tunggu akan dibatasi pada interaksi dalam game – misalnya tepat setelah mendarat, burung bisa melaporkan kembali ke doodle bahwa ia bisa tidur sekarang – tetapi saya tidak menerapkannya pada akhirnya.

Karena langit selalu bergerak, ketika tertidur dan membangunkan doodle tidak hanya berhenti atau memulai – melambat sebelum dijeda, dan sebaliknya untuk melanjutkan, menambah atau mengurangi jumlah tick logis per tick fisik sesuai kebutuhan.

Transisi, transformasi, peristiwa

Salah satu kekuatan HTML adalah fakta bahwa Anda dapat membuatnya menjadi lebih baik: jika ada sesuatu yang tidak cukup baik dalam portofolio HTML dan CSS biasa, Anda bisa melibatkan JavaScript untuk memperluasnya. Sayangnya, sering kali harus memulai dari awal. Transisi CSS3 sangat bagus, tetapi Anda tidak dapat menambahkan jenis transisi baru atau menggunakan transisi untuk melakukan hal lain selain elemen gaya visual. Contoh lain: Transformasi CSS3 sangat cocok untuk DOM. Namun, saat beralih ke kanvas, Anda tiba-tiba melakukannya sendiri.

Masalah ini, dan banyak lagi, adalah alasan Lem doodle memiliki mesin transisi dan transformasinya sendiri. Ya, saya tahu, tahun 2000-an disebut, dll. – kemampuan yang saya bangun tidak sehebat CSS3, tetapi apa pun yang dilakukan mesinnya, selalu konsisten dan memberi kami lebih banyak kontrol.

Saya memulai dengan sistem tindakan (peristiwa) sederhana – linimasa yang memicu peristiwa di masa mendatang tanpa menggunakan setTimeout, karena pada titik tertentu, waktu doodle dapat berpisah dari waktu fisik karena menjadi lebih cepat (maju), lebih lambat (kecepatan frame rendah atau tertidur untuk menghemat CPU), atau berhenti sama sekali (menunggu gambar selesai dimuat).

Transisi hanyalah jenis tindakan lainnya. Selain gerakan dasar dan rotasi, kami juga mendukung gerakan relatif (misalnya menggerakkan sesuatu 10 piksel ke kanan), hal-hal khusus seperti menggigil, dan juga animasi gambar keyframe.

Saya telah menyebutkan rotasi, dan itu juga dilakukan secara manual: kami memiliki sprite untuk berbagai sudut objek yang perlu diputar. Alasan utamanya adalah rotasi CSS3 dan kanvas menampilkan artefak visual yang kami anggap tidak dapat diterima – dan selain itu, artefak tersebut bervariasi di setiap platform.

Mengingat beberapa objek yang berputar melekat pada objek berputar lainnya – salah satu contohnya adalah tangan robot yang terhubung ke lengan bawah, yang terpasang pada lengan atas yang berputar – ini berarti saya juga perlu membuat transform-origin orang miskin dalam bentuk pivot.

Semua ini adalah pekerjaan besar yang pada akhirnya mencakup area yang sudah ditangani oleh HTML5 – tetapi terkadang dukungan native tidak cukup baik dan sudah waktunya untuk penemuan kembali roda.

Menangani gambar dan sprite

Mesin bukan hanya untuk menjalankan {i>doodle<i} – itu juga untuk mengerjakannya. Saya membagikan beberapa parameter debug di atas: Anda dapat menemukan sisanya di engine.readDebugParams.

Spriting adalah teknik terkenal yang juga kami gunakan untuk membuat coretan. Hal ini memungkinkan kami menghemat byte dan mengurangi waktu pemuatan, serta mempermudah pramuat. Namun, hal ini juga mempersulit pengembangan – setiap perubahan pada gambar akan memerlukan spriting ulang (sangat otomatis, tetapi tetap rumit). Oleh karena itu, mesin mendukung pengoperasian gambar mentah untuk pengembangan serta sprite untuk produksi melalui engine.useSprites – keduanya disertakan dalam kode sumber.

Kami juga mendukung pramuat gambar seiring kami melanjutkan dan menghentikan doodle jika gambar tidak dimuat tepat waktu – lengkap dengan status progres tiruan. (Faux karena, sayangnya, bahkan HTML5 tidak dapat memberi tahu kita berapa banyak file gambar yang telah dimuat.)

Untuk beberapa adegan, kami menggunakan lebih dari satu sprite untuk mempercepat pemuatan menggunakan koneksi paralel, tetapi hanya karena batasan 3/5 juta piksel untuk gambar di iOS.

Di mana HTML5 sesuai dengan semua ini? Tidak ada banyak hal di atas, tetapi alat yang saya tulis untuk melakukan spriting/crop adalah teknologi Web baru: kanvas, blob, [download]. Salah satu hal menarik tentang HTML adalah HTML dengan perlahan mengasumsikan hal-hal yang sebelumnya harus dilakukan di luar browser; satu-satunya bagian yang perlu kita lakukan di sana adalah mengoptimalkan file PNG.

Menyimpan status di antara pertandingan

Dunia Lem selalu terasa besar, hidup, dan realistis. Ceritanya biasanya dimulai tanpa banyak penjelasan, halaman pertama dimulai dengan ulasan media, dan pembaca harus menemukannya.

Begitu juga dengan Cyberiad dan kami ingin meniru perasaan tersebut pada coretan tersebut. Kita mulai dengan mencoba untuk tidak menjelaskan cerita secara berlebihan. Bagian besar lainnya adalah pengacakan yang kami anggap sesuai dengan sifat mekanik semesta buku ini; kami memiliki sejumlah fungsi bantuan yang menangani keacakan yang kami gunakan di banyak tempat.

Kami juga ingin meningkatkan kemampuan untuk diputar ulang dengan cara lain. Untuk itu, kita perlu tahu berapa kali {i>doodle<i} diselesaikan sebelumnya. Solusi teknologi yang benar secara historis adalah cookie, tetapi itu tidak berfungsi untuk halaman beranda Google – setiap cookie meningkatkan payload setiap halaman, dan sekali lagi, kami sangat peduli dengan kecepatan dan latensi.

Untungnya, HTML5 memberi kita Web Storage, yang mudah digunakan, memungkinkan kita untuk menyimpan dan mengingat jumlah pemutaran umum dan adegan terakhir yang diputar oleh pengguna – dengan jauh lebih elegan daripada yang dimungkinkan oleh cookie.

Apa yang kita lakukan dengan informasi ini?

• kita menampilkan tombol maju cepat, yang memungkinkan zip melalui cutscene yang sudah dilihat pengguna sebelumnya
• kita tampilkan N item yang berbeda selama
• kami sedikit meningkatkan kesulitan level pemotretan
• kami menampilkan naga probabilitas telur paskah kecil dari cerita yang berbeda pada drama ketiga dan berikutnya

Ada sejumlah parameter debug yang mengontrol hal ini:

• ?doodle-debug&doodle-first-run – anggap saja ini baru dijalankan untuk pertama kalinya
• ?doodle-debug&doodle-second-run – anggap ini adalah putaran kedua
• ?doodle-debug&doodle-old-run – anggap itu adalah lomba lari kuno

Perangkat sentuh

Kami ingin doodle ini terasa familier di perangkat sentuh – yang paling modern cukup kuat sehingga doodle bisa berjalan dengan baik, dan mengalami permainan melalui ketukan jauh lebih menyenangkan daripada mengklik.

Beberapa perubahan awal pada pengalaman pengguna perlu dilakukan. Awalnya, pointer mouse kami adalah satu-satunya tempat untuk mengomunikasikan bagian cutscene/non-interaktif sedang berlangsung. Kemudian, kami menambahkan sedikit indikator di pojok kanan bawah, sehingga kami tidak perlu mengandalkan pointer mouse saja (mengingat bahwa itu tidak ada di perangkat sentuh).

	Normal	Ramai	Dapat diklik	Diklik
Dalam proses
Final	v

Sebagian besar tugas langsung berfungsi dengan baik. Namun, pengujian kegunaan mendadak yang cepat dari pengalaman sentuh kami menunjukkan dua masalah: beberapa target terlalu sulit untuk ditekan, dan ketukan cepat diabaikan karena kita baru saja mengganti peristiwa klik mouse.

Memiliki elemen DOM transparan terpisah yang dapat diklik sangat membantu di sini, karena saya dapat mengubah ukurannya secara terpisah dari visual. Saya memperkenalkan padding 15 piksel tambahan untuk perangkat sentuh dan menggunakannya setiap kali elemen yang dapat diklik dibuat. (Saya juga menambahkan padding 5 piksel untuk lingkungan mouse, hanya untuk membuat Mr. Fitts senang.)

Sedangkan untuk masalah lainnya, saya memastikan untuk melampirkan dan menguji pengendali mulai sentuh dan akhir yang tepat, bukan mengandalkan klik mouse.

Kami juga menggunakan properti gaya yang lebih modern untuk menghapus beberapa fitur sentuh yang ditambahkan browser WebKit secara default (ketuk sorotan, ketuk info).

Dan bagaimana kita mendeteksi apakah perangkat tertentu yang menjalankan doodle mendukung sentuhan? Malas. Alih-alih mencari tahu priori, kami hanya menggunakan IQ gabungan untuk menyimpulkan bahwa perangkat mendukung sentuhan... setelah kami mendapatkan peristiwa mulai sentuh pertama.

Menyesuaikan kursor mouse

Namun, tidak semuanya berbasis sentuhan. Salah satu prinsip panduan kami adalah dengan menempatkan sebanyak mungkin hal di alam semesta {i>doodle<i}. UI sidebar kecil (maju cepat, tanda tanya), tooltip, dan, bahkan, pointer mouse.

Bagaimana cara menyesuaikan kursor mouse? Beberapa browser memungkinkan perubahan kursor mouse dengan menautkan ke file gambar yang dibuat khusus. Namun, hal ini tidak didukung dengan baik dan juga agak membatasi.

Jika bukan ini, lalu apa? Nah, mengapa tidak membuat {i>mouse<i} hanya untuk aktor lain di {i>doodle<i}? Cara ini berhasil, tetapi memiliki sejumlah peringatan, terutama:

• Anda harus dapat menghapus pointer mouse native,
• Anda harus pandai menjaga agar {i>mouse<i} Anda tetap sinkron dengan yang "sebenarnya"

Tema yang pertama rumit. CSS3 memungkinkan untuk cursor: none, tetapi juga tidak didukung di beberapa browser. Kami perlu melakukan beberapa senam: menggunakan file .cur kosong sebagai penggantian, menentukan perilaku konkret untuk beberapa browser, dan bahkan melakukan hard-coding yang lain dari pengalaman apa pun.

Yang lain relatif sepele di wajahnya, tetapi dengan pointer mouse yang hanya menjadi bagian lain dari alam semesta doodle, akan mewarisi semua masalahnya juga. Yang terbesar? Jika kecepatan frame doodle rendah, kecepatan frame pointer mouse juga akan rendah – dan itu memiliki konsekuensi yang mengerikan karena pointer mouse, yang merupakan perluasan alami tangan Anda, harus terasa responsif, apa pun situasinya. (Orang yang menggunakan Commodore Amiga di masa lalu sekarang mengangguk dengan keras.)

Salah satu solusi yang agak kompleks untuk masalah tersebut adalah memisahkan pointer mouse dari loop update reguler. Kami melakukannya – di alam semesta alternatif di mana saya tidak perlu tidur. Solusi yang lebih sederhana untuk hal ini? Hanya kembali ke pointer mouse native jika kecepatan frame bergulir turun di bawah 20 fps. (Di sinilah kecepatan frame bergulir berguna. Jika kita bereaksi terhadap kecepatan frame saat ini, dan jika bergeser sekitar 20 fps, pengguna akan melihat pointer mouse kustom disembunyikan dan ditampilkan sepanjang waktu.) Hal ini mengarahkan kita ke:

Rentang kecepatan frame	Perilaku
>10fps	Perlambat game agar lebih banyak frame tidak hilang.
10–20fps	Menggunakan pointer mouse native, bukan yang kustom.
20–60fps	Pengoperasian normal.
>60fps	Throttle sehingga kecepatan frame tidak melebihi nilai ini.

Oh, dan pointer mouse kita gelap di Mac, tetapi putih di PC. Mengapa demikian? Karena perang platform perlu bahan bakar bahkan di alam semesta fiksi.

Kesimpulan

Ini bukan mesin yang sempurna, tapi jangan coba untuk menjadi salah satunya. Alat ini dikembangkan bersama dengan Lem doodle, dan sangat spesifik untuk itu. Tidak apa-apa. "Pengoptimalan prematur adalah akar dari segala kejahatan," seperti yang dikatakan Don Knuth, dan saya tidak percaya bahwa menulis mesin secara terpisah terlebih dahulu, dan hanya menerapkannya nanti saja yang masuk akal. Praktik ini memberi tahu teori seperti halnya teori menginformasikan praktik. Dalam kasus saya, kode dibuang, beberapa bagian ditulis ulang berulang kali, dan banyak bagian umum yang diperhatikan diposting, bukan ante factum. Namun pada akhirnya, kami di sini dapat melakukan apa yang kami inginkan – rayakan karier Stanisław Lem dan gambar karya Daniel Mróz dengan cara terbaik.

Semoga penjelasan di atas menjelaskan beberapa pilihan desain dan konsekuensi yang perlu kami buat, serta cara kami menggunakan HTML5 dalam skenario spesifik di kehidupan nyata. Sekarang, cobalah kode sumbernya, coba, dan beri tahu kami apa yang Anda pikirkan.

Saya melakukannya sendiri – di bawah ini ditayangkan beberapa hari terakhir, dengan hitungan mundur hingga 23 November 2011 di Rusia, yang merupakan zona waktu pertama yang melihat coretan Lem. Hal yang konyol, mungkin, tetapi seperti coretan, hal-hal yang tampak tidak signifikan terkadang memiliki makna yang lebih dalam – penghitung ini benar-benar “uji stres” yang bagus bagi mesin.

Dan itulah salah satu cara untuk melihat proses hidup orat-coret Google – berbulan-bulan bekerja, berminggu-minggu, 48 jam membuatnya, semua untuk sesuatu yang dimainkan orang-orang selama lima menit. Setiap satu dari ribuan baris JavaScript itu berharap bahwa 5 menit itu akan bermanfaat bagi mereka. Selamat menikmati.