Welcome, Guest. Please Login or Register.  • Help
SMF Underground
+ SHMUP-DEV » SHMUP DEV FORUMS » Assistance
|-+ Best Program Structure for Shmups

Pages: [1]   Go Down
0 Members and 1 Guest are viewing this topic. Topic Tools  
Read January 05, 2006, 12:44:11 AM #0
solidcube

Best Program Structure for Shmups

Do you think it's better to have object interactions encapsulated inside an object manager, and then that object manager encapsulated inside a GameManager class that also handles things like level transitions, game state for things like attract mode and splash screens, et cetera?

How do people do this?  It's one of the stickiest aspects of it for me.  What I usually do is keep my object list as an array of objects inside Main() and then iterate it again and again.  But this seems like a bastardized way and not canonical C++.  Any thoughts?
Offline  
Read January 05, 2006, 01:28:21 PM #1
Digriz

Re: Best Program Structure for Shmups

There is nothing wrong with what you're suggesting here.

Having an object manager, is essential in my eyes for shmups.  Especially, if you are slinging loads of objects around.

Personally, i don't think there is necessarily anything wrong with having an object list as an array.  But i'd use the array to store the index of each objects position in the object manager list.  This way you wont have problems with dangling pointers and other such things.  Avoid link lists if you are iterating through a list constantly, lots of objects can cause performance issues here.

Also, i don't know if i stand alone on this; Don't worry too much about it being perfectly canonical C++....write things to get the optimum speed out of your code, don't write code to make it look neat on the page etc.

Organisation is the key too.  If you can't track your objects and other data easily, you will tie yourself in knots before you get anywhere near finishing your game.
Offline  
Read January 05, 2006, 03:12:26 PM #2
2dguy

Re: Best Program Structure for Shmups

"write things to get the optimum speed out of your code, don't write code to make it look neat on the page etc."

I 100% disagree with this, at least in the initial design phase. Write your code as clean, structured as possible, breaking down as much as possible into smaller routines, etc,etc. Test on low-high end machines, if it's working fine, GREAT! Only optimize if needed. With today's (end user) cpu speeds averaging in the 800mhz range the bottle neck is almost always going to be gpu rather than cpu related.
Offline  
Read January 05, 2006, 03:20:56 PM #3
Nexic

Re: Best Program Structure for Shmups

Yeh I've gotta say that keeping things neat and logical works best for me. If I didn't I would be drowned in my own code in no time. Most of the time logic code will barely ever make any difference the framerate these days so you can afford to do this. However certain things like graphics and collision code really do need to be as fast as you can possibly make them, but even still that doesn't mean it can't be neat!



Offline  
Read January 05, 2006, 05:18:52 PM #4
solidcube

Re: Best Program Structure for Shmups

Yeah, I have to say suggesting to not worry about making it look neat on the page is WHACKO. 

For the optimization stage it's fine, but for the initial prototype stage neatness is the only way to survive.  I run my code through a prettifier called "astyle" every few iterations to make sure it's looking sharp and readable, and I do cleanup on the code every day.

I think I've got a good object manager class structure hashed out now.  Will keep you posted...

Any other thoughts would be welcome.
Offline  
Read January 06, 2006, 03:06:21 AM #5
caseyd

Re: Best Program Structure for Shmups

I think what Digriz was getting at was not to over object orient everything. All the points raised in the last few posts are however, valid. I treat coding like writing. Nothing is ever perfect the first time you write it. It usually takes a few iterations to get it right. Let's say for example I want to add a new feature into my current project, let's call it project Z. I'm not sure exactly how to implement it right off so I go ahead and wing it just to see if it's actually going to improve on my game. Let's say it works. I than go through and recode it, whether it's restructuring the class or possibly reorganizing my existing code base a little. This is like the final proofreading you would do to an essay paper (if you ever actually did that final stage that is). I think that people can go a little overboard with the OOP in C/C++. C++ is still a procedural language, in fact it was originally known as C with Classes.
Offline  
Read January 06, 2006, 04:47:55 AM #6
jbadams

Re: Best Program Structure for Shmups

Also, i don't know if i stand alone on this; Don't worry too much about it being perfectly canonical C++....write things to get the optimum speed out of your code, don't write code to make it look neat on the page etc.
I'd have to agree with the others above, this is in my opinion some pretty bad advice.  While adhering to standards and using perfect OO design certainly isn't something you need to worry overly much about, I'd say that you should always write your code to be readable and easy to understand.

Design your program in a way that makes sense, and that's easy to follow.  Make sure that it's simple to understand, and that it works correctly/as intended; then, if your program isn't performing well enough, profile the code to find any performance bottlenecks, and optimise as required.  Do make sure to profile as well, you'll probably be surprised at where the bottlenecks actually appear if you havn't done so in the past.


As for the initial question, I certainly find that having an object manager handle things helps me to keep the code clean and organised, and certainly makes my life easier in the long run.  I generally have what I call a state manager handling things like running of the game state, pausing, menu display, etc., so that's probably something along the lines of your game manager.  Don't go overboard with a perfect OOP design, it generally isn't worth the hassle unless you really care about it, but I do find that a certain amount of it helps to keep things managable.
Offline  
Read January 06, 2006, 07:37:06 AM #7
Digriz

Re: Best Program Structure for Shmups

Also, i don't know if i stand alone on this; Don't worry too much about it being perfectly canonical C++....write things to get the optimum speed out of your code, don't write code to make it look neat on the page etc.

Ah, ok i deserve to be shot down for this comment.

Caseyd was correct in his assumption about what i was trying to get across in my post.  I am all in favour of code being readable and properly organised; It's the only way i can work.  I just think that over complicating code when it isn't necessary is bad.
Offline  
Read January 06, 2006, 08:58:05 AM #8
solidcube

Re: Best Program Structure for Shmups

Kazgoroth: What is your structure for the state manager?

In my current project, main() initializes the state manager object, then calls methods from it in a tight loop. 

But I'm divided as to whether to turn the states themselves into objects; I think I may just do it with a case statement.  It's not really critical either way because the whole state loop will be executed what, 10 times per run if that?  So not exactly optimization hungry.
Offline  
Read January 07, 2006, 05:23:17 AM #9
jbadams

Re: Best Program Structure for Shmups

My state manager maintains a list of tasks that must be carried out each game tick.  Different states are achieved by requesting them of the manager, which then removes and adds tasks to the list as required to achieve the desired state.  For example, when switching to a paused state, the physics updates will be removed from the task list, and the render manager (which maintains it's own list of items to be drawn to screen) will be told not to accept any new additions to it's list, and to alter the currently held items to be rendered grayscale and add a "PAUSED" graphic to the foreground of the scene.  While in paused mode, the game basically does nothing other than maintain that paused screen and wait for input to unpause.  Similar functions are used to switch to each other state required for the particular game by adding and removing tasks from the task list.
Offline  
Pages: [1]   Go Up
Jump to:  

Page created in 0.17 seconds with 18 queries.