Program kami menggunakan 1 buah kelas View yaitu GameDisplay dan yang berperan sebagai Model adalah semua kelas turunan dari kelas GameObject yaitu semua objek yang didalamnya memiliki objek lain yang dapat dirender ke dalam Canvas yang dimiliki oleh kelas GameDisplay. Controller dalam program kami terdiri dari 2 buah kelas, yaitu kelas GameEngine dan kelas GameStateManager, dimana GameEngine mengatur resource yang akan digunakan oleh kelas-kelas turunan GameObject dan juga mengatur proses rendering ke GameDisplay, dan GameStateManager mengatur kapan sebuah objek harus di render dan di update.
Ular dan tangga dalam program kami di hasilkan secara acak dengan menghubungkan 2 buah tile yang ada di papan permainan, untuk itu kami harus dapat berjalan per langkah dengan jarak tertentu untuk dapat menghasilkan bentuk yang unik seperti ular yang meliuk-liuk dan tangga yang memiliki anak tangga.
Oleh karena itu kami membuat sebuah kelas iterator, PointToPointIterator, yang mampu meng-iterasi sebuah garis, per jarak yang ditentukan, di antara dua buah tile dan juga menyesuaikan pertambahan jarak terhadap sumbu x dan sumbu y dengan memperhitungkan gradien/kemiringan garis.
Pemain/Bidak dalam permainan ini haruslah dapat mengikuti bentuk dan arah dari tangga dan ular, jika harus berjalan melalui tangga maka bidak harus bergerak mengikuti bentuk dari tangga, dan jika melalui ular maka bidak harus bergerak mengikuti bentuk ular.
Oleh karena itu kami membuat kelas iterator, DynamicLineIterator yang mampu meng-iterasi titik-titik yang ada didalam sebuah garis, yang lurus maupun bergelombang, agar pemain dapat berpindah ke titik-titik tersebut sehingga terlihat seperti mengikuti bentuk dari ular maupun tangga.
Kelas Board merupakan kelas yang spesial, sebagai kelas turunan dari kelas GameObject, kelas Board tidak memiliki objek untuk dirender, namun kelas Board merupkan kelas yang terdiri dari komposisi kelas Tile. Board mampu mempopulasikan Tile dan memberikan struktur kepada banyak Tile untuk membentuk papan permainan, juga merender Tile seakan-akan kelas Tile merupakan kelas Board.
Kelas Board juga memiliki ketergantungan lain, yaitu pada kelas Player, Dice, Snake, dan Ladder agar mampu berfungsi sebagai mana semestinya. Namun tidak seperti ke kelas Tile yang merupakan komposisi dari kelas Board, kelas Player, Dice, Snake, dan Ladder tidak dirender oleh Kelas Board melainkan hanya dipopulasikan saja agar mempunyai bentuk, ukuran, dan posisi yang benar di dalam Board saat digunakan dalam permainan. Kelas Board tidak bertanggung jawab terhadap proses rendering dan updating dari kelas-kelas yang bukan merupakan komposisi dari Board.
Program kami tidak menggunakan komponen-komponen yang disediakan Swing untuk membuat tombol, label, dan panel, melainkan kami membuat komponen-komponen sendiri agar komponen tersebut terlihat lebih cocok dengan desain UI kami.
Untuk alasan diatas kami harus dapat menyediakan fasilitas event Broadcasting dan event Listening, maka kami membuat sebuah interface bernama GameEventBroadcaster dan GameEventListener. GameEventListener berfungsi sebagai observer dan GameEventBroadcaster berfungsi sebagai Subject, dengan mekanisme ini kami dapat memberikan kemampuan terhadap komponen-komponen yang kami buat untuk merespon terhadap sebuah event.
Setiap GameObject dalam program kami membutuhkan proses rendering jika ditambah dengan implementasi interface GameObjectUpdate maka objek tersebut haruslah di update karena nilainya terus berubah sepanjang permainan. Program kami memiliki banyak Tile, Button, Label, Snake, Ladder dll, yang harus dirender dan di update maka kami harus mengatur dimana dan kapan proses tersebut harus dilakukan.
Setiap GameObject dimiliki oleh sebuah GameState. GameState memiliki fungsi untuk merender, mengupdate, dan meneruskan event ke setiap GameObject yang menjadi anggotanya. Jadi hanya saat sebuah GameState tersebut aktif, maka GameObject yang menjadi anggota GameState tersebut di render dan di update.
Dengan adanya pembagian tanggung jawab atas proses rendering, updating, dan event-broadcasting, maka kami dapat mengendalikan bagaimana, kapan, dan terhadap objek apa proses tersebut harus dilakukan. Namun walaupun demikian kami masih memiliki 5 GameState berbeda, dan jika secara langsung diserahkan kepada GameEngine maka akan sulit untuk untuk mengontrol rendering, updating, dan event-broadcasting dari setiap GameState.
Untuk alasan diatas kami membuat sebuah Controller selain GameEngine yaitu kelas statik GameStateManager untuk menjembatani GameEngine dimana GameObject benar-benar di proses, dengan Model yang harus diproses. Seakan-akan GameEngine hanya memproses sebuah objek saja yaitu GameStateManager, padahal sebenarnya GameStateManager memberikan GameState yang sedang aktif kepada GameEngine untuk diproses, dan GameState memproses semua anggota-anggotanya sehingga membentuk chain of responsibility yang mudah untuk di maintain dan di debug.
Dalam kasus tertentu beberapa objek harus dapat berkomunikasi agar pertukaran data antar objek dapat terjadi, namun terkadang sebuah objek tidak memiliki hubungan apapun sehingga untuk diperlukan perubahan yang dapat membuat kelas yang tidak memiliki hubungan menjadi saling ketergantungan.
Oleh karena itu kami membuat sebuah kelas yang khusus untuk mengangani sebuah kasus yang kami temui, yaitu ketika GameStage yang mengatur giliran pemain harus dapat memberikan data kepada sebuah komponen Label yang menampilkan giliran pemain sekarang. Maka kami membuat dua interface bernama DataBinder dan DataBindAction yang memberikan kemampuan kepada Label untuk mengubah data pada Label sesuai dengan data yang ada pada GameStage, dengan begitu kami dapat menghubungkan GameStage dan Label tanpa menyebabkan kedua kelas tersebut menjadi saling ketergantungan.
Program kami mengunakan gambar sebagai background, warna tertentu untuk objek tertentu dan juga font tertentu untuk memenuhi desain UI kami. Program haruslah mengambil gambar dan font dari file diluar program, dan warna yang kami gunakan terkadang tidak memiliki nama dan hanya berupa nomor RGB. Jika kami tidak membuat sebuah mekanisme untuk mengatur resource yang kami gunakan maka akan sulit untuk menentukan warna dan gambar yang dibutuhkan oleh objek tertentu dan dimana resource itu disimpan.
Oleh karena itu kami membuat sebuah kelas statik bernama AssetManager yang memberi kemudahan bagi penulis program untuk mengenali suatu resource digunakan oleh siapa dan dipergunakan sebagai apakah resource tersebut, karena AssetManager memungkinkan penulis program untuk dapat memberikan sebuah gambar, font, ataupun warna sebuah nama, dan dapat pula diakses berdasarkan nama yang diberikan.
Desain UI program kami membutuhkan banyak konstanta untuk mengatur seberapa sebesar sebuah objek dan dimana sebuah objek dirender, serta membutuhkan konstanta untuk mengatur delay dan pengaturan-pengaturan Grafik seperti penggunaan antialiasing dan pengaturan banyaknya frame yang di render setiap detik (FPS), yang jika tidak di definisikan dalam sebuah konstanta akan menyebabkan kode program dipenuhi oleh angka-angka yang sulit ditentukan kegunaannya dan juga sulit untuk diubah saat runtime.
Untuk itu kami membuat sebuah kumpulan kelas statik yang menyimpan konstanta-konstanta yang kami butuhkan untuk menyimpan angka-angka penting yang kami gunakan dalam program, kumpulan kelas statik tersebut kami simpan didalam sebuah file bernama GameSettings. Dengan adanya GameSettings kami dapat dengan mudah mengenali dan bahkan mengubah nilai-nilai saat runtime. Seperti halnya pengaturan antialiasing dan pengaturan FPS yang dapat diubah dan digunakan oleh kelas GameEngine dan SettingsState.