|
| Author |
Message |
formula1
|
Post subject: Item (Concept -> Programming) Posted: Sun Nov 09, 2008 9:39 pm |
|
 |
Joined: Sat Nov 08, 2008 9:17 pm Posts: 80 |
|
|
formula1 wrote: fechdog wrote: Basically, if we figure out how to load the data from the SMW engine, that would make this a ton easier, right? yes...... lol....... I should have made that the summary..... We need to know how to load data from txts to the SMW engine and then put them into their appropiate places. If you want to read more specific aspects, copy and paste the following and make it a larger font It seems Like one of the things that people want is items -Since The way the items move is part of what an item is, I'm putting this in.
These two things are actual very similar, The only difference is that The item creator must be 16x16 While enemies can increase and decrease in size
Either way This thread is about the Concept of Item and Enemy creation And Finding the Code to allow us to make them easy to create for users and The codes within Super Mario War to make it easily intergrated into it.
Hittesting One thing that every item some sort of Hittesting. -When you hit an item something happens -Some items can be grabbed which is also an important addition. -Some items don't automatically get used (Pow)
-Hittest --Grab enabled? (Yes/no) --Save (You don't use it automatically) enabled? (Yes/no)
If The item is grabbed enabled -Path works in a different way.
Path Another thing about items is "Path" -Mushrooms just go left to right and bounce of walls, while being effected by gravity. -Feathers come down like a pendelum. Being effected by gravity, but slow down and move to the left or right more until they have no more vertical movement, then get effected by gravity again. -Flowers just stand there
You can set vertical Velocity = Gravity Horizontal velocity = 4 pixles per second If hit wall-What happens? (Go through it, bounce at X velocity, etc) If hits ground-what happens? (Go through it, bounce at Y velocty, etc) If hits ceiling-What happens? (Go through it, bounce at Y velocty, etc)
If item is Grab enabled, physics are -f(Initial velocity)=Time WHere the person works with the initial velocity to decide how the item will move -Initial Velocity will transformed into xvel and yvel and those velocities will change over time. --THis will make Boomerangs a Grabable item you can stomp on rather then a power up like it is now
Graphics -Making The Item Animated --Pow, Flower, feather etc, etc, etc
Triggering I didn't get to into this Because I feel like this is a whole nother Section When you -What happens (Power up, Death to those on ground/in air, this, that, etc,etc) --If its a power up, what does the projectile do (Load pictures and physics) --If its this, what happens. etc If grab enabled -When you step on it, what happens
Removal -How long will the item exsist
Inorder to make it usable by Super Mario war 1) We must look into where they store the Items (Folder) -If they don't, we'll change the scripts so that each item has its own Txt and graphic and they will be stored in their appropiate places (This way everything will be easy for the player to include/delete) 2) How they "Call" the items when -When an item is Ordered to come out of a question mark box. Custom items will be able to come out. 3) Change the "Percentages" to a Dropdown menu with scroll to effect which ones will be exsistant -Give "All On/All Off" option -As well as giving people the ability to save and load Percentages data (Some people may make really good Percentages data.) --If theres an item that one person has that another person does not, then the program will skip that one ---Each item will go by name. when depicting Percentages -THere will be a Percent chance to get Nothing -I want to change the percentages into fractions by giving someone "whats left" and beside each Item on the drop down menu, you'd see the fraction that item has. Every item can have a custom Fraction. And If theres numbers left, thats likely hood you will get nothing. 4) How items get their Graphics-Txt doc 5) how items will get their physics-Txt doc 6) THe effects of the items-Txt Doc
So. 1) Make The SMW code Load every Item data by Names in the Txt documents 2) Make the code enable Physics for an item that comes from data from a txt document 3) Make the code load pictures for an item that come from data from a txt document 4) Make the code that gives the player whatever (Powerup, this that.) 5) Grabable? Instant use (Poison mushroom)? Saves? (Would go first on detection)
So... We must figure out how to load data from documents to say "what is an item" and which would turn on a switch to load data for graphics, physics, Trigger code and misc code
Also figure out Super Mario Wars physics engine And in general, Item engine.
Last edited by formula1 on Sun Nov 09, 2008 10:56 pm, edited 2 times in total.
|
|
| Top |
|
 |
fechdog
|
Post subject: Re: Item (Concept -> Programming) Posted: Sun Nov 09, 2008 10:51 pm |
|
 |
Joined: Sat Nov 08, 2008 3:05 pm Posts: 260 |
|
|
|
Basically, if we figure out how to load the data from the SMW engine, that would make this a ton easier, right?
|
|
| Top |
|
 |
formula1
|
Post subject: Re: Item (Concept -> Programming) Posted: Sun Nov 09, 2008 10:54 pm |
|
 |
Joined: Sat Nov 08, 2008 9:17 pm Posts: 80 |
|
|
fechdog wrote: Basically, if we figure out how to load the data from the SMW engine, that would make this a ton easier, right? yes...... lol....... I should have made that the summary..... We need to know how to load data from txts to the SMW engine and then put them into their appropiate places.
|
|
| Top |
|
 |
Sonnitude
|
Post subject: Re: Item (Concept -> Programming) Posted: Sun Nov 09, 2008 10:56 pm |
|
 |
| Site Admin |
Joined: Thu Nov 06, 2008 8:52 pm Posts: 361 |
|
|
|
Don't forget that we are also trying to improve current features too!
|
|
| Top |
|
 |
formula1
|
Post subject: Re: Item (Concept -> Programming) Posted: Sun Nov 09, 2008 11:05 pm |
|
 |
Joined: Sat Nov 08, 2008 9:17 pm Posts: 80 |
|
|
Sonnitude wrote: Don't forget that we are also trying to improve current features too! Absolutely, But I wouldn't doubt, this will make it alot easier after looking at the code.... But nonetheless... this is one type of code we have to study. This is the hammer Quote: //------------------------------------------------------------------------------ // class hammer //------------------------------------------------------------------------------ MO_Hammer::MO_Hammer(gfxSprite *nspr, short x, short y, short iNumSpr, float fVelyX, float fVelyY, short aniSpeed, short iGlobalID, short teamID, short iColorID, bool superHammer) : IO_MovingObject(nspr, x, y, iNumSpr, aniSpeed, (short)nspr->getWidth() / iNumSpr, (short)nspr->getHeight() >> 2, 0, 0) { ih = ih >> 2;
iPlayerID = iGlobalID; iTeamID = teamID; colorOffset = iColorID * 28; movingObjectType = movingobject_hammer; state = 1; velx = fVelyX; vely = fVelyY; ttl = game_values.hammerttl;
fSuper = superHammer;
if(velx > 0.0f) drawframe = 0; else drawframe = animationWidth - iw; }
void MO_Hammer::update() { if(++animationtimer == animationspeed) { animationtimer = 0; if(velx > 0) { drawframe += iw; if(drawframe >= animationWidth) drawframe = 0; } else { drawframe -= iw; if(drawframe < 0) drawframe = animationWidth - iw; } }
xf(fx + velx); yf(fy + vely); if(!fSuper) vely += GRAVITATION;
if(ix < 0) xi(ix + 640); else if(ix > 639) xi(ix - 640); if(iy > 480 || --ttl <= 0 || (fSuper && iy < -ih)) removeifprojectile(this, false, true);
//Detection collision with hammer breakable blocks IO_Block * blocks[4]; GetCollisionBlocks(blocks); for(short iBlock = 0; iBlock < 4; iBlock++) { if(blocks[iBlock] && blocks[iBlock]->getBlockType() == block_weaponbreakable) { B_WeaponBreakableBlock * weaponbreakableblock = (B_WeaponBreakableBlock*)blocks[iBlock]; if(weaponbreakableblock->iType == 5) { weaponbreakableblock->triggerBehavior(iPlayerID, iTeamID); removeifprojectile(this, false, false); return; } } } }
bool MO_Hammer::collide(CPlayer * player) { if(iPlayerID != player->globalID && (game_values.teamcollision == 2|| iTeamID != player->teamID)) { if(player->shield == 0) { removeifprojectile(this, false, false);
if(!player->invincible) { //Find the player that shot this hammer so we can attribute a kill PlayerKilledPlayer(iPlayerID, player, death_style_jump, kill_style_hammer, false); return true; } } }
return false; }
void MO_Hammer::draw() { spr->draw(ix - collisionOffsetX, iy - collisionOffsetY, drawframe, colorOffset, iw, ih); }
|
|
| Top |
|
 |
fechdog
|
Post subject: Re: Item (Concept -> Programming) Posted: Sun Nov 09, 2008 11:08 pm |
|
 |
Joined: Sat Nov 08, 2008 3:05 pm Posts: 260 |
|
|
|
I didn't expect all that code going into the hammer!
|
|
| Top |
|
 |
Sonnitude
|
Post subject: Re: Item (Concept -> Programming) Posted: Sun Nov 09, 2008 11:08 pm |
|
 |
| Site Admin |
Joined: Thu Nov 06, 2008 8:52 pm Posts: 361 |
|
|
|
| Top |
|
 |
formula1
|
Post subject: Re: Item (Concept -> Programming) Posted: Sun Nov 09, 2008 11:16 pm |
|
 |
Joined: Sat Nov 08, 2008 9:17 pm Posts: 80 |
|
|
fechdog wrote: I didn't expect all that code going into the hammer! lol : P you want the source code? I could give you their SVN or just file by file. Either way, that all seems to be standard for a projectile weapon 1) Animation/graphics 2) Physics 3) Hit detection, if/then's (Blocks and Peoples) Other things are much shorter like mushrooms. But nobody really cares about mushrroms : /
|
|
| Top |
|
 |
Sonnitude
|
Post subject: Re: Item (Concept -> Programming) Posted: Sun Nov 09, 2008 11:18 pm |
|
 |
| Site Admin |
Joined: Thu Nov 06, 2008 8:52 pm Posts: 361 |
|
|
|
| Top |
|
 |
formula1
|
Post subject: Re: Item (Concept -> Programming) Posted: Sun Nov 09, 2008 11:20 pm |
|
 |
Joined: Sat Nov 08, 2008 9:17 pm Posts: 80 |
|
|
Sonnitude wrote: So you found the codes? The game is open source ^________________^ Not too hard to find. 
|
|
| Top |
|
 |
|
|