Recommended Posts

I apoligize in advance for the extremely basic question, but I keep having a hard time with classes (very basic, I know)

I am a database programmer by trade (PL/SQL, Oracle, etc) and have been learning quite a bit of PHP for my job - I started looking into C# to get and have developed a few very basic applications for my company - so I have the very basics down...

I have always been interested in game programming, so I figured startign a small game project will force me to broaden my knowledge.

Lets say I want to create a very basic, small "game" that has a icon randomly walking around the screen. I would create a basic "NPC" or "CREATURE" class that contains all the very basic information that all characters in the game would have correct?

For instance lets say

HitPoints

Armor

damage

Then if I wanted to spawn say 5 of them, I would just invoke this class through a constructor 5x, correct?

Lets say I wanted to add a player character, I could use the same "Class" with creature and just add a few more details on it, that way I would not have to re-create the entire "class" from scratch, correct? Isn't that the general idea? I will expand on my question a bit but want to mkae sure I have the very basics down first before I move on.

Share this post

Link to post

Share on other sites

The first, that you admit to struggling with, is the notion of a class. You are mostly on the mark with this. To represent some entity/being/object within the game, you need an object that represents it. Since you have database experience, you can think of an object as a database table in terms of state, combined with functions that manipulate that state. You can think of each instance of that class as a row in the table. This is the idea at its most basic and straight-forward implementation.

The second issue that warnexus is bringing up is that of how to properly delineate between classes in order to maximize the separation of responsibilities. Just like when you design a database, there's an amount of science and art in choosing how best to split information. This is similar to normalizing a database schema -- If you have a database that tracks orders from a warehouse, its probably redundant to store the order details, customer information, payment information, and shipping address directly all in one table. Instead, you have a table of orders, a table of customer information, a table of payment information, and a table of addresses, and you define relationships between these tables. Designing your system of objects is similar, except that you 'normalize' the system around units of functionality, and that the various ways you can create relationships between objects (inheritence, composition (direct and indirect)) have particular consequences. For example, if all enemies are drawable its reasonable that one design might have an enemy class which inherits from a drawable class; but its also a reasonable that a different design might organize itself such that an enemy class contains within itself or otherwise 'owns' an instance of the drawable class. Either approach is valid, each with pros and cons; ultimately, the decision of which is better is guided by your own needs in the context of the rest of the program, your comfort level with either approach, and your personal preferences.