• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
scjohnson243

Classes

4 posts in this topic

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.

0

Share this post


Link to post
Share on other sites

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.

-3

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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);
 
}
Edited by warnexus
1

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites

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  
Followers 0