Classes

Started by
3 comments, last by Ravyne 10 years, 10 months ago

Good afternoon folks.

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.

Advertisement

You are thinking too hard. A class is just a lump of things that have a direct relationship to each other. You would define the class as an array to get your 5 objects.

You are thinking too hard. A class is just a lump of things that have a direct relationship to each other. You would define the class as an array to get your 5 objects.

You would define the class to be Sprite because it needs to be drawn on screen. You mean to define another class Game separately to store the objects in a list I believe.

The big picture idea of a class is re-usability.

You will a Sprite class to establish that this class will be updated and drawn on screen and have some idea of position and velocity

A Vector2D class(this is just a class that contains values of type double x and y to describe the object's position and velocity followed by methods for basic arithmetic (+,-,*)

A Collidable interface that establishes collision methods.

A GameComponent interface that establishes the idea of updating and drawing the objects

A Game class that loads your game.

Example code in Java:

The Game can also extends JPanel or Canvas instead. The choice is yours.


public class Game extends Canvas
{
 
}

public class Alien extends Sprite implements Collidable
{
 
}


public class Sprite implements GameComponent
{ 
 
private Vector2D position;
private Vector2D velocity;
 
public void update(long milliseconds)
{
 
}
 
public void draw(Graphics g)
{
 
}
 
}

public interface GameComponent
{
 
public void update(long milliseconds);
 
public void draw(Graphics g);
}

Example how to create one row of 5 different aliens using a for loop:

int offSet = 135;
// create a row of Aliens
 
for(int row = 0;row < getWidth() ;row += offSet  )
{
 
Alien alien = new Alien(row,0);
add(alien);
 
}

Other posts here are conflating two issues --

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.

throw table_exception("(? ???)? ? ???");

This topic is closed to new replies.

Advertisement