Ship Settings

[Bak]

I looked over the current way ship settings are handled, and I don't think it's ideal. I'll start with describing the current system, and then my proposed one before I implement it. You guys will have a few days to tell me why the proposed method is not good enough, not general enough, and what it can't do that it should (as well as a chance to propose a better one).

 

Currently each ship has settings. Some example settings are ship graphic index, number of frames in the graphic, ship radius, max speed, ect. Most of these settings are inside the shipman module, from which you can get Ship* from a template name (the template names are like "warbird" and are defined in the settings). There are also default settings that are used if the settings don't define all of them for a specific ship (thus eight copies of the same settings one for each ship are not necessary in the .conf file.

 

struct Ship
{
bool display; // should this ship be displayed?
int imageNum; // don't change this (instead free the ship and make a new template ship via the interface)
int frameOffset; // for the image, don't change this (instead free the ship and make a new template ship via the interface)
int numFrames; // for the image, don't change this (instead free the ship and make a new template ship via the interface)

Vector bounceFactorX; // the percentage of speed retained in both directions off a bounce
Vector bounceFactorY; // the percentage of speed retained in both directions off a bounce
int radius; // radius of the ship for bounces

int rot;	// 0-359(degrees) * 10000, so 0-3599999, clockwise from straight up do not use this when computing
			// velocity changes, instead use getRadians which will get the proper radians based on the number
			// of frames in the image
Point loc; // pixel * 10000

int rotvel; // rotational velocity,  degrees / 10 seconds, or deg / 10000 milliseconds
Vector vel; // positional velocity, pixels / 10 seconds ,or pixels / 10000 milliseconds
...
};

 

Some settings, however, are not in the Ship structure. Max speed, for example is handled in the SelfShip module. Since we only care about the maximum speed of our own ship (what a client really do if others are going faster than their max speed?), we don't need to store this for each ship. Other settings in SelfShip include the settings for the ship exhaust, acceleration and other movement-related settings.

 

struct ExhaustSettings
{
Point offset;
Vector vel;
};

struct ShipSettings
{
int rotVel; // degrees / 10 seconds
int maxVel; // pixels / 10 seconds
int accel; // pixels / (10 (seconds^2))

string exhaustName; // the name of the exhaust animation
int exhaustPercentShipSpeed; // the percent of the ship's speed to add to the exhaust
int exhaustRedrawMilliseconds; // the number of milliseconds that p!@#$%^&* between exhaust bursts
vector <ExhaustSettings> exhaustShipOffsets;
};

 

So what's the problem you ask? This system is not general enough!

 

Settings should be handled on a per-player basis. This means that my spider should be able to have different settings than your spider. There's a few reasons for this, but it's not just hyperspace-style buying and selling of components (although that is one reason). Imagine there's a map-region where you can move faster than normal. Rather than hack this into SelfShip before it computes your new speed, we could modify the setting from a central location and selfship would keep a pointer to its max speed which it would automatically use. Then we could imagine a system where there's an unlimited number of modifiers that can take place without modifications to SelfShip (ship is at location X which lets him go faster, has modifier "damaged engines", player owns "super-thrusters", "player used rockets 2 seconds ago", "player is in spider", ect).

 

another problem with the current system is that every time I want to add a setting I either have to change the struct Shipman uses, or store it locally in my own module. The problem with the second approach is it discourages sharing. So currently SelfShip stores the exhaust data locally. Why shouldn't we be able to draw the exhaust of other ships? We can't right now since that data is not exposed. We could expose it in the SelfShip interface, but then every time this happens you have to write your own initialization code, use it locally, and then expose it through your interface. That's a lot of work. Also, if you want to use one of these settings you have to figure out which one of the ten modules that has private ship data it's contained in. A centralized place is a better idea.

 

So looking at this, the player's ship is just another mask on top of the settings. Other masks are like those mentioned above, the player's location, damaged parts perhaps, items he's used, ect. so the settings are no longer to be stored on the shipmanager. Instead I propose we store them use the PerPlayerData module, which manages a data on a per-player basis and allows global sharing of data using names like "position". It gives you a pointer to the data, so any updates will instantly be used by other modules using that data (they should store the pointers for this, obviously). Previously this module was used to store things like the names of players or the freqs they are on. Then, whenever a player changes ship, the ship manager will just apply the settings to the per-player data.

 

One issue I see with this is composability. If we have one setting for ship image, and the shipman sets it whenever we change ships, we need to take care when applying changes. For example, one module may want to change the ship image to a damaged one after the player sustains some damage. Another one may want to change the image to a modified ship that include a giant booster the player has bought. If they both don't know about each other it seems like only one of them will get their way. Perhaps we should be drawing a series of images for each player rather than just a single image... hmm I'm getting off topic here though...

 

But yeah, in general, settings are not as easy as simply being additive. Here's a better example: there is a region where a ships max speed is 2000 no matter what, regardless of any items he's using or such. So if a player uses a rocket and goes into this region his speed drops to 2000. Now the question is when he leaves the region what should the MapRegionSlowdown module reset his max speed to? His previous speed wouldn't be good since the rocket may have run out. Should the region module be forced to communicate with the rocket module (that doesn't scale very well as any future additions may have to modify all the previous functionality)? I'm sure I could think of something to solve this problem but I'll see what you guys can do. Also, do you think this system is general enough or am I missing something?

[Sass]

hey bak, for what it's worth, I'll take a stab at this from the graphics side:

-- I like how you say that one module uses a damaged image, another uses a booster image (upgrade). I definitely do not want to have to draw 40 or more new sprites just to show each combination (1 damage, 1 booster, 1 damage & booster, etc). So since ss is largely 2D, will layers work? (relying on PNG black as transparent). We'll need to be very careful about designing the base 8 ships so that the base layers are easy to cover with upgrades. This !@#$%^&*umes that all upgrades are larger than the base ships. Damage would work like upgrades do except that damage cannot be PNG black or it won't show (obvious) so if I wanted to show 'overall' damage to a ship, my layer contains a black image sprite set with damage at RGB (17,17,17) minimum.

 

Another idea to conquer this graphics maze is to make ships from components. Ship 1 could be Hull A, Wings A, Guns A, and Thrusters A. This same Ship 1 upgrade might be the graphics for Hull A, Wings B, Guns C, and Thrusters B. (endless combinations). On the graphics side, this means that we need to create a sprite set for each component and be sure that it's centered and placed correctly. That's a lot of work for a zone owner but maybe for the new client we could produce a set of 4 upgrades for each ship and let zone owners do more if they want. maybe an XML file contains the upgrade list in order by layer placement. This is probably ideal for zones that use upgrade systems.

[Bak]

yeah that's similar to what I was thinking, but you may want to replace an image entirely rather than just adding to it (a damaged terrier may be missing a wing, not just have brown smudges on it). also instead of xml i'll probably just use the .conf format like for everything else.

[Sass]

With damage, it might be easier if we only need to build damaged components. So we can build Wings A, B, C, and D and maybe we have Dmg_Wing A1, A2, A3, (the list can go on depending on how sophisticated you want damage to appear). Sorry, on my first post i was trying to distinguish two different ideas rather than a combination of both and now reading it again I think i've only re-stated where you were headed with your idea. Edited March 19, 2008 by Sass

[»D1st0rt]

One thing you could do is have a globally accessible list of "overrides" for each player which would be like a setting name/identifier, a value, and then some priority designation. The first thing PerPlayerData would do when retrieving a value would be to check and see if there is an overridden value for that setting.

[»doc flabby]

This is a similar conceptual problem STF is facing.

 

this is how i see the order of processing.

Arena -> Player -> Player Overrides

 

However my idea has been to abstract the settings further, so all the settings are created from the file. rather than them being hardcoded. I've yet to work out how to achieve this however.

 

Eg.

 

Arena.settings

Warbird-speed=100
Firebird-speed=200
Javelin-speed=300

 

These are sent the the client. It stores these in memory in some way.

 

Then a module could alter these by something like.

 

if(special area) {
 Override("Warbird-speed",400)		//sends update to client
} else {
 Reset("Warbird-speed")	 //sends update to client
}

 

It would mean that any setting could just be made up and alter.

 

I am still getting caught up on how to stucture the settings file

Edited March 23, 2008 by doc flabby

[Bak]

Yeah I think the overrides is the way to go. However, a challenge still remains in that we're not always just setting a flat value we want to override with. For example, say the base speed is 1000. There's two "overrides", a damaged engines one with subtracts 200 from the speed, and a rocket override which adds 400. Using plain overrides the speed would be set to either 800 or 1400 depending on the priority, whereas the correct value is 1200.

 

I don't think it's always as simple for every setting to just be able to add, subtract, and set absolute limits, (or use priority to just replace). But I'm having trouble thinking of a situation where this wouldn't work.

[Sass]

Maybe an example of not using the add,subtract simplicity is when you figure kinetics into it. Someone suggested (on the STF forum I think) that it would be cool to see a ship speed or direction be affected by a hit from a bomb or bullet. Bombs obviously having a larger 'blowback' effect. Like in the movies: man gets shot in the arm it; he staggers backward (or stops forward momentum) spins and flops to the floor. That might require a ton of advanced math to figure but I dont think it's as simple as if(hit by bullet) reduce speed 100.

[»D1st0rt]

We have different flags that we can apply to item properties in Hyperspace. Values are relative to the original setting by default, but you can specify that it is an absolute value as well and it will set it to that. If any of the values for a certain property are absolute, they are all added together (though you may want to be able to ignore others based on priority) and we also have a way to make values not stack if a player has multiple of the same item. Something along these lines should get the job done for what you need.

[ThunderJam]

Don't limit bullets bombs to 3 levels, and dont limit them buy a upgrade dmg amount. Let each ships weapons have their own level of dmg, prox, etc.

[teraskasi]

There is a solution, but I haven't figured out an optimal storage method yet.

 

Store all attribute modifiers in lists, and store the start of each list in a map that is mapped via attribute name, psuedo code example:

"MaxSpeed" => maxspeed_attr_list 
"MaxRotation" => maxrot_attr_list

 

The ship object would have two sets of values. The base_values, and the actual_values. Whenever a modifier is added, removed, or changed, option 1) would be to simply alter the corresponding actual_value. Option 2) would be to completely recalculate the actual_value by adding all the corresponding modifiers to the base_value.

 

Option 2 requires more CPU, but is ultimately fail-safe in ensuring that the modifier list and base_value add up to the actual_value.

 

Now as I understand it, These attribute modifiers will come from different sources, such as ship damage, boosters, or being in an area that represents hyperspace. This complicates things just a little bit, because you now have to give each modifier a unique identifier to keep track of them. I'm !@#$%^&*uming that various modules can alter the modifiers, so the safest bet would be to force the use of namespaces for each module, and let the module author sort out the specific identifier. It goes without saying, I think, that modules shouldn't play with other module's attributes under most, if not all cir!@#$%^&*stances.

Edited June 29, 2008 by Steel Arm

[L.C.]

Would a MySQL-styled database work efficiently? That's sort of what it looks like.

 

It would store a variable, a name, and a value (and possibly a description -- otherwise a description could be in a separate file, such as a template.sss). The name would be the name that is displayed to the person configuring the settings, of course.

 

Then again, maybe I should have taken the time to read this entire thread before bringing up this suggestion. Maybe it has already been suggested and dumped.

[»jabjabjab]

split the rolls into 2 images, one where it bends to left, and one that bends right. Make them flexible, aka give more options for rolls (like it turns 10 notches sideways instead of 5, so stack each bend 10 times for left in one image, and then stack 10 times for the right image.