Real Software Forums

The forum for Real Studio and other Real Software products.
[ REAL Software Website | Board Index ]
It is currently Fri Jul 28, 2017 9:51 am
xojo

All times are UTC - 5 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Fundamental Game Structure
PostPosted: Fri Apr 20, 2012 1:24 pm 
Offline
User avatar

Joined: Mon Nov 29, 2010 7:01 pm
Posts: 446
I've made a variety of games in the past, and I know how to get the job done. But overall I've accomplished this in less than elegant ways.

Everywhere I look for resources online, they fail to provide what I'm looking.
I know how to program,
I have the software I need,
I understand what makes a balanced game,
etc...

What I'm looking for is a general structure for how a game should be coded with graphics, animation, and sound.
I understand that if you are making a card game you might have something like
Card - Suit, Value
Player - Cards(), Name, Score
Game - Players(), Deck, Turn
etc....

What I really want to know is what the best methodology for taking the Model above and returning that as media to the user.

So let's say I display a character on screen. The character and other objects needs to animate in place in some cycle on the screen. They may need to change this looped animation based on some condition, they also may need to animate a series of actions. Some of these actions may also cause sound.

Do I have an Animation Module and a Sound module to keep up with these? Do I use key frames? I know there are a million ways to get the job done but is there some sort of standard way game developers go about this? I want to make a highly re-useable game-class that takes care of all the sound and animation and I want to set it up right.

Ideas? Resources?


Top
 Profile  
Reply with quote  
 Post subject: Re: Fundamental Game Structure
PostPosted: Fri Apr 20, 2012 1:32 pm 
Offline
User avatar

Joined: Sun Aug 05, 2007 10:46 am
Posts: 4931
Location: San Diego, CA
in a word CLASSES

Take for example your "card game" (I have this exact structure)

A Class that defines a CARD.... this class contains its value (rank, suit), method to return those, as well as color (black, red), it contains methods that know how to DRAW the card.... basically everything that defines a playing card is encapsulated in this class

Then I have another Class "Deck". this class contains an array of "CARD" classes, methods to control shuffling, "dealing" the next card in the deck etc.

Once those two classes are defined.... you no longer have to worry about the mechanics of dealing, shuffling, displaying cards etc etc. Now you build the game engine.. Same methodology applies to any other game (or any program for that matter)

_________________
Dave Sisemore
iMac I7[2012], OSX Mountain Lion 10.8.3 RB2012r2.1
Note : I am not interested in any solutions that involve custom Plug-ins of any kind


Top
 Profile  
Reply with quote  
 Post subject: Re: Fundamental Game Structure
PostPosted: Fri Apr 20, 2012 1:37 pm 
Offline
User avatar

Joined: Mon Nov 29, 2010 7:01 pm
Posts: 446
DaveS wrote:
in a word CLASSES

Take for example your "card game" (I have this exact structure)

A Class that defines a CARD.... this class contains its value (rank, suit), method to return those, as well as color (black, red), it contains methods that know how to DRAW the card.... basically everything that defines a playing card is encapsulated in this class

Then I have another Class "Deck". this class contains an array of "CARD" classes, methods to control shuffling, "dealing" the next card in the deck etc.

Once those two classes are defined.... you no longer have to worry about the mechanics of dealing, shuffling, displaying cards etc etc. Now you build the game engine.. Same methodology applies to any other game (or any program for that matter)


I think you missed what I was asking. I understand how to make a card game. I understand all the classes and methods that would be involved. What I want is a fundamental class that could take said instance of a "game" and relay it to the user with sounds and animations.

I want the Model of the game to separate from the View of the game. A card class should most definitely not know how to draw itself. The controller should be able to take the model and given a card, know how to draw it.


Top
 Profile  
Reply with quote  
 Post subject: Re: Fundamental Game Structure
PostPosted: Fri Apr 20, 2012 1:42 pm 
Offline
User avatar

Joined: Sun Aug 05, 2007 10:46 am
Posts: 4931
Location: San Diego, CA
ok.... I will agree to totally disagree with you....

_________________
Dave Sisemore
iMac I7[2012], OSX Mountain Lion 10.8.3 RB2012r2.1
Note : I am not interested in any solutions that involve custom Plug-ins of any kind


Top
 Profile  
Reply with quote  
 Post subject: Re: Fundamental Game Structure
PostPosted: Fri Apr 20, 2012 1:47 pm 
Offline
User avatar

Joined: Mon Nov 29, 2010 7:01 pm
Posts: 446
DaveS wrote:
ok.... I will agree to totally disagree with you....


I've been reading up on MVC(ModelViewController) design implementation, which is a necessity especially in iOS development. It allows high-reusability, ease of debugging, quick modifications.

Essentially a card might have a graphic property. But let's say I have the cards shimmer every few seconds. The controller should be doing this shimmer to the View and it should have nothing to do with the card class itself.

This way if I change how I want the UI to act or what it should look like, nothing in the card class changes. The controller just changes how it has to view draw/animate the card.

Also lets say I have a desktop version, phone version, tablet version. I wouldn't (and shouldn't) need to edit the card class. It should fundamentally be the same across all of the versions. The only thing that changes is how my Controller decides to relay that information back to the user based on their hardware for example.


Top
 Profile  
Reply with quote  
 Post subject: Re: Fundamental Game Structure
PostPosted: Fri Apr 20, 2012 8:04 pm 
Offline
User avatar

Joined: Thu Feb 16, 2006 10:04 pm
Posts: 262
The MVC design pattern is something that Apple has embraced in a big way for sure. It's not a necessity per se, but it's something Apple suggests. Your comments about reusability, etc. are only half true really. The MVC pattern is not a magic bullet. One of the reasons Apple embraces this pattern is it meshes nicely with their selected language of choice, Obj-C. In a broad sense, it is difficult to get a MVC pattern using the Realbasic language. It's at times not a very good fit of pattern and language.

Game architecture is tricky. I'd suggest a search on Amazon for some book titles to read up on the subject. So, should you give up on the MVC pattern in Rb? No, not at all. But you shouldn't rely on it either. You will most likely end up with a blend of patterns that suit your needs and coding style because Rb doesn't use the same messaging of events and methods as Obj-C.

One excellent lecture on the MVC pattern is http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=473757255. Look for the MVC lecture and pdf notes. And despite that being an Xcode/Obj-C series, it's a flat out excellent computer sciences course that can certainly be applied in Rb.

_________________
Thomas C.
Real Studio Blog
http://bigdaddysurf.com/blog/

https://itunes.apple.com/us/app/maui-dragstrip-2013/id604516033?mt=8
https://itunes.apple.com/us/book/how-to-waterstart/id576214730?mt=11


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 5 hours


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group