I''ve been programmin for about a year, and c++ for about 3 months (started out with vb of course). I''ve done some programs using tile engines and directx stuff, but never really tried to convert it all to OOP. Right now i am making bomberman and started out with an OOP goal. But i''m getting so damn confused!!! How can you think of all these things as seperate objects if they need access to the same variables!!! Before, without OOP, all my functions could access the global variables set...it seemed easy. I made something called DZX, inspired by EZX from VB. Basically its the simplest 2d you can get, just make a DZXImage variable and then show it by passing x and y coords. In the DZX.h file i enforced use of two functions gamestart() and gameloop(double fps) by putting function prototypes in the .h. You can figure out what these due. Basically I hid all the windows entry point and callback functions to make it easy to concentrate on the game. Now that i''ve said that, heres the current structure of the game. I have a cApp class which includes every other class and handles basiclally everything. In gamestart() i do myApp.loadimages() and what not, and then in the gameloop i do myApp.moveobjects(double fps) and myApp.draw(). In cApp i have as private members cItemMap (which holds a 15x15 matrix [0 for nothing, 1 for blue bomb, 2 for red bomb, 3 bomb exploding, 4 for health...and so on]), cMap(I load a map when the program starts[0 for nothing, 1 for bombable block, 2 for non-bombable block]), and finally cCharacter. But my prob is that they all need each other!!!! For example, in cCharacter i need the map and itemmap to check for collision. In every one of my other attempts to convert my progs to OOP i run into this problem. Will somebody please give me advice?? BTW, if you want to see the source just e''mail me and i''ll send it to ya. ~EODCyismARDEM

sup,

i had the same problems and confusions when i first started learning OOP too. no worries.

anyway basically you have to STOP using global variables. it's that simple.

reworking something into an OOP architecture means pretty much completely redoing the software architecture.

if you are finding that different object need to access the same variables then you didn't do a good job of making objects.

think of different objects in terms of discreet components of your codebase. if you want to have a Util class or something that processes data passes to it make a member function like:

DataType * Util::processSomething(DataType * foo) {
//do something with foo
return foo;
}

that way you can pass in info to be processed and you return the data later.

i dunno. mostly you have to struggle with OOP and then it'll just start making sense.

i'd suggest that your "teach myself OOP" project NOT be porting something to OOP that was not originally OOP. do soemthing from scratch and set up the initial architecture without global variables. if you're porting something you just get stuck in the logic that you came up with before and you can't see the new way to do it.

-me



Edited by - Palidine on February 7, 2002 5:48:00 PM

thanks for the post Palidine

This bomberman project that I started was my first attempt to start an OOP project from the beginning. I figured out what you were saying about getting mixed up in your original logic when trying to port to OOP from non-OOP. In the beginning the structure i made seemed most reasonable, but after making the code i needed come classes to access other classes...and thats my prob. Obvously my structure wasn''t good to start with, but even this other bomberman source (that is HUGE and i can''t understand some of the stuff) had the same logic i had. Can somebody gimme tips on a new structure or maybe how i could work this out??

btw, does anybody know any good resources for OOP. books,tutorials, websites whatever?

object orientation isnt just something you can read about, its an entire mindset that takes years to get.

if youve been programming in c++ for only three months then calm down -procedural programmers can take a while to adjust to oop.

the entire idea of oop is to take normal static stuff and group it under common contexts. this often results in associating variables with functions, but not always.

first off, do you understand each of these words:
composition
inheritance
polymorphism
?
those words are the foundation of oop, if you are fuzy on any of em, then read up.

there are also two problems i think you may have, 1, starcraft syndrome -youre trying to start too big, and 2, your trying to port from C ----------------------- do not do this!!! if you are an amature c++ programmer, then attempting to port from c is a bad idea! you have to many preconceptions and junk! try to start from scratch, and then, someday when u know what ur doing, come back and make comparisons to C...

you should look into something called UML, or Unified Modeling Language, it will help you figure out how to design objects.

Edited by - evilcrap on February 8, 2002 1:25:22 AM

A simple approach to OOP is to:
1. think of all the nouns in your game
2. jot them down
3. usually they are the basic Objects in OOP
4. those that are not, put them aside, they might be... in the later analysis stage.
4b. think of the attributes of the object (eg. name, power, score)... they might end up member data.
5. think of the action/verb of each of those objects can do.
6. most likely they would turn up as your member functions.

At the final you most probably will think about the interactivity between all the objects (using the member funtions u have found.)

Hopes that help a little.

Object oriented programming is not something you can master in a few months so don''t become frustrated if creating a logical program structure seems confusing. Here is a few tips you might find useful when trying to solve problems:

Look at your overall system and decide how you can break it down into smaller parts. That is one of the biggest mantras my Java instructor drilled into our class. "you have to break things down and keep breaking them down". It is really the core of programming. You never see every detail until you try to implement an algorithm and the thing is growing exponentially on you. Suddenly you have one method that is so convoluted you forget what you are doing. You find out as you go along that you need to keep breaking down the problem into even tinier and tinier parts. Create public interface methods for objects and then create private helper methods for the interface methods. Then create private helper methods for the private helper methods. Keep going until you create a set of tools the object can use over and over and over again for more than one specific task. When you''ve reached that point you''ve got a pretty good class written and the code is so much easier to follow.

Creating classes helps break things down. Now you can group methods logically together along with data fields. How do you get objects to share data? It''s more simple than you think. If you look at the standard APIs (particularly with the java platform) they make it easy as pie. Almost every object has methods whose names begin with either "set" or "get". That''s the basics of passing data between objects. Follow in the footsteps of the people who wrote these great peices of work- adopt a naming scheme and stick with it. You''ll be glad you did.

Hope that helps you some. Be persistent!

Something to keep in mind - If it ain''t broke, don''t fix it. Is it really necessary to re-write your program in an OOP fashion? If not, then don''t.

Anyway, if you decided you really must, and you still need to have access to a global variable, give the class a static variable. All objects of that class will share one copy of the variable. For example:

4 members in my family-Me, Wife, Daughter, Son
Each has a separate name, but all share a last name.
The last name would be a static variable.


If more than one class needs it, you would have to get into wrapper classes and all kinds of other mystical forces best left untapped.


ShadeStorm, the Day_Glo Fish

THANKS FOR THE HELP GUYS!! Bascially i think i''ve realized that maybe i just need to go out and get a damn book on OOP. I knw that i had to keep my project simple, so don''t worry i wasn''t naive and had a case of the starcraft syndrome or whatever. I wanted to keep it to 4 classes. BTW, i think some of you had the wrong idea...the Bomberman project was not a port. It was my first project on OOP right from the beginning, all my other attempts were ports. I realized that porting wasn''t so easy and stuff. So this project is not a port!!

~EODCyismARDEM