tags:

views:

95

answers:

1

Hello! I'm on my way with my first game, all design and that stuff are done, just coding left. I have successfully watched tutorials around the world wide web with information about Graphics and how to create a successfully thread-synchronization within it.

Like now I have a SurfaceView-class and a Thread-class. The thread-class have this constructor to receive the Game Engine from my SurfaceView-class. Simple code from Thread-class constructor:

    public Thread(SurfaceHolder localsurfaceHolder,
    Context context,
    Handler handler, 
    SurfacefView localEngine) {

    surfaceHolder = localsurfaceHolder;
    this.handler = handler;
    this.context = context;
    engine = localEngine;
}

From my SurfaceView-class in the surfaceCreated-method:

thread = new GameThread(getHolder(), context, new Handler(), this);

And there is my code that will start trigging the thread when the surface is created.

Now to the real deal. Shortly I want a game engine that is totally separated from the view. The problem is; how to achieve this? How should the GameEngine-class constructor look like and where shall I put the drawing/calculations-methods? What does the GameEngine?

Now my GameEngine-class look like:

package com.myname.mygame;

public class GameEngine {

      //If im right, a constructor for the engine should be placed here
      //How and which parameters shall I change and send with from the view

}

Thanks in advance!

+2  A: 

How should the GameEngine-class constructor look like.

A common pattern is to have a facade class which provides methods to the view. This would be the main controlling class for the UI, so any commands that update the state of the model go through this class. Since you generally only have need for one instance a singleton can be useful here.

public class GameEngine {
    private static GameEngine instance = null;

    private GameEngine(){
       // init stuff here
    }

    public static GameEngine getInstance(){
       if(instance == null){
          instance = new GameEngine();
       }
       return instance;
    }
}

The controlling class would then also pass objects from the core back to the userinterface, which can be accessed via getter methods. I'm not saying this is how you must do it, its just a way of going about things with loose coupling.

where shall I put the drawing/calculations-methods?

Calculations for movement, collisions, AI and stuff I'd put in the model. For drawing stuff that depends. For greater portability and cohesion I'd generally place that stuff in the view.

Have fun.

DrDipshit
Thanks for answer! I understand where I shall place my init-stuff.But the getInstance, is it there just to load things up for the first time, when the instance is null? One thing left, I still don't understand the connection I have to make, in order to trigging and update the objects in the right way. How should I connect my GameEngine for example in the thread-class?
Julian Assange
When you call getInstance() for the first time it runs the constructor for the class once, so any further calls to it just use the existing model. To connect the engine you bascially just call getInstance() from you interface whenever you want to access the model. Or, when you call it the first time you just can store a reference to it in the interface. Hope that makes sense.
DrDipshit
I think I got it now. Then I also just put the necessary calculations/draw-functions in the GameEngine and then in the thread-class i I put for example,GameEngine.getInstance().calculateNow(); to access the GameEngine calculateNow()-method. Right?
Julian Assange
Yeah thats it. Like I said, I'd probably keep the draw routines in the UI for cohesion. Also, if you are going to be calling game engine methods often then its probably best to store a reference to it, as theres a tiny bit overhead to calling it.
DrDipshit
Well cohesion basically means that the tasks performed closely relate to the intended functionality of the class, and the classes in the view are generally responsible for displaying stuff, whereas the model handles the internal mechanics. Also, the draw methods are designed to work with your graphics environment, and tend to have dependancies on it. So say, if you wanted to port your model to use a different graphics library you would not end up having to refactor the code in your model. Storing a reference to the facade saves calling getInstance unnecessarily.
DrDipshit
Accepted! If I also understand this correct, we have stored a reference in your example, right?
Julian Assange
Oh my last comment came above this one for some reason o_O
DrDipshit
Funny, I deleted the previous comment because I got it and your came with an even better explanation! Thank you for this! :-)
Julian Assange
No worries. Good luck with making your game.
DrDipshit
Well, I just wanna tell you that I have worked on this and it is implemented, it works great! I have even create a getInstance-method for the Thread, and a getInstance-method for the Graphics-object, just to make sure the objects are using the existing models. Thank you!
Julian Assange
if you want a detailed example check out the source code for replica island http://code.google.com/p/replicaisland/
schwiz