MVC programming [solved]

[felixwatts]

Glad to help

[Zthun]

Just as a note, when doing MVC, you have your model of the application, your views where your UI goes, and your controllers which act as the gateways between the two layers - containing all the logic that gets them to work together. The model should know nothing about your view, and likewise, the view should know nothing about your model. The view should only know how to draw itself given it's appropriate actors/groups/widgets/elements/etc, and the model should hold the state of the application.

With games, however, you have another layer - sound. Sound can be separated as well, since it would be very difficult to test things with sound in them - your unit/integration tests would be very noisy. So I would separate this layer as well. I guess you could call it the MVSC pattern but that doesn't matter. Again, the controller would be responsible for playing sounds upon player input.

[wmdAndrew]

This post may also help people looking into data patterns in games:

http://www.badlogicgames.com/forum/viewtopic.php?f=15&t=3715

[djgriff]

Thanks for the input and the link.

I haven't had experience with the IEventHandler! yes newbie here, i have tried to extend the EventHandler expecting it to be an java API.

So what info would i store in the EventHandler?

sorry if this sounds stupid.. just not sure what i would be calling with in this class.. would it be input controller listeners?

Thanks

Daniel

[felixwatts]

IEventHandler is a simple interface I made up that has one method:

void onEvent(int eventType, Object arg)

I'm from a C# background where the convention is to begin interface names with an 'I'. Maybe there is already a similar interface in the java api which you could use instead. Basically any object can implement IEventHandler by just having that one method. Then that object, whatever it is, can be used to handle event s of the model.

The reason I'm using that interface is so that the model has a way to tell the outside world when something important has happened inside it, without it having to know anything about the outside world. I could have passed the Game object into the constructor of the Model, then the model could still have called onEvent on the Game object as it does now. But that would have introduced a dependency on the Game object, which is specfically a LibGDX thing. If later I wanted to port to another framework I would have to change my model to remove the reference to Game. By using a simple interface then I don't have to change the model to port to a different framework, all I have to do is implement one method in my new framework (onEvent) and pass that into the model instead. Interfaces are brilliant!

[djgriff]

Cheers for clearing that up, makes sense now.

Cheers Felix

Best

Daniel

[djgriff]

IEventHandler is a simple interface I made up that has one method:

void onEvent(int eventType, Object arg)

I'm from a C# background where the convention is to begin interface names with an 'I'. Maybe there is already a similar interface in the java api which you could use instead. Basically any object can implement IEventHandler by just having that one method. Then that object, whatever it is, can be used to handle event s of the model.

The reason I'm using that interface is so that the model has a way to tell the outside world when something important has happened inside it, without it having to know anything about the outside world. I could have passed the Game object into the constructor of the Model, then the model could still have called onEvent on the Game object as it does now. But that would have introduced a dependency on the Game object, which is specfically a LibGDX thing. If later I wanted to port to another framework I would have to change my model to remove the reference to Game. By using a simple interface then I don't have to change the model to port to a different framework, all I have to do is implement one method in my new framework (onEvent) and pass that into the model instead. Interfaces are brilliant!

Hi Felix,

please excuse me if this comes across as a dull question.

With your call in the Model class you have the Array<ientity> getEntities(){ }.. Is this where you would place objects like boat.class, fish.class for instance, sorry can't think of the correct termanology right this moment.. basically placing the models into the Main Model class.

Hope this makes sense.

Cheers

Daniel

[felixwatts]

Yes. In this setup, the model contains a list of entities. Each entity is an object representing a thing in the game world such as a ship or whatever. So you might have a Ship class that would implement the IEntity interface. You can put whatever methods you like in the IEntity interface, anything you need all your entities to support. For example you might want to put an update() method in your IEntity interface. Then your model class can iterate through the entities in the list and execute the update() method on each to update them.

Entities can be added to and removed from the entities list at any time to reflect things appearing and disappearing in the game world. For example when a ship gets hit by a bullet you might want to remove the ship object from the entities list and add some kind of explosion entity.

Hope that's clear.

[djgriff]

Hi Felix, thanks for the reply that clears it up for me.. many thanks
Cheers