[C] Programming a mechwarriors mud - Tilted Forum Project Discussion Community

Fallon · 03-22-2004, 03:20 PM

So as the subject says, I'm programming a mud in C from another mud/codebase. Right now, I'm in the process of "trimming all the fat" so to speak. Soon though, I want to start the actual programming but I've hit a couple roadblocks. First, I want to make it as close to the table-top game as possible, so I'd have to have limbs and give each allocation spots. So assuming there are 6 limbs, 12 allocation spots, and a field for status of each allocation space, that'd be about 146 variables for each spot, and I know I'm missing a field or two like what's in the spot and stuff. What does something think the best strategy would be. I've been thinking about using an array for it, but that array would also be kinda hefty. Would my best bet be to just drop the accuracy and go for something simpiler or what?
Next part was the hexigonal board. As those who have played know, you have the board(duh) and each hex has it's own status ie: on fire, grass, trees, water, etc. I was also debating on making this an array as I couldn't see much else to do with it. like have an array like board[3][100]
and each value in the [3] would be an x coordinate, a y coordinate and what is in that hex and the [100] would be all of the possible coordinates.
Thanks for reading this far and I'd appriciate very much any help anyone could give.

Yakk · 03-22-2004, 05:43 PM

I'd maintain two mappings.

Item->Allocation Slot
Allocation Slot->ItemID

Items have status usually, slots don't have status. You could give allocation slots damage in order to prevent multiple hits to the same spot, but I don't think that is worth it.

So, your mech becomes a collection of of "items" (including gyroscopes, weapons, cockpit, engine, etc), and a collection of allocation spots, each knowing about the other.

On a hit to an allocation spot, you look up which item is damaged, then you apply the damage to the item.

Quote:

I've been thinking about using an array for it, but that array would also be kinda hefty

Numbers less than 1 million are not hefty. =)

A traditional way to deal with a hex board is to treat it as a grid with a skew on it.

Imagine taking grid paper, and shifting each row by half a "grid size" in turn. Notice that each cell is now in contact with 6 other cells... And, it isn't that hard to know which grid cells are adjacent to each other.

Maintain an array of "struct"s for a zone map:
typedef hex_element zone_map[max_zone_size][max_zone_size];

struct hex_element {
terrain_type basic_type;
bool on_fire;
bool smokey;
bool full_of_chickens;
};

If your terrain is sparse, you can do this a bit better, but at the battle-mech scale of maps, this is good enough.

Fallon · 03-22-2004, 06:06 PM

well, I'd just be worried about having over 30 arrays with at least a possble 146 elements. I've already figured if I used a number style for part of the array, I could have it look up the item name in another array or a table.
But ya, I've already got an idea what to do about the grid and got all the math figured out in my head, going to use a basic x, y coordinate system as i think it'd probably be easier movement wise.
And by the looks of what you got Yakk, to me, an array with a numbered status in the 3rd row would be somewhat easier...=p

KnifeMissile · 03-22-2004, 11:26 PM

By the way, when you say Mechwarrior, do you mean Battletech? Mechwarrior is the roleplaying game, while Battletech is the table top game. If you're replicating the table top game, I assume you have the rulebook with you, so it's kind of surprising that you'd mix the two up...

Anyway, is there a particular reason why you'd be programming in pure C? Even if you don't use the object oriented programming aspects of C++, it still offers many advantages.

Okay, suppose you are programming in C. You'd still want to learn how to use structures. It may seem like a simple idea but they are powerful and will really help your code make sense.

Anyway, enough of that. Onto your problem! You claim to have the grid problem figured out so I'll leave that to you (although your example of the two dimensional array suggests that you don't understand your grid problem but, whatever--listen to Yakk advice!).

You should probably notice that 6 * 12 &ne 146 variables. Anyway, there are two ways you can go about this. The static way (which you seem keen on) and the dynamic way. Lets start with the static way.

You have a structure for each limb. Each limb structure will have an array big enough for the maximum number of items for that limb (I happen to know that not all limbs can have 12 items). If these items have state (they can be destroyed or have ammo) then the elements of this array are, themselves, structures that contain the necessary info, like item type (although this would mean they'd all have to carry this info, even if it doesn't apply--like ammo for your lasers). The static method has the dubious claim of being simpler but, as you have pointed out, allocates a lot of resources (although it's highly unlikely that you don't have these resources). After all, a limb has a static array big enuogh for twelve items, even if it is only equiped with one!

Now, lets look at the dynamic way. Each limb can be a structure that will have a linked list of items. Just like the static way, if the items have state, this will be a linked list of structures that contain state info of each item. Because these are linked lists, they will only allocate resources that are needed. After all, if your mech is fully loaded with 146 (or however many) items, then you really do need 146 slots, right! There's no getting around that... But at least you'll only using the resoures you need and that is the best solution you can get for your concerns of using up too many resources.

If you are intimidated by the use of structures or don't know what a linked list is, then may I kindly suggest that you don't know enough about programming to really implement a game as sophisticated as Battlemech. Practice a little more with simpler projects and this stuff will become second nature to you...

Good luck!

Fallon · 03-23-2004, 04:25 AM

well, my main concern knife, is memory usage, as I will be on a server that only gives us a certain percentage. And yes, I do know the difference between Battletech and Mechwarriors. I have the Battletech Master Rulebook, Maximum Tech and I also have various source books. I have also been programming for a little over 3 years, more precisely, mud programming. So I do know about structures and linked lists. As I said above though, I was wary of using that because of memory usage. Thanks though and I'll start setting all of that up.

KnifeMissile · 03-23-2004, 11:48 AM

Umm, okay. I assume that you do see how the use of dynamic containers (as they're sometimes called) avoids the use of excessive memory that you're so wary of.

Also, just a small hint about the hex map. It should work almost exactly the same way as a grid. If you're storing the coordinates of the hex in the hex structure, you're doing something funny...

Now, that will be all I will say about that and I'll let you carry on however you will...

Yakk · 03-23-2004, 12:18 PM

Code:

typedef enum {head, left_arm, right_arm, centre_torso, left_torso, right_torso, left_leg, right_leg} body_location;

struct  installed_part {
  int item_id;
  int damage;
  body_location location;
  int start_slot_number;
  // possibly include the stop_slot_number, but you can determine this by looking up the item_id
};

typedef std::vector<installed_part> mech_parts;

struct item_details;
// contains item details, like what kind of item, its size, and possibly a reference to
// another table (ie, rather than having all parts carry all of the weapon details, have an
// optional weapon_id int in this structure)

typedef std::map<item_id, item_detail*> mech_part_registry;
// maps item_ids to item_datail*s.



struct global_mech_spec_data;
// contains all the things, like mech_part_registry, or mech_weapon_registry,
// that are needed to understand what id's mean.  Could be
// a global variable, but globals are evil.

bool verify_valid_mech_part_layout(const mech_parts& parts,  global_mech_spec_data const& global_data);
// makes sure the parts don't overlap
// returns false if the constructor of the mech cheated
// returns true if the mech can be layed out like that.

struct mech_armor;
// a struct describing the state of a mech's armor.
struct mech_base_specs;
// a struct describing the non-part specific parts of a mech's design:
// engine size, total weight, options like quad, etc.

struct total_mech;
// contains  mech_base_specs, mech_armor and mech_parts

bool verify_mech(const total_mech& mech,  global_mech_spec_data const& global_data);
// returns true if and only if the mech is a valid mech.
// Checks weight restrictions, slot alloitments, etc.

That would work. No wasted empty arrays. Doing crit hits would be somewhat annoying.

Quad mech support would require extra parameters to verify_valid_mech_part_layout.

KnifeMissile · 03-23-2004, 01:03 PM

Yakk, not everyone programs in C++. Check the thread title...

Fallon · 03-23-2004, 02:45 PM

Knife, I'm open to anything and I've already been looking at adding in some C++ stuff.

Yakk · 03-24-2004, 07:02 AM

I tried to keep it mostly C-like, with some small uses of the STL.

Maps and Vectors are just too useful to pass over, even if you want to avoid complicated C++ object/template junk.

A few gotchas:
If you add elements to a vector, all pointers within the vector might be invalidated. Do not store pointers to objects stored in vectors.

maps are harder to use than vectors, especially to someone new to the STL.

You could just use a vector (which behaves nearly exactly like an array), and manage the mapping yourself.

Vector 101:

Basic use of vectors involves using them as resizeable arrays:
std::vector<int> my_vector; // creates a vector of "int"s.
std::vector<double> my_vector2; // creates a vector of "double"s.
int vec_size = my_vector.size(); // returns # of elements in the vector.
my_vector.push_back(int); // places "int " onto the back of the vector. Makes the vector 1 larger.
int value = my_vector[index] // accesses the index'd element of the vector. Do not pass in a negative index, or an index larger than .size().
my_vector[index] = 7; // you can use [] much like you do with an array or pointer.
my_vector.resize(int); // changes the size of the vector.
&my_vector.front(); // get a pointer to the vector data. This pionter can be invalidated by resize(), push_back(), or many other methods.

When a vector goes away, it deletes the memory it owns automatically. This makes leaks harder than managing a buffer using malloc() and realloc().

You cannot use {0} notation to initialize a struct containing a std::vector. =/

03-22-2004, 03:20 PM	#1 (permalink)
Fallon Junkie Location: RI	[C] Programming a mechwarriors mud So as the subject says, I'm programming a mud in C from another mud/codebase. Right now, I'm in the process of "trimming all the fat" so to speak. Soon though, I want to start the actual programming but I've hit a couple roadblocks. First, I want to make it as close to the table-top game as possible, so I'd have to have limbs and give each allocation spots. So assuming there are 6 limbs, 12 allocation spots, and a field for status of each allocation space, that'd be about 146 variables for each spot, and I know I'm missing a field or two like what's in the spot and stuff. What does something think the best strategy would be. I've been thinking about using an array for it, but that array would also be kinda hefty. Would my best bet be to just drop the accuracy and go for something simpiler or what? Next part was the hexigonal board. As those who have played know, you have the board(duh) and each hex has it's own status ie: on fire, grass, trees, water, etc. I was also debating on making this an array as I couldn't see much else to do with it. like have an array like board[3][100] and each value in the [3] would be an x coordinate, a y coordinate and what is in that hex and the [100] would be all of the possible coordinates. Thanks for reading this far and I'd appriciate very much any help anyone could give.

03-24-2004, 07:02 AM	#10 (permalink)
Yakk Wehret Den Anfängen! Location: Ontario, Canada	I tried to keep it mostly C-like, with some small uses of the STL. Maps and Vectors are just too useful to pass over, even if you want to avoid complicated C++ object/template junk. A few gotchas: If you add elements to a vector, all pointers within the vector might be invalidated. Do not store pointers to objects stored in vectors. maps are harder to use than vectors, especially to someone new to the STL. You could just use a vector (which behaves nearly exactly like an array), and manage the mapping yourself. Vector 101: Basic use of vectors involves using them as resizeable arrays: std::vector<int> my_vector; // creates a vector of "int"s. std::vector<double> my_vector2; // creates a vector of "double"s. int vec_size = my_vector.size(); // returns # of elements in the vector. my_vector.push_back(int); // places "int " onto the back of the vector. Makes the vector 1 larger. int value = my_vector[index] // accesses the index'd element of the vector. Do not pass in a negative index, or an index larger than .size(). my_vector[index] = 7; // you can use [] much like you do with an array or pointer. my_vector.resize(int); // changes the size of the vector. &my_vector.front(); // get a pointer to the vector data. This pionter can be invalidated by resize(), push_back(), or many other methods. When a vector goes away, it deletes the memory it owns automatically. This makes leaks harder than managing a buffer using malloc() and realloc(). You cannot use {0} notation to initialize a struct containing a std::vector. =/ __________________ Last edited by JHVH : 10-29-4004 BC at 09:00 PM. Reason: Time for a rest.

03-22-2004, 06:06 PM	#3 (permalink)
Fallon Junkie Location: RI	well, I'd just be worried about having over 30 arrays with at least a possble 146 elements. I've already figured if I used a number style for part of the array, I could have it look up the item name in another array or a table. But ya, I've already got an idea what to do about the grid and got all the math figured out in my head, going to use a basic x, y coordinate system as i think it'd probably be easier movement wise. And by the looks of what you got Yakk, to me, an array with a numbered status in the 3rd row would be somewhat easier...=p

03-22-2004, 11:26 PM	#4 (permalink)
KnifeMissile Location: Waterloo, Ontario	By the way, when you say Mechwarrior, do you mean Battletech? Mechwarrior is the roleplaying game, while Battletech is the table top game. If you're replicating the table top game, I assume you have the rulebook with you, so it's kind of surprising that you'd mix the two up... Anyway, is there a particular reason why you'd be programming in pure C? Even if you don't use the object oriented programming aspects of C++, it still offers many advantages. Okay, suppose you are programming in C. You'd still want to learn how to use structures. It may seem like a simple idea but they are powerful and will really help your code make sense. Anyway, enough of that. Onto your problem! You claim to have the grid problem figured out so I'll leave that to you (although your example of the two dimensional array suggests that you don't understand your grid problem but, whatever--listen to Yakk advice!). You should probably notice that 6 * 12 &ne 146 variables. Anyway, there are two ways you can go about this. The static way (which you seem keen on) and the dynamic way. Lets start with the static way. You have a structure for each limb. Each limb structure will have an array big enough for the maximum number of items for that limb (I happen to know that not all limbs can have 12 items). If these items have state (they can be destroyed or have ammo) then the elements of this array are, themselves, structures that contain the necessary info, like item type (although this would mean they'd all have to carry this info, even if it doesn't apply--like ammo for your lasers). The static method has the dubious claim of being simpler but, as you have pointed out, allocates a lot of resources (although it's highly unlikely that you don't have these resources). After all, a limb has a static array big enuogh for twelve items, even if it is only equiped with one! Now, lets look at the dynamic way. Each limb can be a structure that will have a linked list of items. Just like the static way, if the items have state, this will be a linked list of structures that contain state info of each item. Because these are linked lists, they will only allocate resources that are needed. After all, if your mech is fully loaded with 146 (or however many) items, then you really do need 146 slots, right! There's no getting around that... But at least you'll only using the resoures you need and that is the best solution you can get for your concerns of using up too many resources. If you are intimidated by the use of structures or don't know what a linked list is, then may I kindly suggest that you don't know enough about programming to really implement a game as sophisticated as Battlemech. Practice a little more with simpler projects and this stuff will become second nature to you... Good luck!

03-23-2004, 04:25 AM	#5 (permalink)
Fallon Junkie Location: RI	well, my main concern knife, is memory usage, as I will be on a server that only gives us a certain percentage. And yes, I do know the difference between Battletech and Mechwarriors. I have the Battletech Master Rulebook, Maximum Tech and I also have various source books. I have also been programming for a little over 3 years, more precisely, mud programming. So I do know about structures and linked lists. As I said above though, I was wary of using that because of memory usage. Thanks though and I'll start setting all of that up.

03-23-2004, 11:48 AM	#6 (permalink)
KnifeMissile Location: Waterloo, Ontario	Umm, okay. I assume that you do see how the use of dynamic containers (as they're sometimes called) avoids the use of excessive memory that you're so wary of. Also, just a small hint about the hex map. It should work almost exactly the same way as a grid. If you're storing the coordinates of the hex in the hex structure, you're doing something funny... Now, that will be all I will say about that and I'll let you carry on however you will...

03-23-2004, 01:03 PM	#8 (permalink)
KnifeMissile Location: Waterloo, Ontario	Yakk, not everyone programs in C++. Check the thread title...

03-23-2004, 02:45 PM	#9 (permalink)
Fallon Junkie Location: RI	Knife, I'm open to anything and I've already been looking at adding in some C++ stuff.