Tilted Forum Project Discussion Community  

Go Back   Tilted Forum Project Discussion Community > Interests > Tilted Technology


 
 
LinkBack Thread Tools
Old 03-22-2004, 03:20 PM   #1 (permalink)
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.
Fallon is offline  
Old 03-22-2004, 05:43 PM   #2 (permalink)
Wehret Den Anfängen!
 
Location: Ontario, Canada
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.
__________________
Last edited by JHVH : 10-29-4004 BC at 09:00 PM. Reason: Time for a rest.
Yakk is offline  
Old 03-22-2004, 06:06 PM   #3 (permalink)
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
Fallon is offline  
Old 03-22-2004, 11:26 PM   #4 (permalink)
 
KnifeMissile's Avatar
 
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!
KnifeMissile is offline  
Old 03-23-2004, 04:25 AM   #5 (permalink)
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.
Fallon is offline  
Old 03-23-2004, 11:48 AM   #6 (permalink)
 
KnifeMissile's Avatar
 
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...
KnifeMissile is offline  
Old 03-23-2004, 12:18 PM   #7 (permalink)
Wehret Den Anfängen!
 
Location: Ontario, Canada
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.
__________________
Last edited by JHVH : 10-29-4004 BC at 09:00 PM. Reason: Time for a rest.

Last edited by Yakk; 03-24-2004 at 06:53 AM..
Yakk is offline  
Old 03-23-2004, 01:03 PM   #8 (permalink)
 
KnifeMissile's Avatar
 
Location: Waterloo, Ontario
Yakk, not everyone programs in C++. Check the thread title...
KnifeMissile is offline  
Old 03-23-2004, 02:45 PM   #9 (permalink)
Junkie
 
Location: RI
Knife, I'm open to anything and I've already been looking at adding in some C++ stuff.
Fallon is offline  
Old 03-24-2004, 07:02 AM   #10 (permalink)
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.
Yakk is offline  
 

Tags
mechwarriors, mud, programming

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -8. The time now is 03:18 AM.

Tilted Forum Project

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Search Engine Optimization by vBSEO 3.6.0 PL2
© 2002-2012 Tilted Forum Project

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360