Sign in to follow this  
  • entries
    570
  • comments
    2427
  • views
    216096

[4E4] Progress Update

Sign in to follow this  

65 views

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 {
protected:
// 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;

public:

// 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!


[wink]

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  


0 Comments


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