Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (767)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (854)
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  
  Seperating R, LP, A and I  (Read 3826 times)
0 Members and 1 Guest are viewing this topic.
Offline K.I.L.E.R

Senior Devvie

Java games rock!

« Posted 2004-08-21 10:43:28 »

Logic Processing (heart of the game).

What I do is:

Audio is usually caused by switches(boolean values depicting something occuring like moving into a new area) so that is pretty easy to do.

Rendering, I just have each class contain it's own rendering definitions and then after calling the game processing function I pass the game processing function into the Render class which calls the game class's render method.

Input I just do a couple bool switches which then end up calling the appropriate methods.

An illustration of what I'm talking about.

Is there a better way of doing these things?

I really hate it how a lot of people squash as much as possible into a single class.

Is there a name for a "redneck" programmer?

Unemployed. Wink
Offline gangrel-br

Junior Devvie

Java and Scala! Thats the game =)

« Reply #1 - Posted 2004-08-21 16:49:21 »

Shouldn't Audio and Rendering be more coupled? If they are too separeted, wouldn't we get audio out of sync with the video? Or am I concerned too much for nothing?

Paulo "JCranky" Siqueira
Offline Jacko

Junior Devvie

« Reply #2 - Posted 2004-08-21 21:40:43 »

On the rendering side, one approach is to have a Render Queue. Your loop is basically doLogic, then render(renderQueue).  As you are going through the game logic things can decide if thay are visible and place themselves on the queue.

When you  render, you can sort the objects by render state and transparency and call them back to render themselves.

Have a look at the architecture of Ogre for a good example of this.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline K.I.L.E.R

Senior Devvie

Java games rock!

« Reply #3 - Posted 2004-08-22 03:26:38 »

What am I going to stick into a render queue?

Is there a name for a "redneck" programmer?

Unemployed. Wink
Offline nonnus29

Senior Devvie

Giving Java a second chance after ludumdare fiasco

« Reply #4 - Posted 2004-08-22 11:42:26 »

Something like this maybe?

public class GameObject {
  Mesh mesh;
  void render() {
    if( inFrustum(MyRenderer.getFrustum())

  boolean inFrustum(Frustum f) {...}

public class MyRenderer {
  private static Queue renderQueue;
  private MyRenderer() {}
  public  static MyRenderer getMyRenderer() {}        
  public  static void addRenderQueue(GameObject) {}
  public  static Frustum getFrustum() {}
  public  static void drawAll() {
    //for each item in the queue
  private drawMesh(Mesh) {...}

Offline kevglass

« JGO Spiffy Duke »

Medals: 319
Projects: 25
Exp: 22 years

Coder, Trainee Pixel Artist, Game Reviewer

« Reply #5 - Posted 2004-08-22 12:00:18 »

I think I've ranted on about seperating out the data model and rendering before. Another way to organise things is to keep a model of the actual game world in just pure data. Then run through your Renderable(i/f) objects asking them to render themselfs. They update themselfs based on the data object they represent and decide whether or not to render themselves.

Its worked quite nicely for me in the past, benefits being the ability to change rendering details without worrying about game logic.

Incidently, I've always considered audio as part of the rendering layer since you're rendering stuff its just not visual. Input is always tricky, theres this whole thing about using a controller interface but its never really worked out well for me. I tend to stick in in the main loop although I normally abstract away how the controls are actually being delivered, i.e. keyboard/joypad/etc..


Offline mhale

Senior Newbie

Take pity, I'm just a poor blob!

« Reply #6 - Posted 2004-08-30 22:28:54 »

I have used something like the GAGE sprite interface. I have various sprite classes for all my game objects. My parent sprite class is a composite of a java.awt.geom.Area instance (object geometry for stuff like collision detections) and a renderer instance which the sprite delegates to for rendering. Game object behaviour is determined by the methods in the sprite sub-classes.

I use renderer factories to construct the renderer delegates. At the moment I have two factories, the normal game one and a geometric one. The geometric one renders sprites according to their java.awt.geom.Shape and I use it to debug collision detection.

I have no sound currently and I handle input in the game frame class using boolean switches. Oh, I also went as far to abstract the rendering loop, so I can easily swap in different frame scheduling algorithms.  Grin
Pages: [1]
  ignore  |  Print  

EgonOlsen (1232 views)
2018-06-10 19:43:48

EgonOlsen (1101 views)
2018-06-10 19:43:44

EgonOlsen (842 views)
2018-06-10 19:43:20

DesertCoockie (1251 views)
2018-05-13 18:23:11

nelsongames (1100 views)
2018-04-24 18:15:36

nelsongames (1329 views)
2018-04-24 18:14:32

ivj94 (2068 views)
2018-03-24 14:47:39

ivj94 (1223 views)
2018-03-24 14:46:31

ivj94 (2147 views)
2018-03-24 14:43:53

Solater (787 views)
2018-03-17 05:04:08
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46 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‑
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!