1

I am writing a RPG game and am finding there is far more background functionality that the user ever sees.

I have a battle class. this holds instances of the enemies the background picture and deals with choosing which enemies are in the battle.

I have developed several global functions to calculate and display gauges like hp and mp. and another to move the timer bar so battle progresses. but I am wondering if these should be in the battle class as with all the other functions I for see it will grow far larger than any other class ?

Also i know drawing should be separated from other code so right now i have global functions that loop through all the active stuff and draw it after the process code has finished, but would it be better to put a draw function inside each class and loop through them instead or keep it all separate ?

The other thing that has been bothering me is I am implementing attacks and was thinking of giving the creature class four attack class instances. this would work but would create waste if there were two or more creatures in the battle that used the same attack. I thought about making one instance of every attack type somewhere and having each creature store four pointers to the applicable attack instances. Are either of these options a good idea or are the better ways to implement this?

sepp2k
  • 363,768
  • 54
  • 674
  • 675
Skeith
  • 2,512
  • 5
  • 35
  • 57
  • I recommend that you read a [good book](http://stackoverflow.com/questions/388242/). I fear there is no simpler answer. – Björn Pollex Jun 15 '11 at 09:43
  • @Space_C0wb0y 1) I have read books but there are so many different approaches, traditionally I have favoured procedural over OOP but seeing as this is a game OOP it is :) 2) there is a difference between a page written by some guy however many years ago and peer opinions on your specific set-up. – Skeith Jun 15 '11 at 09:51
  • It sounds like you have a lot of global functions. Perhaps you should think of a way to encapsulate some of that functionality. Maybe a "ScreenManager" interface which is composed with a `list` of screen members ("draw a battle", "draw a heath meter" etc...) would be useful. – Dennis Jun 15 '11 at 09:53
  • @Skeith - There will be varied opinions on your question, and no definite answer and a fool is he(she) who says so. You yourself should be the guy to decide which suits you best. Take opinions but use the one which suits you the best. – DumbCoder Jun 15 '11 at 09:55
  • @Skeith: I recommended to read a book, because the scope of your question is so huge that only a book can answer it. As it stands, it is not a question with a definite answer, and as such not appropriate for SO. As I write this comment, I realize that I should have voted to close in the first place. Doing so now. – Björn Pollex Jun 15 '11 at 09:55
  • @Dennis i was thinking of some kind of draw class, I think that is what you suggest but I don't recognise the term but I found that it would need mostly runtime information so I have had no luck with it :( – Skeith Jun 15 '11 at 09:57
  • @Skeith - As the other are saying there are TONS of ways to do this. @Dumbcoder is correct... there are going to be lots of opinions on this. You should look at some open source games and see how they are implemented, read some books about design patterns, and be aware of all the different ways to abstract your code and encapsulate functionality. Good luck! – Dennis Jun 15 '11 at 10:02

1 Answers1

0

I think you should have a look on the finite state machines which usually the base mechanism for games. That would give you a broad idea how your code should be organized in order to keep everything easily editable and easy to browse.

I think your choice of class extraction is kind of weird. The "battle" in it self does not qualify for a class since it has no resemblance to any "object" which is at the heart of OOP. I mean, yeah, you can collect your functions in to a specific class, but then it make more sense to identify first the states you are dealing with and then build a state machine around them, so if as you progress, a new set of states arise, you can easily build a new class for that functionality.

I'm sure that FSM is the thing you're looking for...

To give an idea: Simple but generic FSM implementation in C++ Game design with FSM tutorial

progician
  • 910
  • 8
  • 15
  • yes a class for battle may be the wrong idea but my theory was battle was a state and all the data on that state is in the battle class. people on this site have told me it is ok to have a class like this that is only implemented once. – Skeith Jun 15 '11 at 11:05