[C++|SDL]Lets get organized!!... How?
Author
Ok, my code is a real mess and its done the worst way its possible to code. SO i want to organize it, put stuff in classes. But how do i do one? Should I just make it class Entities and then have a player and an array of badGuys? And how do i make the update And Render functions in classes, i mean, how do i make it reender the player if player.reender(); is called?
Well, stuff like that.
(Gf, you might help here (again))
ah man... thats a really big can of worms your trying to open...
what do you know about OOP ? how is your code done now? no classes ? the more you program the better you get at designing your code. if i look back at donkey punch adventures, that code is a mess! if i would have known then what i know now.. my code would be a whole world cleaner and nicer looking, and probably smaller also. also, while i was coding DPA, i was looking back at my pong game thinking the same thing...(although pong only took a week and was only 2 files... DPA took over a month and was like 12 files.. my new game ive only worked on 2 weeks and is already over 20 files
) im sure in my next game, i will think that i didnt know crap even now.....
really, i would recommend getting comfy with OOP. i personally love it very much. also, learn about vectors (and the rest of the STL). it will save you time and they come in very usefull (also, dont be scared, they really arent complicated at all)
heres some things i wish i would have known making DPA...
use inheritense. its not scary at all. its very easy to use. also polymorphism is very helpfull. basically, inheritense allows you to split up very simliar classes into different classes. polymorphism allows you to group these different classes togeather and call them as if they were in the same class. in DPA, i only made one class for the players/enemies. it was called class Entity, then, i would have members like Draw_Player(), Draw_Enemy(), Draw_Enemy_Scared(), ETC. this is bad design. calling player.Draw_Player() and enemy.Draw_Enemy() is very bad.
instead, make a base class called entity. have it contain everything that both the player and enemy will have in common. do not have any class members that a certain instance of the class will never use (IE the enemy would never use Draw_Player()). once you have this base class, you make a Player and Enemy class, which both inherit from base. then, you can customize the player/enemy to your liking.
contain all your classes data/actions from inside the class. DONT do any logic for your classes from inside your main. instead, call player.Update(), and inside Update(), you do all your players logic. your main function should not care anything about anyone... your main should only care about Updating() its world... then each part of the world should take care of itself... try to encapsulate everything as well as possible..
how do you make player.render() render the player? well im sure you know how to draw the player by now... just put all that drawing code inside a .Render() function, which is called form Update().
please if anyone sees mistakes correct them. im not an expert on these things, i too am learning, but i think i gave good advise (read my 'over-using the friend keyword' thread for some good advise on designing your code)
if you have more questions then let me know..
also, i posted something like this in the friends thread, but ill post it now:
think of your code as a well oiled machine. a car, for example. an engine does not care about a car seat. an engine only cares about moving the car. in fact, the engine doesnt even care about starting the car. the starter does that. the starter doesnt care about moving the car, and likewise, the car seat only cares about people sitting on it. do you get the picture here? each part to your car, should only care about itself. think about it like this : if a car was just one big hunk of metal melted togeather, if it broke, you would be screwed . likewise, its easy to upgrade/change individual parts. but how easy would it be to upgrade that huge hunk of metal? keep everything encapsulated as much as possible. dont 'melt your code togeather'. encapsulation keeps things organized, and easily changed. even if you dont understand why yet, you will see after a while. all of this wont just make sence to you at first, but after working with it you will realize what the point of OOP is. im just starting to understand this now
[edited by - graveyard filla on May 7, 2004 5:12:05 PM]
[edited by - graveyard filla on May 7, 2004 5:24:01 PM]
[edited by - graveyard filla on May 7, 2004 5:25:40 PM]
what do you know about OOP ? how is your code done now? no classes ? the more you program the better you get at designing your code. if i look back at donkey punch adventures, that code is a mess! if i would have known then what i know now.. my code would be a whole world cleaner and nicer looking, and probably smaller also. also, while i was coding DPA, i was looking back at my pong game thinking the same thing...(although pong only took a week and was only 2 files... DPA took over a month and was like 12 files.. my new game ive only worked on 2 weeks and is already over 20 files
) im sure in my next game, i will think that i didnt know crap even now.....really, i would recommend getting comfy with OOP. i personally love it very much. also, learn about vectors (and the rest of the STL). it will save you time and they come in very usefull (also, dont be scared, they really arent complicated at all)
heres some things i wish i would have known making DPA...
use inheritense. its not scary at all. its very easy to use. also polymorphism is very helpfull. basically, inheritense allows you to split up very simliar classes into different classes. polymorphism allows you to group these different classes togeather and call them as if they were in the same class. in DPA, i only made one class for the players/enemies. it was called class Entity, then, i would have members like Draw_Player(), Draw_Enemy(), Draw_Enemy_Scared(), ETC. this is bad design. calling player.Draw_Player() and enemy.Draw_Enemy() is very bad.
instead, make a base class called entity. have it contain everything that both the player and enemy will have in common. do not have any class members that a certain instance of the class will never use (IE the enemy would never use Draw_Player()). once you have this base class, you make a Player and Enemy class, which both inherit from base. then, you can customize the player/enemy to your liking.
contain all your classes data/actions from inside the class. DONT do any logic for your classes from inside your main. instead, call player.Update(), and inside Update(), you do all your players logic. your main function should not care anything about anyone... your main should only care about Updating() its world... then each part of the world should take care of itself... try to encapsulate everything as well as possible..
how do you make player.render() render the player? well im sure you know how to draw the player by now... just put all that drawing code inside a .Render() function, which is called form Update().
please if anyone sees mistakes correct them. im not an expert on these things, i too am learning, but i think i gave good advise
(read my 'over-using the friend keyword' thread for some good advise on designing your code)if you have more questions then let me know..
also, i posted something like this in the friends thread, but ill post it now:
think of your code as a well oiled machine. a car, for example. an engine does not care about a car seat. an engine only cares about moving the car. in fact, the engine doesnt even care about starting the car. the starter does that. the starter doesnt care about moving the car, and likewise, the car seat only cares about people sitting on it. do you get the picture here? each part to your car, should only care about itself. think about it like this : if a car was just one big hunk of metal melted togeather, if it broke, you would be screwed
. likewise, its easy to upgrade/change individual parts. but how easy would it be to upgrade that huge hunk of metal? keep everything encapsulated as much as possible. dont 'melt your code togeather'. encapsulation keeps things organized, and easily changed. even if you dont understand why yet, you will see after a while. all of this wont just make sence to you at first, but after working with it you will realize what the point of OOP is. im just starting to understand this now [edited by - graveyard filla on May 7, 2004 5:12:05 PM]
[edited by - graveyard filla on May 7, 2004 5:24:01 PM]
[edited by - graveyard filla on May 7, 2004 5:25:40 PM]
It depends on what type of game you''re coding.
If you''re talking action game, it might be a good idea to take a
look at the Half-Life SDK code and see how they did it.
Heck, any commercial SDK would be a benefit to you, I''m sure.
-Hyatus
"da da da"
If you''re talking action game, it might be a good idea to take a
look at the Half-Life SDK code and see how they did it.
Heck, any commercial SDK would be a benefit to you, I''m sure.
-Hyatus
"da da da"
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
