Sign in to follow this  

First game using Classes

This topic is 4099 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, I am teaching myself a little code to better understand game development as a whole. I have been making my way through a book on C++ and have hit classes and OO programming. I like to learn a new aspect of C++ then write a small game using what i have just learnt. But i am finding it hard to design a text based game using classes. Could anyone give me some ideas/help/links on designing a basic text based game using OO programming? Thanks, Dan.

Share this post

Link to post
Share on other sites
How about your standard text adventure game where the player has to navigate a set of rooms with monsters and items in them? This can be modeled well with OOP. For example you can have a Player class (possibly deriving from a more general class), Monster classes, Item classes etc.

A lot of learning to use OOP is in trying to design things yourself and learning from your mistakes. It can be hard to wrap your head around inheiritance and composition at first.

Share this post

Link to post
Share on other sites
You can see classes as just types. Only, instead of containing only a single value, you can define just what exactly they store.

For example, if you had power-ups spread across the level, you would create a Powerup class, containing it's type and location. You can now create multiple Powerups, just as you can use multiple ints or bools in your program:

Powerup a;

a.x = 5;
a.y = 10;

A next step would be to derive classes from other classes. Say, a sword is a specific Powerup type: besides a location and type, it also needs to store the strength and duration of the sword. So:

class Sword: public Powerup
// class definition

A Sword object can be treated as a Powerup, since essentially it is one, but it adds a few variabeles (and possibly functions) of it's own. This saves you writing code twice and makes maintenance easier, if done well of course.
There are far more aspects to OO programming, such as dividing responsibility - should the Paint class render all objects, or should each object have a Paint function itself? Rather than treating classes as data buckets, you should keep in mind they can have functionality attached.

I've put up the source of a small ascii game prototype I wrote a while ago here:
download. It features a scripting-system, allowing you to create levels for it with Notepad. I hope you can learn a few things from it. It's certainly not the only, or perfect, approach, but it sufficed at that time. :)

Share this post

Link to post
Share on other sites
Original post by bam104
I was hoping for something more detailed that i could base my first attempt from. Anyone have some old code they wrote at this sort of level?

You're honestly waaaaay better off just trying this out yourself to begin with and just coming back to the boards with questions. Looking at someone else's code and just copy - pasting or even just cribbing will dramatically slow down your learning curve.

Just take a stab and start writing code. You'll get confused pretty quickly and you can come here with good questions.


Share this post

Link to post
Share on other sites
Guest Anonymous Poster
I may take some heat for this, but it's been my experience that effective use of OOP is more often about what NOT to model as an object.

You might find yourself falling into object-obsession at first: why would I represent a deck of cards as a simple array or list or records, when I could model the deck as a 'Deck' object inheriting from the 'Collection' object, and make each card an object which multiply inherits from the 'Cardboard', 'Numbered' and 'Picture' classes, with overloaded 'lookat' methods...

So find yourself a problem that DOES fit neatly into the OO paradigm. These problems are fewer than you might imagine. How do they look like?

1) You have to model entities with local state whose state update functions are tightly coupled to the entities' type, and you want to create them dynamically (in the middle of program execution).

For example, multiple counters with differing step sizes (you want, say, two counters starting at 0 which count in increments of one and three counters starting at 7, 8 and 9 which count in increments of 4, and you want to make them in response to player actions during the game).

You don't need to go through the hassle of making classes for this in richer languages (those that support lexical closures, for example) but classes are the way to go for this sort of thing in C++.

2) You have to model entities that are different but share important similarities. These similarities must be more or less hierarchical in nature (look like a tree) for you to be able to effectively apply OO, and they should span both state (variables) and functionality (methods) that in some sense 'belong' to the entities. This is what OO is mostly about.

A good example is entities in a game, as the previous poster observed. Each entity has a position and an image representing it, at least. Each entity also has a display() method, that knows how to draw it on the screen (or maybe not, depending on your design).

If they're not rocks or trees, they also have a move() method. Different creatures move() in different ways, but they all move().

Some characters may have attack() methods. The name attack() stays the same (it represents a common action) but the specific attack may vary from creature to creature.

Player characters may have an inventory.

Monster characters may be further subclassed into ghosts and grues, each with different move() and attack() methods and health or item attributes...

The important thing is that methods and attribute definitions are inherited from superclasses, which saves you the hassle of defining them anew each time if they are identical AND (more importantly) PROVIDES A COMMON INTERFACE TO COMMON FUNCTIONALITY: you can call the move() method on any entity, not caring whether it is a ghost or a grue or whatever, and not caring HOW it moves specifically. You just want it to move, and it takes care of moving in its creature-specific way. So instead of scattering move_grue(), move_ghost() etc calls throughout your program you simply call move() methods on movable objects, leaving the details of the movement to the object.

3) Relationships that are symmetric between classes are usually NOT well modeled as class methods: don't try to shoehorn things into the OO paradigm that don't belong there. For example, a method that checks for collisions: it depends equally on two entities, so making it assymetrical (making it a method of a particular entity class) probably isn't a good idea.

I think this third point is the most important: remember that good design doesn't mean 'make everything an object'.

Share this post

Link to post
Share on other sites

This topic is 4099 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this