Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (517)
Games in Android Showcase (123)
games submitted by our members
Games in WIP (577)
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  
  MVC pattern  (Read 5294 times)
0 Members and 1 Guest are viewing this topic.
Offline MChester

Junior Newbie




Java games rock!


« Posted 2004-03-02 07:36:35 »

Comming from a business software background, I've been using the model-view-controller pattern alot. I am doing a little hobby project diablo style game wannabee and started out designing the model and the view seperately. This allowed me to not worry about collisions but also means that the scenegraph (the view) and the model must both be updated.

I was just wondering about how others are architecting their software?

I also read an article on slashdot last week by a "professional" game developer i the industry and it seemed like they dont architect their code at all and only has focus on 3D speed and effects.

My thoughts are that if I wanted to build a robust game engine I should build one that i very loosely coupled...

any comments anyone?

Michael
Offline kevglass

JGO Kernel


Medals: 191
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2004-03-02 07:40:08 »

I pretty much stick to Model/View split. It helps when writing server/client interactions. In addition helps when you want to do a 2D, Isometric and 3D version of your game.. Smiley

Kev

Offline MChester

Junior Newbie




Java games rock!


« Reply #2 - Posted 2004-03-02 08:45:48 »

Hi Kev

Just my thoughts. By seperating the model and view I can always upgrade the look and feel later when I get better at 3D while still having fun playing my game.

Michael
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline moonpxi

Senior Newbie




Java games rock indeed!!!


« Reply #3 - Posted 2004-03-02 20:33:58 »

Out of my apparent cluebieness, would you mind giving me a short example of your MVC modeling in the game??

I am actually aware of the MVC patern, which I find it very interesting and am trying to follow it to my best. However I am still curious of how others envision its use in a game.

Thanks, and forgive my newbiness...  Tongue

Moon Pxi, a NerdCorper
Offline kevglass

JGO Kernel


Medals: 191
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #4 - Posted 2004-03-02 20:43:13 »

Say you're writing a space game, you know Elite style in space, you're entities are maybe:

Ship.java
SpaceStation.java
Planet.java

Each of these entities will have data about them, their position, orientation and velocity maybe. In these classes you store these are pure data.

Then in your rendering layer you might implement:

Ship3D.java
SpaceStation3D.java
Planet3D.java

Each of these knows how to render the appropriate 3d geometry for the assocaited data object. Each object holds a reference to a data element. They are responsible for adjust the geometry as the data objects change.

Note however the data objects are responsible for detecting collisions and such. So the "View" is dependant on the "Model" but not vice vesa.

So now, say you come to write a server for multiplayer version of your space game. You can run the data model on the server, sync it via the network with the data model on the client. The View doesn't know anything about this it just continues to work as tho the data model is fine.

Now you've got your 3D networked version working but you now want to implement a 2D version. You implement a new View which is dependant on the data model and everything else gets reused (the collision, the data model, the network code).

Kev

Offline bmyers

Junior Duke





« Reply #5 - Posted 2004-03-10 15:48:33 »

In my approach, I actually use a more strict separation of Model and controller, in addition to View.  Model is pure data, plain and simple.  Controller objects load the model with data (from database or file or network or wherever) and also save it when needed.  View objects are responsible for rendering the Model objects (in 2D, 3D, 2.5D, HTML, or whatever).

Also, for a particular GUI platform (2D vs 3D vs cellphone for example), there are platform-controllers that handle input for the GUI and feed it to the rendered View.  So, for example, keyboard input, mouse input, joystick input, phone buttons, network messages, etc. all feed the View, and the View doesn't care where the input comes from.

I must admit, this creates a lot more classes in your object tree, and is arguably more work, but it adds flexibility to the design, and (for us) will make it much easier to support multiple platforms for our MMP game.

As a side note, having worked as a commercial game developer, I think the advantages of approaching a game architecture this way will start to outweigh the benefits of tweaking the rendering.  As graphics hardware continues to improve, the ability to get an extra frame or two per second, or the ability to get an extra hundred (or thousand) polygons rendered will be irrelevant, and the ability to build reusable architectures to reduce development time and cost will become more important, along with better story and more interesting gameplay.  

Offline gangrel-br

Junior Duke




Java and Scala! Thats the game =)


« Reply #6 - Posted 2004-09-29 01:21:01 »

I'm trying to follow the MVC pattern, but I'm not sure if I am in the correct way...

I have, say, an IsometricMap, divided in two classes: IsometricMapModel and IsometricMapView. A map is composed by MapCells, that are also separated in model and view classes, and each map cells contains Tiles (also with model and view).

My question is: Am I just complicating things or is this the way to go?  Huh

Paulo "JCranky" Siqueira
Offline snak

Senior Newbie




Eu não falo o português


« Reply #7 - Posted 2004-10-01 14:46:52 »

My first cent - never forget that the purpose of all these software design patterns is to make life easier for the people actually writing and maintaining the code.  They aren't for performance, or for software correctness, etc.  If you're working on a solo project, use the patterns in whatever way makes the most sense to you.

Second cent - I've been using a pattern like this lately, which is MVC-derived and pretty useful.  I have four types of classes - Game Objects (Model), Renderers (View), Managers (Controller - pt 1), and Controllers (Controller - pt 2).  

Game Objects for the most part are just data structures.  I usually have one class of these per entity in my world - in my case characters, towns, dungeons, etc.  Getters and setters abound

I typically have one renderer for each 'screen' - so one for the menu, one for drawing the 'in town' display, one for drawing the 'world map', etc.  Renderers just takes a list of relevant game objects and draws them to the screen.  They have logic, but it's all focused on rendering - culling, etc.  Right now I just have renderers running in their own thread, but you could synchronize them with the game loop.  Renderers may have data structures that parallel Game Objects (such as vertex data), but I try not to put that data into the Game Objects themselves.

Managers conceptually should contain all the game logic.  Lately I've been orienting these around game states - which correspond to screens - same as renderers.  There is one master manager that keeps track of game state and calls an update method on any active 'children' managers.  

What I call 'Controllers' are assigned to any autonomous entities in the game world, and are responsible for choosing actions for the entity they represent.  So the player's Game Object, and any monsters or NPC's are each assigned a Controller.  Controllers are responsible for querying the world around their assigned entity, formulating a good action, and returning that to whichever Manager class is asking for an action.  Controllers have no ability to update the world - they just return instructions to a manager class such as 'Walk North' or 'Open Door'.  The manager class is responsible for checking the validity of this instruction and actually moving the game object or opening the door.  

There is one special controller for the player that basically maps keyboard and mouse events to instructions in the controller 'instruction set', which may be returned to a manager class.  If you're making a turn based game, you have the player controller stall until the user enters an action.  If you're making a real time game, you have the player controller just return NOOP if the player isn't pressing a button or whatever.

So the basic idea is that you have all these Game Objects that represent the things in your world.  Alone these objects don't do anything.  You add on top renderers that show a list of game objects.  The list of game objects they display may be limited by a manager class (to eliminate nearby but hidden enemies for example).  You add on top of this a layer of manager classes which are responsible for updating the game state (Game Objects).  Finally, controllers are responsible for *suggesting* to the manager classes how to update the game world.

Anyway, that's the architecture I've been using lately.  I've found this model very flexible and easy to extend.  Let's say I want to add gravity to my world - that belongs in the manager class ONLY.  I may choose to enhance a controller class to compensate for gravity, but that's an independant chunk of work.  Let's say I want to improve pathfinding - I add that to a controller class.  If I want to switch to a different rendering engine, I swap out the renderer class for the relevant game state(s).  If I want to make the game network enabled, I just create a new proxy controller class which communicates across to some client over the network (which is of course not at all a trivial task).
Offline gangrel-br

Junior Duke




Java and Scala! Thats the game =)


« Reply #8 - Posted 2004-10-01 21:29:14 »

Quote
never forget that the purpose of all these software design patterns is to make life easier for the people actually writing and maintaining the code.  They aren't for performance, or for software correctness, etc.  If you're working on a solo project, use the patterns in whatever way makes the most sense to you.


Yep, that what I'm aiming at: to make the code easy to maintain (I what it to be easy to add / modify features). I'm just not sure I'm on the right way.

Your architecture is very interesting (somewhat similar to mine, but a little more complex and complete). But it might get difficult for new developers to understand it - unless it is documented. How do you do it?  
Huh

Paulo "JCranky" Siqueira
Offline snak

Senior Newbie




Eu não falo o português


« Reply #9 - Posted 2004-10-05 15:42:38 »

In my case, I'm the only developer, so no communication problem.  In general, I find that if you can establish one sensible, robust pattern, and then use that over and over again, your system will be pretty easy to get around for new coders - once they understand the major pattern you're using.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #10 - Posted 2004-10-07 09:27:06 »

Quote

But it might get difficult for new developers to understand it - unless it is documented. How do you do it?  
Huh


Javadoc is your friend.  If you use JBuilder or Eclipse, they can automatically start the Javadoc comments for you.  Then you can fill in the details.  Also, writing a quick 1 or 2 lines about a method or class will make you think about what you are doing, so you have a better chance of doing it right the first time.  If you do it while you are coding, you will get into the habit.  If you wait until the end, you will never do it.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #11 - Posted 2004-10-07 10:55:35 »

Quote


Javadoc is your friend.  


...but not a subsitute for documentation. Javadoc is only a reference manual, not a developer-guide. If you are going to "customize" or ignore patterns, you need developer-guide levels of explanation if other people are to be able to work with it.

malloc will be first against the wall when the revolution comes...
Offline gangrel-br

Junior Duke




Java and Scala! Thats the game =)


« Reply #12 - Posted 2004-10-09 17:38:27 »

Quote
...but not a subsitute for documentation. Javadoc is only a reference manual, not a developer-guide. If you are going to "customize" or ignore patterns, you need developer-guide levels of explanation if other people are to be able to work with it.


That's exactly the point. I'm not concerned with Javadoc, they are easy to do and I'm already doing it with no problems. What I'm thinking about is a higher level of documentation, the one that can help you understand the game architecture without having to read the source of a 100 classes.

Paulo "JCranky" Siqueira
8: Undefined index: online
File: /home/jgo/public_html/Themes/default/Display.template.php (main sub template - eval?)
Line: 161