enclose.horse

 (enclose.horse)
1 poin oleh GN⁺ 2026-01-07 | 1 komentar | Bagikan ke WhatsApp
  • Game puzzle untuk mengurung kuda dengan jumlah dinding terbatas, dengan tujuan membuat pagar seluas mungkin
  • Pemain mengklik tile rumput untuk memasang dinding, dan kuda tidak bisa bergerak diagonal atau melintasi air
  • Jika Cherries dimasukkan ke dalam pagar, pemain bisa mendapat poin tambahan, dan semakin besar pagarnya semakin tinggi skornya
  • Mendukung editor level, leaderboard, puzzle harian, dan fitur menjelajahi level buatan pengguna
  • Berawal dari ide sederhana, tetapi berkembang menjadi game bergaya masalah optimasi ala Leetcode/Advent of Code

Gambaran game

  • enclose.horse adalah game puzzle untuk mengurung kuda dengan menggunakan jumlah dinding yang terbatas
    • Tujuannya adalah mengelilingi area seluas mungkin dengan pagar
    • Skor ditentukan oleh ukuran pagar dan jumlah ceri yang termasuk di dalamnya
  • Cara bermainnya adalah dengan mengklik tile rumput untuk membangun dinding
    • Kuda tidak bisa bergerak diagonal atau bergerak di atas air
    • Jika ceri dimasukkan ke dalam pagar, pemain mendapatkan +3 poin
    • Pengiriman jawaban hanya bisa dilakukan satu kali

Antarmuka dan fitur game

  • Informasi level menampilkan ukuran (12x14), anggaran dinding (12), jumlah permainan (4455 kali), level ID (ZtiI9g), dan sebagainya
  • Di menu pengaturan, pemain dapat menyesuaikan nama, garis grid, tema, dan pengaturan lanjutan
  • Nama disimpan di leaderboard sehingga bisa dibandingkan dengan skor pemain lain
  • Melalui editor level, pemain dapat membuat dan membagikan puzzle sendiri
  • Di halaman “Browse”, pemain dapat menjelajahi level buatan pengguna lain dan memberi suara setelah bermain

Riwayat pembaruan

  • 29 Desember 2025: rilis awal, penambahan editor level dan leaderboard
  • 30 Desember: fitur puzzle harian (Daily puzzles) dan puzzle lama (Past Puzzles) diperkenalkan
  • 31 Desember: tab pembaruan ditambahkan
  • 1 Januari 2026: Solver ditambahkan ke editor level, serta fitur penjelajahan dan voting level buatan pengguna diperkenalkan
  • 2 Januari: fitur pelacakan area terbaik saat bermain ditambahkan
  • 3 Januari: elemen ceri ditambahkan
  • 4 Januari: perbaikan bug ceri dan peningkatan filter pencarian

Latar belakang pengembangan

  • Pengembang awalnya membayangkan game ini sebagai masalah optimasi ala Leetcode atau Advent of Code
  • Setelah mencobanya sendiri, pengembang menilai bahwa game ini layak dikembangkan menjadi game puzzle yang matang
  • Game ini dibuat oleh Shivers dan dipublikasikan melalui situs resmi serta akun X (Twitter)

Elemen lainnya

  • Fitur “Horse Tip” memberikan peringatan saat pemain masih memiliki sisa dinding ketika akan mengirim jawaban
    • Menyediakan opsi “jangan tampilkan lagi”
  • Melalui fitur laporan bug, pemain dapat melaporkan level yang tidak pantas atau mustahil diselesaikan
  • Termasuk beberapa elemen humor, seperti penamaan ceri (Name Five of Cherries)

Bacaan terkait

1 komentar

 
GN⁺ 2026-01-07
Komentar Hacker News

  • Ini benar-benar game yang menyenangkan. Jika pengembang mengumpulkan data dengan baik, rasanya 100 level yang dikelompokkan berdasarkan tingkat kesulitan juga layak dirilis di Steam.
    Namun, animasi pintu yang terangkat ke atas terasa membingungkan karena merusak logika visual 2D.
    Aku berharap nantinya ada mekanik game baru yang ditambahkan. Misalnya

    • Umpan: kuda bergerak menuju umpan di setiap giliran. Tumpukan jerami atau bongkahan gula sepertinya cocok dijadikan pemikat
    • Titik tujuan: puzzle yang mengarahkan kuda melewati pagar agar masuk ke petak tertentu
    • Banjir: air naik dari tepi, jadi pemain harus mengurung kuda sambil menahan air
    • Ada juga yang bilang pengumpulan data seperti ini terasa tidak nyaman. Menurutku dunia juga butuh game yang bisa dinikmati secara murni tanpa pengawasan
    • Game ini punya potensi sebagai minigame berbasis giliran. Saat kuda bergerak menuju jalan keluar, pemain menaruh dinding untuk mengubah rutenya, lalu dengan jumlah dinding terbatas mencoba membuatnya menempuh sebanyak mungkin petak—itu terdengar menarik
    • Aku setuju dengan pendapat bahwa efek pintu yang bergerak ke atas tidak cocok dengan estetika keseluruhan. Meski begitu, ini tetap game yang hebat
    • Aku menafsirkan animasi ini seperti sudut pandang RPG top-down. Secara visual tidak terlalu membingungkan, tetapi di ponsel jadi mudah menyentuh petak yang salah sehingga agak merepotkan
    • Menurutku game yang sederhana justru lebih bagus. Kalau bisa pemrograman, membuat versi sendiri dengan meluangkan beberapa akhir pekan juga bisa jadi proyek belajar yang bagus

  • Aku mencoba mencari solusi optimal untuk puzzle hari ke-8 secara manual, dan ternyata cukup seru.
    Aku memulai dari solusi minimum lalu memperluasnya langkah demi langkah, sambil memastikan setiap kali memindahkan dinding, solusi yang valid tetap terjaga.
    Pada akhirnya aku menemukan skor optimal hanya dalam 15 menit

    • Ada yang berpendapat pendekatan ini mirip dengan pola pikir TDD (Test-Driven Development)
    • Aku juga memakai algoritme yang sama. Pendekatan top-down tidak terlalu berhasil, tapi tetap sangat menyenangkan

  • Akan lucu kalau ceri diganti menjadi baterai dan nama gamenya diubah menjadi Correct Horse Battery Stable

    • Atau ceri diganti menjadi pastry atau camilan PBJ sehingga jadi Collect Horse Buttery Stable, itu juga lucu
    • Ada juga ide memakai staples alih-alih dinding
    • Ada yang bilang ceri bisa diganti bongkahan gula dan disebut My Lovely Horse
    • Lelucon ini merujuk ke xkcd 936

  • Gamenya sangat bagus. Hanya saja, saat menekan “Show optimal”, aku jadi tidak bisa membandingkannya dengan solusiku, dan itu agak disayangkan.
    Dinding yang terlihat menempati satu setengah petak juga membingungkan, dan desainnya terasa seperti pagar dinosaurus, jadi akan lebih baik kalau dibuat seperti pagar kuda

    • Akan bagus kalau “Show optimal” dibuat menjadi tombol toggle sehingga bisa bergantian melihat solusiku dan solusi optimal. Aku juga setuju bahwa di ponsel dinding yang saling bertumpuk membuatnya sulit disentuh
    • Perlu ada tombol untuk beralih dengan cepat. Aku menemukan cara kembali ke solusiku lewat menu tanggal-tanggal sebelumnya
    • Melihat kuda itu berbicara tentang dewa jahat saat diklik, rasanya mungkin ada sesuatu yang lebih di balik ini

  • Nilai awal sebaiknya ditampilkan sebagai N/EIGH alih-alih N/A agar sesuai dengan tema kuda

    • Itu mengingatkanku pada komik parlemen kuda (neigh) yang pernah kulihat
    • Kreativitas yang bisa memikirkan hal seperti ini benar-benar mengagumkan

  • Aku sampai membuat pencari solusi sendiri

    1. Ambil screenshot grid
    2. Unggah ke enclosure-horse-solution.onrender.com
    3. Cek jumlah dinding lalu klik Solve
      Karena ini versi gratis, kadang-kadang layanan bisa crash, tapi aku sudah menambahkan cache.
      Bisa juga dijalankan secara lokal lewat repositori GitHub
    • Di level editor, kamu bisa membuat map kustom dan melihat solusi optimal. Kalau peta resmi direkonstruksi, niat pengembang juga bisa terlihat
    • Ada juga yang bertanya apakah caching dilakukan di memori atau di disk. Rasanya akan lebih stabil kalau memakai Redis atau yang sejenis
    • Karena servernya sering down, jika hasilnya tidak keluar, disarankan menjalankannya secara lokal

  • Akan bagus kalau ada fitur untuk membandingkan solusiku dan solusi optimal sekaligus

    • Aku juga membandingkannya dengan mengambil dua screenshot
    • Fitur tampilan side-by-side (diff) akan membuatnya sempurna

  • Aku penasaran bagaimana cara mencari solusi optimal secara algoritmis untuk masalah ini. Di Factorio aku juga pernah mencoba menyelesaikan masalah serupa, tapi tidak menemukan cara yang cepat

    • Situs tersebut katanya memakai Answer Set Programming (ASP) dan engine Clingo. Masalah memaksimalkan di grid seperti ini kemungkinan besar NP-hard. Solver SAT/SMT tidak efisien untuk perhitungan flood-fill
    • Ada juga pendapat bahwa pendekatan constraint programming cocok dipakai. Posisi dinding dijadikan variabel, lalu petak yang bisa dijangkau kuda ditetapkan sebagai constraint
    • Ada orang yang mengatakan bahwa masalah ini langsung mengingatkannya pada berbagai pendekatan optimasi seperti graph cut, SAT/SMT, ACSP
    • Diskusi terkait juga ada di CS StackExchange
    • Ada yang menganggap ini masalah NP-hard dan bisa diturunkan dari Sparsest Cut. Usulnya adalah mencari minimum cut lalu berulang kali menyesuaikan kapasitas sambil melakukan pencarian

  • Setiap kali melihat domain horse, aku jadi tersenyum sendiri sambil menjalankan traceroute bad.horse

    • Ada juga tanggapan bahwa lelucon ini benar-benar indah

  • Sepertinya challenge harian dirilis berbeda tergantung zona waktu. Temanku sudah melihat hari ke-9, sedangkan aku masih hanya melihat hari ke-8.
    Akan lebih seru untuk bersaing dengan teman kalau waktu rilisnya dibuat seragam secara global