Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (600)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Design Question  (Read 2813 times)
0 Members and 1 Guest are viewing this topic.
Offline dime

Senior Newbie





« Posted 2010-09-07 12:22:35 »


Right now I have 3 objects.

Player, Map and Camera.

They all need information from each other. 

For example, player needs to know where he is on the map.
The map needs to know where the player is.
The camera needs to know information from both the map and player.

How would you design this?  Just have a SetMap function for player and SetPlayer function for map, etc?

Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #1 - Posted 2010-09-07 13:15:00 »

I would suggest a review of Model View Controller  patten *in practice*.  Basically you want to avoid too much sharing, but often it can't be avoid without excessive over design IMO. Then how you communicate depends on details.

Sorry, but sometimes it pays just to "hack it up" and see what falls out. Re-factoring later is always an option. Writing code is better than over thinking design IMO, because by *writing* code you understand what problem the design is attempting  to solve better. 

I have no special talents. I am only passionately curious.--Albert Einstein
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #2 - Posted 2010-09-14 04:54:47 »

Oftentimes my MVCs are all singletons, so they can be easily referenced from anywhere. Or, I have a main class that holds references to them, and typically the Model doesn't care about the Controller or the View, but the Controller and View both need the Model. So I instantiate the Model first. Then basically the Controller periodically updates stuff in the Model based on input events, and the View periodically draws everything in the Model. This means a lot of accessors, but it's fairly easy to keep clean and most of the time you can keep things separately encapsulated enough that you're only passing a few objects across.

See my work:
OTC Software
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #3 - Posted 2010-09-14 08:50:32 »

Oftentimes my MVCs are all singletons, so they can be easily referenced from anywhere.
Ugh. People who make MCV out of three singletons shouldn't be allowed to give architectural advice. Tongue

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #4 - Posted 2010-09-14 10:11:55 »

A little OT:

I am one of the "singletons are antipatterns" people. Singletons are the same as  global static variables. Bad.

When i find myself wanting a singleton i ask myself "single with respect to what". Single per JVM (almost never) Single per application instance (not necessarily the same thing), single per thread... etc. It doesn't take long to work out that you don't really want a singleton.

Anyway i use Dependency Injection frameworks now. So i leave the management of how many instances to the glue code.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #5 - Posted 2010-09-14 11:31:49 »

Oftentimes my MVCs are all singletons, so they can be easily referenced from anywhere. Or, I have a main class that holds references to them, and typically the Model doesn't care about the Controller or the View, but the Controller and View both need the Model. So I instantiate the Model first. Then basically the Controller periodically updates stuff in the Model based on input events, and the View periodically draws everything in the Model. This means a lot of accessors, but it's fairly easy to keep clean and most of the time you can keep things separately encapsulated enough that you're only passing a few objects across.

Ew! Tongue

stuff => look at the diagram below.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline tom
« Reply #6 - Posted 2010-09-14 13:04:22 »

Right now I have 3 objects.

Player, Map and Camera.

They all need information from each other. 

For example, player needs to know where he is on the map.
The map needs to know where the player is.
The camera needs to know information from both the map and player.

How would you design this?  Just have a SetMap function for player and SetPlayer function for map, etc?



I would create a Game object that holds the Player, Map, Camera and other shared data. Then pass the game object to everyone. You avoid the problems with singletons and you have only one object you have to send around.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #7 - Posted 2010-09-15 15:28:06 »

Ew! Tongue

What you are describing has nothing to do with MCV MVC. The View must be connected to the Controller and must not know about the Model in any way. Think of the Controller as the accessor to the model. The View knows nothing about logic, it just passes 'stuff' to the controller, which stores/modifies it to pass it to the Model, catching results / exceptions, and passing that feedback to the View so it can adjust itself. The Model can implement the listener-pattern, and the View is allowed to hook directly into it, it therefore can catch events that are asynchronous - please note that the View does not know about the Model, the Model knows about the View.



1  
2  
3  
                     View  <------> Controller ------> Model
                       ^                                 |
                       \________________________________/


Hm, all right. I tend to have a slightly different implementation of MVC every game I make because I wasn't completely clear that there was such a specific distinction. As far as I understood the main point was that one handles input, one handles the program's state, and one handles the output. But it's logical for the "controller" to be the one that delegates communication between the model and the view. I only ever formally learned about MV architectures, so looks like I've been assuming wrong on what the C part does.

As for the singleton thing. I should probably specify that I've been working in Objective-C lately, and for whatever reason that's the way they do it (singletons all over the place) whereas Java just uses static classes. So I've pretty much been following the programming paradigm on the platform I've been working with. And I actually don't usually make the MVC globally accessible, I just do it when I'm being lazy and don't want to access things the right way. I should scale down the singletons, come to think of it. I've started using them everywhere since becoming an iPhone developer...

So don't listen to me. Read these far more educated opinions on the subject. Smiley


See my work:
OTC Software
Offline cylab

JGO Ninja


Medals: 55



« Reply #8 - Posted 2010-09-15 18:03:19 »

Ew! Tongue

What you are describing has nothing to do with MCV MVC. The View must be connected to the Controller and must not know about the Model in any way. Think of the Controller as the accessor to the model. The View knows nothing about logic, it just passes 'stuff' to the controller, which stores/modifies it to pass it to the Model, catching results / exceptions, and passing that feedback to the View so it can adjust itself. The Model can implement the listener-pattern, and the View is allowed to hook directly into it, it therefore can catch events that are asynchronous - please note that the View does not know about the Model, the Model knows about the View.



1  
2  
3  
                     View  <------> Controller ------> Model
                       ^                                 |
                       \________________________________/


Ew... what???

You make fun of Eli, dont you? His description was quite right. The Model must not have any idea of a View (to allow for different or multiple Views of the data), but a View holds a reference of a Model to know what to display. Every modification to the Model is done through the Controller (usually in response to some events or messages), but the Controller does not wrap the Model or something.

Mathias - I Know What [you] Did Last Summer!
Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #9 - Posted 2010-09-15 18:10:37 »

hence why i said go and look at this *in practice*. Real code just doesn't map to simplistic "this is the best way to do it".  Its also just coding something up is a good idea. Working code is better than a non working "perfect" design... that once you start implementing you realize is useless for your particular problem.

I have no special talents. I am only passionately curious.--Albert Einstein
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline dime

Senior Newbie





« Reply #10 - Posted 2010-09-15 18:40:20 »

hence why i said go and look at this *in practice*. Real code just doesn't map to simplistic "this is the best way to do it".  Its also just coding something up is a good idea. Working code is better than a non working "perfect" design... that once you start implementing you realize is useless for your particular problem.

Have any open source examples of largish Java games that are code "right"?
Offline Nate

« JGO Bitwise Duke »


Medals: 158
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #11 - Posted 2010-09-15 21:31:08 »

Have any open source examples of largish Java games that are code "right"?

He is saying is that you need to adapt to the problem you are solving, which will likely be different for each project.

I agree with delt0r. Strict MVC in generally can cause more problems than it solves. It is most useful when you have multiple views for the same model. If you aren't doing that, it probably isn't worth the trouble. If whatever bastardization of MVC you implement can't support two completely different views of the same model, then you aren't doing MVC.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #12 - Posted 2010-09-16 07:16:34 »

Have any open source examples of largish Java games that are code "right"?


This is how I do it (when I'm not using singletons! Tongue), although it's not the way Riven said to do it. Works fine for me.
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
public class Main
{
    private Controller controller;
    private Model model;
    private View view;

    public Main()
    {
        model = new Model();
        controller = new Controller(model);
        view = new View(model);
    }

    public void gameLoop()
    {
        while(running)
        {
                controller.update();
                model.update();
                view.draw();
        }
    }
}

public class Controller
{
    private Model model;

    public Controller(Model theModel)
    {
        model = theModel;
    }

    public void update()
    {
        for (int i = 0; i < inputEvents.size(); i++)
        {
            model.setSomething(someValue);
        }
    }
}

public class View
{
    private Model model;

    public View(Model theModel)
    {
        model = theModel;
    }

    public void draw()
    {
        model.getBackground().draw();

        for (int i = 0; i < model.getStuff(); i++)
        {
            model.getStuff().get(i).draw();
        }
    }
}
public class Model
{
    private World world;
    private CoolGameStuff stuff;
    private GameState state;

    public Model()
    {
        //boop boop
    }

    public void update()
    {
        world.doPhysicsAndStuff();
        state.update();
        stuff.doYourThing();
    }
}


So unlike what Riven was saying I make the Model the only class that doesn't know about anything else, whereas the view and controller both know about the model. The controller knows how to update the model from input events, and the view knows how to show the model's current state. This approach has always remained very clean for me because all of the actual game always ends up in the model, safe from the potential confusion of having nested input events and the like. Also, it makes it very easy to have multiple views and/or multiple input sources.

See my work:
OTC Software
Offline cylab

JGO Ninja


Medals: 55



« Reply #13 - Posted 2010-09-16 10:28:28 »

@Eli
In strict MVC you would move the model.update() stuff to controller.update(), so that the model doesn't have any logic in it. It just stores the games state for the current timestep and maybe knows how to load and save itself. What you do is more like a separation of the display logic from the game with your controller being a simple input manager. I wouldn't call it MVC, but this design is fine however for most use cases.

Mathias - I Know What [you] Did Last Summer!
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #14 - Posted 2010-09-16 11:55:36 »

Ew... what???

You make fun of Eli, dont you? His description was quite right. The Model must not have any idea of a View (to allow for different or multiple Views of the data), but a View holds a reference of a Model to know what to display. Every modification to the Model is done through the Controller (usually in response to some events or messages), but the Controller does not wrap the Model or something.

Eli's description is (with all respect) very far from what defines MVC. Sure, people mis-implement is all over the place, but that doesn't make it right.

Please read the official documentation (http://java.sun.com/blueprints/patterns/MVC-detailed.html) of the MVC model, not that wikipedia crap. The Model is allowed to have listeners, and the View is encouraged to be such a listener. The Model doesn't *know* about the View, it notifies listeners (possibly the View) of events.

Click to Play

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Online princec

« JGO Spiffy Duke »


Medals: 429
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2010-09-16 14:24:32 »

Something frequently glossed over in this fairly naive view of MVC is that the view itself may maintain an intermediary model which it uses for rendering, and may well pull together several Models (eg. a JList will use a ListSelectionModel and a ListModel). The best way to think about it is to apply this restriction: the "Model" should have no information to do with rendering at all - it should all be abstract state, with no knowledge of whether something is visible, where it's displayed, or what colour it might be. The job of the View is to notice changes to its Models and adjust its internal representations accordingly in order to accurately render itself.

The same principle applies to games.

My game state consists of, for example, a list of gidrahs. The gidrahs are not renderable. They maintain references to Sprites, and those Sprites themselves aren't actually renderable, they're just little models. There's a SpriteEngine that actually looks at Sprites and builds the actual data structures used to render the scene - that's the View here. And so on.

Cas Smiley

Offline cylab

JGO Ninja


Medals: 55



« Reply #16 - Posted 2010-09-17 08:55:42 »

Eli's description is (with all respect) very far from what defines MVC. Sure, people mis-implement is all over the place, but that doesn't make it right.

Please read the official documentation (http://java.sun.com/blueprints/patterns/MVC-detailed.html) of the MVC model, not that wikipedia crap. The Model is allowed to have listeners, and the View is encouraged to be such a listener. The Model doesn't *know* about the View, it notifies listeners (possibly the View) of events.

Click to Play


I was refering to the fact, that Eli described the interaction of the three components correctly and you don't.

Quote from: Eli
(...) typically the Model doesn't care about the Controller or the View, but the Controller and View both need the Model. (...) Then basically the Controller (...) updates stuff in the Model.

which more or less correctly describes the roles of the components, while

Quote from: Riven
The View must be connected to the Controller and must not know about the Model in any way. Think of the Controller as the accessor to the model. (...) please note that the View does not know about the Model, the Model knows about the View.

is either wrong or misunderstandable. Take a look at the diagram you linked - the View *must* know the Model to know what to display (doing the "sate query") and the Controller is no accessor to the Model at least not in a wrapping fashion (like your statements seem to suggest to me). Also the Model does not know the View, at least not interface wise. It may "know" the View because it is hooked as a Listener, but that doesn't make the View and its functionality available to the Model (again like your statements seem to suggest to me).

Quote from: Riven
Please read the official documentation (http://java.sun.com/blueprints/patterns/MVC-detailed.html) of the MVC model, not that wikipedia crap.

My experience of the MVC pattern come from daily work with multiple languages, frameworks and application setups - not from Wikipedia. Also I doubt that Sun is the originator of the MVC pattern so the term "official documentation" might be a bit exaggeratory. 

You are right about the misimplementations, though. There are myriads of (mostly web-) frameworks out there, that state they implement MVC but doing only something vaguely related...

Mathias - I Know What [you] Did Last Summer!
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #17 - Posted 2010-09-17 09:15:54 »

Also the Model does not know the View, at least not interface wise. It may "know" the View because it is hooked as a Listener, but that doesn't make the View and its functionality available to the Model (again like your statements seem to suggest to me).

The Model is allowed to have listeners, and the View is encouraged to be such a listener. The Model doesn't *know* about the View, it notifies listeners (possibly the View) of events.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline cylab

JGO Ninja


Medals: 55



« Reply #18 - Posted 2010-09-17 09:47:48 »

Yep, I see. I just wanted to explain what I understood from your first post.

Mathias - I Know What [you] Did Last Summer!
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #19 - Posted 2010-09-17 15:14:01 »

This is all interesting, but I'm curious how many of you use strict MVC for games? One reason I don't think it makes too much sense to have the model notifying of the view of changes via a listener is because in a game setup you will typically have separate timing for rendering and updating - therefore it makes more sense for the view to pull the current state from the model whenever it happens to be rendering.

As for putting all game logic in a Controller... I suppose that means that the game loop and the like are in the controller, and they update everything? That seems like it's also a pain in games, because I like having an update() function in every Entity where it knows how to update itself. It seems like in true MVC you'd have to only store the current Entity data in one class, then somewhere else have the update() function.

Seems like in a game context it's more of a pain than it's worth.

See my work:
OTC Software
Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #20 - Posted 2010-09-17 15:37:50 »

Yesterday I went through a lot of my code to see how strictly I do follow MVC. To my surprise I stick to the strict definition every time. Well ok the controller is often an inner class to the view. Its wasn't my discipline of adhering to patterns that did this. Its the fact that i want my models to be clean. Change notification is generally done with a call back. But often I "make" the view poll for changes. but the view does query the model often, as per the picture. 

My game is the same. I have a game model that knows nothing about rendering or opengl at all. It can be queried by the view to determine what to draw.

However i often have a lot of model logic in my models. I am not really a fan of data only objects per say. But this does not invalidate the MVC .. it would if i had *view* dependent logic in the model.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #21 - Posted 2010-09-17 15:44:47 »

Yesterday I went through a lot of my code to see how strictly I do follow MVC. To my surprise I stick to the strict definition every time. Well ok the controller is often an inner class to the view. Its wasn't my discipline of adhering to patterns that did this. Its the fact that i want my models to be clean. Change notification is generally done with a call back. But often I "make" the view poll for changes. but the view does query the model often, as per the picture. 

My game is the same. I have a game model that knows nothing about rendering or opengl at all. It can be queried by the view to determine what to draw.

However i often have a lot of model logic in my models. I am not really a fan of data only objects per say. But this does not invalidate the MVC .. it would if i had *view* dependent logic in the model.

So you would never do this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
public class Entity
{
    public void update()
    {
        //Do logic stuff
    }

    public void draw()
    {
        SpriteManager.getSprite(mySpriteName).draw(x, y, width, height);
    }
}

public class View()
{
    public void draw()
    {
        for (int i = 0; i < model.getEntities().size(); i++)
        {
            model.getEntities().get(i).draw();
        }
    }
}

public class Model()
{
    public void update()
    {
        for (int i = 0; i < getEntities().size(); i++)
        {
            getEntities().get(i).update();
        }
    }
}


I end up having both the rendering and the logic update code within the Entity object, but the Model never calls draw() and the View never calls update(). Do you do something like have some other class do the Sprite draw call, and maybe get the sprite name, position, etc. from the Entity with accessors?

See my work:
OTC Software
Offline delt0r

JGO Knight


Medals: 30
Exp: 18 years


Computers can do that?


« Reply #22 - Posted 2010-09-17 16:04:49 »

No I would not. In my case Entity is part of the model (the model is a "entity" collection). The controller in my case is either a AI bot (called a borgatron --cus bot is boring), a "network" controller, or a "gui" controller.

The view would querry (in a thread safe manner) the model about, the list of entitys. This list is just data. ie postions, and type. The view know how to get a 3d model from the type, then draws it at x,y,z. It does *not* delegate drawing to the entity.

Now if i run a dedicated server I don't need *any* of the opengl data at all. I can plug in borgs or network players at will and there is just lots of general goodness.

My implementation is more complicated in reality. But not as far as MVC goes. I just do things like interpolate entity states for smooth animation, and a way to decouple game turns from animation frames. 

I have no special talents. I am only passionately curious.--Albert Einstein
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #23 - Posted 2010-09-17 20:43:42 »

That's a very clear and useful way of putting it, thanks. And yeah, if you're looking to have AI / networked / local control options, that is absolutely the best way of doing things. I will definitely borrow some of these concepts in the future. Typically for AIs I was making a subclass of Entity and overriding the update() method with AI choices. Definitely some big disadvantages to this, obviously.

See my work:
OTC Software
Offline cylab

JGO Ninja


Medals: 55



« Reply #24 - Posted 2010-09-18 16:42:47 »

In strict MVC you would move the model.update() stuff to controller.update(), so that the model doesn't have any logic in it. It just stores the games state for the current timestep and maybe knows how to load and save itself

As for putting all game logic in a Controller... I suppose that means that the game loop and the like are in the controller, and they update everything? That seems like it's also a pain in games, because I like having an update() function in every Entity where it knows how to update itself.

I have to correct myself here. This is only true, if you only consider your game state the model. But you can "model" anything you want. Data structures, behaviour, physics etc. So if you want your Model to also contain behaviour information, its OK to implement like you did.

You might want to separate behaviour from your Entities in some kind of "Behaviour (Sub)model" to reuse behaviour schemes for multiple Entities, though. Those are however not used from the View but usually applied to the Entities directly, so they might not fall into consideration when talking about MVC.

I don't think it makes too much sense to have the model notifying of the view of changes via a listener is because in a game setup you will typically have separate timing for rendering and updating - therefore it makes more sense for the view to pull the current state from the model whenever it happens to be rendering.

I also don't think that asynchronous change notification is the essential ingredient to make a design an MVC implementation. A View can (and does) render a Model for various reasons and not only on change notification. So driving the rendering from the game loop does not break any MVC paradigma.

Mathias - I Know What [you] Did Last Summer!
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (28 views)
2014-12-15 09:26:44

Mr.CodeIt (19 views)
2014-12-14 19:50:38

BurntPizza (35 views)
2014-12-09 22:41:13

BurntPizza (70 views)
2014-12-08 04:46:31

JscottyBieshaar (32 views)
2014-12-05 12:39:02

SHC (44 views)
2014-12-03 16:27:13

CopyableCougar4 (40 views)
2014-11-29 21:32:03

toopeicgaming1999 (108 views)
2014-11-26 15:22:04

toopeicgaming1999 (94 views)
2014-11-26 15:20:36

toopeicgaming1999 (29 views)
2014-11-26 15:20:08
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!