[kunilkuda]

Gw pengin memisahkan antara rendering logic dan game logic. Ada yang tahu gimana cara misahinnya dalam Model-View-Controller responsibility ?

Berikut adalah beberapa pemikiran gw ttg task dan kategorinya:
1) Init graphic/screen : View
2) Rendering sprite : View
3) Detecting which sprite that user choose : <don't know> (asumsi bahwa ada beberapa sprite yang bisa dipilih oleh user dalam game)
4) Init timer : Controller
5) Update game model : Controller
6) Detecting user input : Controller
7) Play audio : Model
8 ) Collition detection : <don't know>
9) Sprite attributes (image, color, position, speed, etc) : Model

Ada yang bisa kasih ide ?

Thanks
-kunil

[pe-e-be]

eh, ada kunil.. ini kunil BHTV?

[Ultraman_Bastard]

BHTV?? *berpikir keras*

[bhimz]

Actually, several frameworks/language/tools sepertinya sudah menerapkan ini, tinggal gmn cara makenya (what game type/language are we talking about btw?). Mungkin ada baiknya kamu menggali sedikit dokumentasinya.
In response ke pembagian MVC berdasarkan pemikiran u, sepertinya gw lebih setuju kalau dibuat seperti ini:
View: Interface building, Sprite factory, Sound handler, collision detection
Controller: page handler (chaining antar interface), user input handler, game ticker & logic
Model: game attributes, char attributes, collision detection (bisa juga disini, kalau mau dianggep sebagai attribut char), user interface model (model dasar yg dipake buat ngebangun user interface di view)

As for detecting sprite yg digunakan, relevansi itu seharusnya ada di level user interface juga.

[pe-e-be]

hmm, tergantung sih mau game yang seperti apa dulu dan seberapa jauh generalisasi yang diharapkan dari MVC...

klo game yang umum, mungkin begini :
- Model : Level, Scenegraph, Assets, Game AI (mungkin juga bisa dipindah ke controller klo cukup sederhana), Configuration
- View : Renderer, Input Manager, Audio Player, Network Engine
- Controller : Application, Game Screen, Collision, AI (Pathfinding/Rule-based) Engine

[HeapCleaner]

BHTV = Bandung High Tech Valley

[Ultraman_Bastard]

weh.. keren.. ada ya kayak gitu di bandung.. *kapan ada di bali ya??

[ace]

don't judge the book by it's cover

[Kiki]

Menurut saya, kalau mau konsisten dengan paradigma MVC, sprite seharusnya nggak masuk dalam konsiderasi. Sebaiknya dipakai dua buah class : Entity di layer Model dan EntityView di layer View. EntityView harus berhubungan somehow dengan Entity, saya usulkan dengan menggunakan Observer Pattern (EntityView adalah observer dari Entity). Data Dari Entity dan EntityView mungkin diduplikasi, tapi tersinkronisasi oleh mekanisme observer (contoh : Data Rectangle di Entity dan EntityView diduplikasi. akan tetapi ketika data Rectangle di Entity berubah, mungkin karena entity tersebut bergerak, Entity akan menotifikasi perubahan tersebut ke entityview yang akan mengatur data rectanglenya supaya tersinkronisasi dengan rectange milik entity) .

1. Init Graphic/screen : view (obvious)

2. Render Sprite : View -> Ini diganti dengan Render EntityView. tentu saja EntityView "own" sprite supaya bisa menggambar.

3. Detecting which sprite that user choose: ->What about something like this: There's an attribute in Entity that correspond to a "look" in EntityView. Whenever that attribute change, the Entity notifies EntityView thet the attribute changes. In turn, EntityView will change its "look", and as the owner of sprite, will change the sprite to match the "look".

4. Init timer : Controller -> obvious

5. Update game model : Controller ->obvious

6. Detecting user input : Controller -> obvious

7. Play audio : Model :-> why not view ? I do not have a good argument why it should be view, though.

8. Collition detection : -> Ini bisa dilakukan di layer model, contohnya dengan Rectangle yang disebut sebelumnya. Ini adalah salah satu alasan mengapa beberapa data di Model dan View harus di duplikasi dan disinkronisasi.

9. Sprite attributes (image, color, position, speed, etc) : Model -> Make that attribute of Entity. With the Observer mechanism this attribute also available to EntityView, and can be used to render the sprite if necessary.

PS: Actually I do not really care with MVC paradigm

[L_O_J]

@Kiki:
7. Play Audio bisa disamakan dengan render sprite (image), so it's a view, Modelnya ya raw audio data.
8. Collision itu controller kali ya, di Model cuman rectanglenya aja (or pixel data kalo mau pixel perfect collision), sedangkan actual process of detecting it ada di controller.