Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm making a text based game in C++, but I've hit a snag. I have three classes, plus the driver program. One class is for the player, one for monsters, and one for battle related functions.

My question is, what would be the best way to split up the functions between the classes? Right now I have the variables and functions that create and store all data for the player character (typical RPG style stats, the player menu for commands like move, inventory, etc.), the inventory, and the structs I use to create weapons and armor in the player class. I have a similar class for creating monsters.

I originally intended to put all of the functions related to fighting in the battle class, but then it occurred to me that I'll need all of the data of the player and monsters for the fight function. So, I wrote the main fight function in the driver program, where I create the player and monster objects, and therefore have access to the private member variables of each. However, since I have the "move" command in the player menu (which is in the player class), and it calls a random encounter function, and I want the fight function to be called if a random encounter happens (but the fight function is declared in the driver program), I'm stuck.

So, what I need is advice on what the best practice would be for where to declare the fight function.

share|improve this question
    
What's a "driver program"? –  Liosan Dec 24 '12 at 9:10
1  
Research composition and inheritance in OOP. You can also search for component based models. –  Erik Jan 24 '13 at 13:46
add comment

2 Answers

There are a few different things that could be commented on here, but I'll stick to one for now. Now, I am not a professional game programmer, but it sounds like having the battle functions in a class separate from the driver is good logic. To make this work, it seems to me all you would have to do is pass the player and monster objects to the "battle class" as parameters. Objects can be passed as function parameters just like variables are. look into that and see if it helps you resolve any of your issues.

share|improve this answer
    
Ah, thanks! I'm pretty new to programming, and I figured that there was a simple fix. My question isn't really game specific, but more a general question regarding classes and function. I totally spaced on the option of passing an object as a parameter. I'll definitely try that out and post the result. –  user24312 Dec 24 '12 at 22:44
add comment

It's really hard to answer that question, because, sadly, there are no general answers to design questions. It doesn't really matter if it's C++ or any other language supporting OOP. If you want to get some general knowledge, you should get a book about OOP design (OO Analysis and Design from Head First Series is rather nice).

General tips for creating designs is usually to follow basic principles such as:

  • DRY - Don't Repeat Yourself - pretty straightforward. Reuse everything!
  • SRP - Single Responsibility Principle - an object should be responsible for one task
  • KISS - Keep It Simple, Stupid - don't overcomplicate.

If your code follows basic principles of OOP (such as hermetization) and these rules, it becomes more of an art to create a good model.

Anyway, a tip from myself: static languages such as C++ aren't really well suited to make logic in them. Given that nowadays PCs are a lot faster and you don't need ASM or Pure-C optimizations everywhere, script languages can really help you develop your game logic faster with more ease. I'm a great fan of Lua, but there aren't much problems with embedding Javascript (Google V8) or Python (Boost.Python) in your C++ application.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.