Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

[4E4] Progress Update

Sign in to follow this  


Okay, so I finished the gameplay design either yesterday or the day before (can't remember) and have been working on engine stuff. Here is a sample of my labors:
//// 3.4.1 Deriving Maps ////

Okay, so we have our object manager. Now we need a class to handler rendering maps
and such. First, we'll need another datastructure for each tile:

struct cTile : public cObj {
// since our maps are stored with more than one tile per surface (HOPEFULLY)
// we need to put the texture coordinates for the tile we want to use. We'll
// write a map loader later to handle loading this crap from a file, and much
// later we'll write a map designer app to make the map file to make the maps.
// Yay.
int t_x, t_y, t_w, t_h;

// boolean flag indicating whether units may move through it
bool passable;

Ugh, I've been thinking. How will we know what to do when a user clicks a unit,
then right-clicks a map location? I'm thinking a couple possibilities right now:
- Write a callback function which changes a "mouse state" (bad)
- In the case of a right-click, pass back a move-to position struct, except
transformed from screen coordinates to world coordinates. (good)
So I guess this means we need a position struct (which, in all honesty, can be
used to derive some other stuff previously discussed, but foo.)

struct cXYPos {
float p_x, p_y; };

Okies, so now that we have something to pass back (if there is a unit selected, which
is handled by the parent Game State object) we can move on:

class cMap : public cObjMan, cClickable {
// no need to have a container with all the tiles - that's automagically
// generated when the compiler works its template magic. But we DO have
// our tile list (cMap::m_Objs) floating around.

// since our map is (hopefully) larger than the screen, we'll need to store
// the offset values. We'll use these when we render the map to transform
// all of the tiles from local to screen space, and also use them to clip
// tiles that are offscreen.
int m_offX, m_offY;


// all of the functions which have been previously explained. Should be pretty
// self-explainatory. All inheritec from cObjMan.

// add tile
// get tile
// rem tile

// render
// update

// here's how we move the Map around - by allowing indirect access to the
// offset variables.
virtual void moveMap(int incX, int incY);

// might as well throw in the other accessor function:
virtual void getOffset(int& offX, int& offY);

// now we have a couple more tidbits to throw in, primarily user interaction with
// the map. Since the unit manager handles all the fancy mouse-unit coldet, our
// job here is pretty simple - just transform screen space to local space :)
// inherited from cClickable.
virtual cXYPos onClick(int mouseX, int mouseY);

And that's about it for the map class. Time to write the unit manager!


EDIT: not using tags eats the whitespace (tabs), its too wide to fit in [source] tags, and actually using tags with [quote] tags are too wide for my journal. We're going to have to live with it.
Sign in to follow this  


Recommended Comments

There are no comments to display.

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
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!