• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to control the flow of my program?

 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In Microedition, I'm using only one Canvas to display graphics
and Keypressed method to read keyboard inputs.

I want to use something like this to control the flow of a game:
But I'm not quite sure about where to put this code to take control of the flow,
since Keypressed & repaint() methods are likely to be outside this control.

Can someone, perhaps, suggest how to manage the flow of the program as I'm trying above?
 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What you need to do is discern a way to separate your View (the drawing process) from the Model (the game state and logic). Make classes that perform all the logic you want to implement. Then create some shared set of classes where it stores the results of your Model logic.

Then just simply rewrite you View (drawing classes) to access the shared ones. Now you have decoupled the View from the Model. A classic example of this is using a Design Pattern called The Mediator. If you google Mediator Pattern you will find plenty of tutorials on how to adapt your code to this concept. It's fairly straightforward.

A word of caution. After you have had a chance to study the mediator concept ... you'll find it tempting to stuff all your "middle-man" code into ONE class. If you do, you might as well title the class as =P

Make every attempt to divide the in-between logic into multiple mediator classes so that it will be easier for you to debug and make changes that won't cascade (i.e changes that require you to make more changes to existing code that is already working)
 
Sergio Campos J.
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, Mr. Cox!
This seems to be what I need to learn about to step forward.
(I was a little worried about the english barrier to express my doubts)
I'll google Mediator Pattern to find out about this interesting concept.
 
reply
    Bookmark Topic Watch Topic
  • New Topic