Need VBA Class Guidance

[ROgden]

I've been an Access VBA developer for over a decade, but I'm working on a project and trying to utilize some class modules. You know, just for kicks. However, I'm having a hard time finding the value of incorporating a class for a specific idea, and would like some folks to give me feedback, as to the below.

I've created a functional Monopoly game that allows the fundamental aspects of game play up to landing on a property. I had this handled with modules and functions, but envisioned that creating the methods of the property into a class would be more streamlined. However, it seems that I would have to create the property class, assign all appropriate values to it, then open the 'Property' form and write the values back into the form. Now I'm thinking it was a bit more streamlined just opening the form and writing the particulars into it and skipping the 'middle-man' class.

This is leading me to wonder if there is any benefit from using this class here, or anywhere for that matter.

I think I'm just looking for some concrete feedback about my above idea, and maybe some discussion about correct circumstances where a class is a valid tool for efficiency.

Thanks for any feedback. ~R

 

[Galaxiom]

Well firstly don't call the Class "property" or it will be very confusing and Access will likely spit the dummy. I use the term RealEstate here.

The RealEstate Class would have a Collection of Properties for Owner, HouseCount, HotelCount, HousePrice, HotelPrice, Image, etc.

Rent is would be a collection of properties itself since storing a single value would be a normalization error because it is based on the houses and hotels included. I would add PurchasePrice too so you could calculate return on investment even though it isn't relevant to the core of the game.

These classes would actually be implimented on the board as instances a subform so as you said they might as well be built on a Form Class.

Create the RealEstate form and add the properties to it. Then while loading the board create instances of this form class for each of the subforms and populate them with the appropriate values. I would store these values in a table. I would also include a Method to save the state so an unfinished game could be reloaded.

This is a better approach then desiging separate subforms for each because you are using a single form design which can easily have properties added rather than adding them to dozens of separate forms.

 

[ROgden]

Thank for the feedback Galaxiom. i'm not calling anything 'Property', that's just asking for trouble. And I also have protocols for saving the session after each move. right now, all real estate values are saved in a table (Owner, Name, Building Cost, Rent Per Building, Number of Buildings etc.)

The way it currently functions is that, when a piece is done 'moving' the real estate that their piece is on is identified, then the values are pulled out of the table and populated into a pop-up form. This states whether or not it can be purchased, if rent is owed etc. If someone wants, they can also click on a 'properties owned' link next to each player that shows a listing of that players properties in a continuous form. clicking on any of the real estates in this list again calls the 'Deed' form up and populates it accordingly.

Basically, only one Deed will ever be displayed at a time. This information is determined by real estate someone lands on, or clicks on in order to review.

Considering this, do you still think there may be value added by creating a handling class? Thanks for you help. ~R

 

[Galaxiom]

I guess if the form is just bound to a table there is no real point to using the class.

A class would be be used in a pure Visual Basic or C solution.

 

[stopher]

I would definitely create a handling class e.g. clsGameAdmin. All your objects should reside in this rather than directly in the form. The forms code should manage the form/interface and communicate with an instance of clsGameAdmin.

This approach seems like overhead but you get a complete separation of the game and the interface. This should make designing the game engine much more structured. You won't have interface code intermingled with game code.

So you have a button on the form "Roll Dice".

• The On Click event tell clsGameAdmin to throw the dice e.g. using a dice method of the class. clsGameAdmin will respond with a move object (player ID & number of moves)
• The form updates to show the new position (moving the player on the form).
• The form calls the SquareAction method of clsGameAdmin.No id is needed, because the class already knows whose move it is and where they are.
• The SquareAction method tells the form what to display e.g. Chance, Deed etc.
• Lets say its Chance. So the form knows to do the Chance popup. The Chance popup asks the clsGameAmin for a card (e.g Chance method).

And so it goes on. The form knows nothing about the rules or position or anything. It knows what to display and where and what to do if certain buttons are pressed.

Another benefit of this approach is that you could take clsGameAdmin design as a complete block and drop it into another programming environment (obviously changing the syntax) e.g. you can do it for an android mobile phone programme (java variant?). Obviously you'd need to do an interface for the mobile phone program but the design of the game class would work fine.

If you really want to follow the class route then I would expect classes for:
GameAdmin, Board, Square, players, Player, PropertyGroup, Property and maybe more.

Chris

 

[stopher]

I guess if the form is just bound to a table there is no real point to using the class.

A class would be be used in a pure Visual Basic or C solution.

It's a fair point. At the end of the day, designing a monopoly program in Access is rather counter-productive.

Recognising the OP is doing this for the sake of interest, he/she might like to look at ChrisO's work here which has some nice tips for doing graphics in Access (which Access is generally limited in)
http://www.access-programmers.co.uk/forums/showthread.php?t=204786&highlight=chess

 

[stopher]

- The On Click event tell clsGameAdmin to throw the dice e.g. using a dice method of the class. clsGameAdmin will respond with a move object (player ID & number of moves)

On considering this again, the move object should simply be player ID and destination square index since the interface has no notion of moves. It simply knows that square 12 is at x,y on the form. It also knows how to graphically move the graphic from one position to another.

 

[ROgden]

Great feedback Stopher. Actually, I don't have the form bound to a table as I don't bind any forms to table or queries, I handle all data traffic through the VBA in all of my projects.n I know this is a silly platform to design this kind of game, but it was more of a 'I wonder if it can be done' thing.

Although I've made complete 'LCARS' interfaces in Access by moving and resizing graphics, this game essentially hides and unhides the appropriate game piece images on the board to 'move' a player. At the end of a move, the player's piece that is visible indicates which square they are on.

I like the idea of separate classes for 'Square', 'Player' etc, and I like the point about how classes will keep the interface code separate form the game engine code. This makes the 'double-hit' (writing all values to the class, then writing them again to the form) worth-while and I don't believe you can 'bind' a class instance to an existing form object.

I've had a mental block about classes in that I can make then function, but the actual understanding seems to continually elude me. I probably need to run through several tutorials and hopefully I'll gain enlightenment somewhere along the way. Thanks for everyone's help in this. ~R