FA+
Shop
Cracked Open a YT Channel - Dedicated to Growth!
General | Posted 7 months agoHere's the channel: https://www.youtube.com/@MonsterGrowthMedia
At the time of this post, there's not too much on there right now, but I have a decent cache of content I'm planning on uploading over time.
Anyway, I think most of the people following me know me for my (somewhat limited) vore content, but monster growth is something I'm very much into, too. My intent is to showcase instances of growth showing up in different kinds of animated media (mainly in cartoon shows and anime). I know there are already a few dedicated channels to this, but there are still a lot of examples I can think of that seem to be undocumented online, so... here I am!
I mention it plenty of times in the channel, but if anyone here has any good examples of monsters growing in media, feel free to let me know, and I'll probably put them up on the channel, too!
And I guess, just to ask. Are there any websites dedicated to this type of media? Like, I know there are websites out there dedicated to vore, such as http://www.aryion.com, but there don't appear to be any related to monster growth. Not as much demand for the subject material, I guess? But if you know of any websites like that, I'd appreciate if you'd let me know!
At the time of this post, there's not too much on there right now, but I have a decent cache of content I'm planning on uploading over time.
Anyway, I think most of the people following me know me for my (somewhat limited) vore content, but monster growth is something I'm very much into, too. My intent is to showcase instances of growth showing up in different kinds of animated media (mainly in cartoon shows and anime). I know there are already a few dedicated channels to this, but there are still a lot of examples I can think of that seem to be undocumented online, so... here I am!
I mention it plenty of times in the channel, but if anyone here has any good examples of monsters growing in media, feel free to let me know, and I'll probably put them up on the channel, too!
And I guess, just to ask. Are there any websites dedicated to this type of media? Like, I know there are websites out there dedicated to vore, such as http://www.aryion.com, but there don't appear to be any related to monster growth. Not as much demand for the subject material, I guess? But if you know of any websites like that, I'd appreciate if you'd let me know!
MUGEN Coding Commissions?
General | Posted 2 years agoI guess I might as well ask; is there any market out there for spriters/animators who want to make vore elements for MUGEN, but don't know how to actually implement them with importing/coding via FighterFactory?
I personally feel like the coding end is relatively simple, as it really does just require a lot of copying and pasting from existing sources and then tweaking them the way you want, but I also get that it might just not be for everyone anyway. The artistry aspect of it is something that's very difficult for me, after all.
Anyway, I figured I'd see if there's any interest in this. I'd love to see more vore content in MUGEN, and hey maybe I'd be able to make this into a side hustle or something, iunno.
Give me a holler if you want to get something started!
I personally feel like the coding end is relatively simple, as it really does just require a lot of copying and pasting from existing sources and then tweaking them the way you want, but I also get that it might just not be for everyone anyway. The artistry aspect of it is something that's very difficult for me, after all.
Anyway, I figured I'd see if there's any interest in this. I'd love to see more vore content in MUGEN, and hey maybe I'd be able to make this into a side hustle or something, iunno.
Give me a holler if you want to get something started!
Information About Scyther
General | Posted 5 years agoI'm going to go ahead and list out the primary differences between a standard vore edit character and what I was able to manage to put into Scyther. As I said with the original submission, I'm hoping that all this work will help inspire others to either start their own vore edit projects, or even push what they already have even further.
Also check out Scyther here if you haven't already: https://www.furaffinity.net/view/40711058/
Sprite Layering
I made a submission of the spritesheet I used to develop Scyther here: https://www.furaffinity.net/view/40711373/
The important takeaway you should get from this is that, since a vore character's belly is generally between their arms and legs, and the goal is to have the belly move independently from the main character, different sprites will need to be made of the character's body parts so they can be layered via coding. In the case of Scyther, there were three main elements to his layering. From back to front, it would be: most of his main body, then the belly, and then his front arm and leg.
There were two main poses Scyther could be in while having swallowed an enemy: standing straight up, and leaning forward a bit. In those cases, the sprites of the main body, and the sprites of the front limbs were made separately, and then layered together using MUGEN's coding.
The belly doesn't need to be sprited differently based on Scyther's position, so I didn't need to make any special exceptions for that. Its sprites were exclusively just the struggling animations and nothing else.
One other note is that, if Scyther is in a scripted position (swallowing, spitting up, digesting etc.), where the opponent is not meant to be able to struggle, then sprite layering wouldn't be needed in that case. You can see that I just wholesale made the entire sprites in those cases.
Coding the Vore Attempt and Swallow
Compared to the other aspects of Scyther's vore coding, there isn't too much here that differs from your standard vore edit. But there are a few things I'd like to point out, as they are helpful to know.
In the Vore Attempt's HitDef, there are a few good practices you should enforce:
[state 3000, HitDef]
type = hitdef
Trigger1 = 1
attr = S, NT
.....(S means that the move is a standing attack, and NT means that the move is a normal throw; unblockable, but won't connect if the opponent is airborne, in hitstun, or in blockstun.)
hitflag = M
priority = 8, hit
sparkno = -1
hitsound = S6, 0
p1sprpriority = 4
ID = 10
.....(ID is important, as it sets an ID number on the opponent that can be used for further manipulation. You'll see coding later on in this entry reference ID 10; this will make it so only the swallowed target is affected, and not a secondary opponent in the case of a team battle. If you code a double vore move, give them a different ID, and manipulate both targets separately.)
p1stateno = 3001
p2stateno = YYYY
.....(p2stateno will send the target to a state that exists in YOUR state files. Create a state YYYY that uses selfstate to put the target in their own state 5150 and you can effectively bind them.)
guard.dist = 0
fall.recover = 0
p2facing = 1
hitonce = 1
.....(HitOnce = 1 will make it so you can only hit one target, which is important in the case of a team battle. If you code a double vore move, set HitOnce to 0 on that one, otherwise you'll drop the original target.)
Once you've made it to your Swallowing state, make sure to enforce TargetBind on them like always:
[State 3001, Move Target to Mouth]
type = TargetBind
trigger1 = Animelem = 1
pos = 85, -50
ID = 10
You'll note that ID = 10 is being referenced even here, to make sure that a second opponent is not affected by any of this.
You should also use the very end of the Swallowing state to spawn in the separate sprites for Scyther's belly. We do this using a Helper, which is effectively a copy of your character, which can perform its own tasks. For the purposes of this vore edit, it's going to be the belly the entire time.
[State 3001, Generate Belly]
type = Helper
trigger1 = AnimTime = 0
.....(AnimTime = 0 means that this activates at the exact moment the Swallowing animation ends.)
ID = 4000
.....(Helpers have their own ID that need to be set.)
pos = 0,0
.....(Pos indicates where on Scyther's body the belly should be attached. Since we didn't make context sensitive animations for the belly based on which pose Scyther is in, we'll need to adjust this value so it stays attached in the right spot.)
postype = back
stateno = 4000
.....(This indicates that the Helper's starting state will be 4000. In this case, it's the entire control state for the belly and its animations.)
helpertype = normal
name = "Belly"
keyctrl = 0
ownpal = 0
The Belly's Coding
With the belly in place as a Helper, there are some special exceptions in coding that need to be made. Remember that, as a Helper, the belly is effectively just a 'second Scyther,' which receives its own commands.
As a note, we spawned in the belly as a Helper in this roundabout way, as there's no way to directly enforce your own animations onto the opponent. The best we can do is make the opponent invisible and have our 'second Scyther' do all of the animating.
[Statedef 4000]
type = A
movetype= H
physics = N
anim = 4000
velset = 0,0
sprpriority = 5
I want to point out sprpriority here. This basically determines how each sprite is layered on Scyther. His main body has an sprpriority of 1, the belly, of 5, and the front limbs, of 10. This ensures the elements are stacked properly, and the belly is properly sandwiched between.
[State 4000, Attach Belly to Scyther]
type = BindtoParent
trigger1 = parent, var(24) = 0
pos = 0,0
[State 4000, Move Belly in Certain Situations]
type = BindtoParent
trigger1 = parent, var(24) = 1
pos = 0,5.2
Later on in the coding, var(24) is used to state whether Scyther is standing up straight or leaning forward. These lines of code detect which position he's in and move the belly accordingly.
[State 4000, Despawn Belly]
type = DestroySelf
trigger1 = parent, var(24) = 2
DestroySelf is the only way to make a Helper despawn itself.
[State 4000, Struggle Down]
type = changeanim
trigger1 = anim = 4000
trigger1 = var(19) = 0
trigger1 = root,cond(numtarget,target,cond(1,command = "holddown",0),0)
value = 4003
trigger1 = root,cond(numtarget,target,cond(1,command = "command",0),0) is an extremely important line of code here. Helpers are NOT able to use the typical "target, command" coding that normal vore characters are able to. This line of code, however, is its equivalent specifically for Helpers.
The Front Limbs
Since the front limbs don't really require input to animate, they aren't spawned in as Helpers. Instead, they are spawned in as Exlpods, which are basically just particle effects.
[State 3002, Higher Front Arm]
type = Explod
trigger1 = var(24) = 0
anim = 6000
ID = 6000
postype = p1
pos = 0,0
scale = 1.7,1.7
sprpriority = 10
bindtime = -1
RemoveTime = -1
(You'll note that var(24) is being read here too.)
I have this trigger (or the var(24) = 1 equivalent) in each individual vore state Scyther has. You'll also note that this has its own ID, too.
Explods can't despawn by themselves, so you'll also need to include coding to make sure they go away in the right situations.
[State 3002, Remove Higher Front Arm]
type = RemoveExplod
trigger1 = var(24) = 1
ID = 6000
There's a lot more I can go over, but I would recommend just going through my coding at this point. I left in helpful information about Scyther's vore coding in as many spots as I could in his .def file. With that, as well as descriptions for the most essential functions of Scyther's vore here, you should be able to get yourself started.
That said, I'm also happy to help answer any coding-related questions you may have about MUGEN. Let me know if you have any!
Also check out Scyther here if you haven't already: https://www.furaffinity.net/view/40711058/
Sprite Layering
I made a submission of the spritesheet I used to develop Scyther here: https://www.furaffinity.net/view/40711373/
The important takeaway you should get from this is that, since a vore character's belly is generally between their arms and legs, and the goal is to have the belly move independently from the main character, different sprites will need to be made of the character's body parts so they can be layered via coding. In the case of Scyther, there were three main elements to his layering. From back to front, it would be: most of his main body, then the belly, and then his front arm and leg.
There were two main poses Scyther could be in while having swallowed an enemy: standing straight up, and leaning forward a bit. In those cases, the sprites of the main body, and the sprites of the front limbs were made separately, and then layered together using MUGEN's coding.
The belly doesn't need to be sprited differently based on Scyther's position, so I didn't need to make any special exceptions for that. Its sprites were exclusively just the struggling animations and nothing else.
One other note is that, if Scyther is in a scripted position (swallowing, spitting up, digesting etc.), where the opponent is not meant to be able to struggle, then sprite layering wouldn't be needed in that case. You can see that I just wholesale made the entire sprites in those cases.
Coding the Vore Attempt and Swallow
Compared to the other aspects of Scyther's vore coding, there isn't too much here that differs from your standard vore edit. But there are a few things I'd like to point out, as they are helpful to know.
In the Vore Attempt's HitDef, there are a few good practices you should enforce:
[state 3000, HitDef]
type = hitdef
Trigger1 = 1
attr = S, NT
.....(S means that the move is a standing attack, and NT means that the move is a normal throw; unblockable, but won't connect if the opponent is airborne, in hitstun, or in blockstun.)
hitflag = M
priority = 8, hit
sparkno = -1
hitsound = S6, 0
p1sprpriority = 4
ID = 10
.....(ID is important, as it sets an ID number on the opponent that can be used for further manipulation. You'll see coding later on in this entry reference ID 10; this will make it so only the swallowed target is affected, and not a secondary opponent in the case of a team battle. If you code a double vore move, give them a different ID, and manipulate both targets separately.)
p1stateno = 3001
p2stateno = YYYY
.....(p2stateno will send the target to a state that exists in YOUR state files. Create a state YYYY that uses selfstate to put the target in their own state 5150 and you can effectively bind them.)
guard.dist = 0
fall.recover = 0
p2facing = 1
hitonce = 1
.....(HitOnce = 1 will make it so you can only hit one target, which is important in the case of a team battle. If you code a double vore move, set HitOnce to 0 on that one, otherwise you'll drop the original target.)
Once you've made it to your Swallowing state, make sure to enforce TargetBind on them like always:
[State 3001, Move Target to Mouth]
type = TargetBind
trigger1 = Animelem = 1
pos = 85, -50
ID = 10
You'll note that ID = 10 is being referenced even here, to make sure that a second opponent is not affected by any of this.
You should also use the very end of the Swallowing state to spawn in the separate sprites for Scyther's belly. We do this using a Helper, which is effectively a copy of your character, which can perform its own tasks. For the purposes of this vore edit, it's going to be the belly the entire time.
[State 3001, Generate Belly]
type = Helper
trigger1 = AnimTime = 0
.....(AnimTime = 0 means that this activates at the exact moment the Swallowing animation ends.)
ID = 4000
.....(Helpers have their own ID that need to be set.)
pos = 0,0
.....(Pos indicates where on Scyther's body the belly should be attached. Since we didn't make context sensitive animations for the belly based on which pose Scyther is in, we'll need to adjust this value so it stays attached in the right spot.)
postype = back
stateno = 4000
.....(This indicates that the Helper's starting state will be 4000. In this case, it's the entire control state for the belly and its animations.)
helpertype = normal
name = "Belly"
keyctrl = 0
ownpal = 0
The Belly's Coding
With the belly in place as a Helper, there are some special exceptions in coding that need to be made. Remember that, as a Helper, the belly is effectively just a 'second Scyther,' which receives its own commands.
As a note, we spawned in the belly as a Helper in this roundabout way, as there's no way to directly enforce your own animations onto the opponent. The best we can do is make the opponent invisible and have our 'second Scyther' do all of the animating.
[Statedef 4000]
type = A
movetype= H
physics = N
anim = 4000
velset = 0,0
sprpriority = 5
I want to point out sprpriority here. This basically determines how each sprite is layered on Scyther. His main body has an sprpriority of 1, the belly, of 5, and the front limbs, of 10. This ensures the elements are stacked properly, and the belly is properly sandwiched between.
[State 4000, Attach Belly to Scyther]
type = BindtoParent
trigger1 = parent, var(24) = 0
pos = 0,0
[State 4000, Move Belly in Certain Situations]
type = BindtoParent
trigger1 = parent, var(24) = 1
pos = 0,5.2
Later on in the coding, var(24) is used to state whether Scyther is standing up straight or leaning forward. These lines of code detect which position he's in and move the belly accordingly.
[State 4000, Despawn Belly]
type = DestroySelf
trigger1 = parent, var(24) = 2
DestroySelf is the only way to make a Helper despawn itself.
[State 4000, Struggle Down]
type = changeanim
trigger1 = anim = 4000
trigger1 = var(19) = 0
trigger1 = root,cond(numtarget,target,cond(1,command = "holddown",0),0)
value = 4003
trigger1 = root,cond(numtarget,target,cond(1,command = "command",0),0) is an extremely important line of code here. Helpers are NOT able to use the typical "target, command" coding that normal vore characters are able to. This line of code, however, is its equivalent specifically for Helpers.
The Front Limbs
Since the front limbs don't really require input to animate, they aren't spawned in as Helpers. Instead, they are spawned in as Exlpods, which are basically just particle effects.
[State 3002, Higher Front Arm]
type = Explod
trigger1 = var(24) = 0
anim = 6000
ID = 6000
postype = p1
pos = 0,0
scale = 1.7,1.7
sprpriority = 10
bindtime = -1
RemoveTime = -1
(You'll note that var(24) is being read here too.)
I have this trigger (or the var(24) = 1 equivalent) in each individual vore state Scyther has. You'll also note that this has its own ID, too.
Explods can't despawn by themselves, so you'll also need to include coding to make sure they go away in the right situations.
[State 3002, Remove Higher Front Arm]
type = RemoveExplod
trigger1 = var(24) = 1
ID = 6000
There's a lot more I can go over, but I would recommend just going through my coding at this point. I left in helpful information about Scyther's vore coding in as many spots as I could in his .def file. With that, as well as descriptions for the most essential functions of Scyther's vore here, you should be able to get yourself started.
That said, I'm also happy to help answer any coding-related questions you may have about MUGEN. Let me know if you have any!
Growth in MUGEN
General | Posted 6 years agoI'm trying to figure out how to make characters grow (and shrink) in MUGEN. Here's the progress I've made so far.
In [Statedef -2], which is active at all times, I slapped in the following:
[State -2, SizeChange]
type = angledraw
trigger1 = 1=1
scale = 1+fvar(X),1+fvar(Y)
and then, on a move where I want the character to grow (or shrink), I used the following:
[State]
type = varadd
trigger1 = get creative here, though using "animelem = B" for a single spurt of growth, and "gametime%C = D" or "gametime%C >= D" for gradual growth will usually suffice.
fvar(X) = the number here will decide how much the character will grow. Just keep in mind the numbers will usually have to be very small decimals, as an increase of 1 in this variable will make the character instantly double in size.
[State]
type = varadd
trigger1 = same deal, make sure it matches the trigger for fvar(X)
fvar(Y) = this should be the same as the value you placed in fvar(X)
I really enjoy the concepts of absorption and growth mixed in with vore, so I'm glad I was able to make some headway on this. On top of that, we already know how to increase and decrease both the player's and the opponent's HP and Power bars, and there's probably a way to alter both players' Attack and Defense stats, so all of that could lend itself further to the effects of absorption during vore moves.
.
.
.
.
.
Of course, there are still a few problems with just the simple coding I've come up with so far.
The main issue is that the "angledraw" modifier in Statedef -2 is quite literal in its name; it DRAWS your character with a different scale, without actually changing anything about the sizes of hitboxes and hurtboxes. As a result, you could grow a character to a large size, but all of their attacks would be performed as if the size had never changed. As a large character, you could visually reach across the whole screen, but the attack would not actually make contact with the opponent. And as a small character, you could have a big visual distance between you and the opponent, but somehow your attacks would still be able to make contact. To solve this, I'll have to figure out how to make hitboxes and hurtboxes change alongside the growth caused by angledraw.
The next issue is that I can't seem to find a way to apply angledraw to the opponent fighter. While not necessary, it would definitely be a good time to have the option to cause the opponent to shrink as a result of using a move that absorbs on them. The solution to this might not exist, as size changing effects as I know them apply to Statedef -2, and I don't think fighters have access to modifying the opponent's Statedef -2. Of course, if anyone has any ideas to this one, let me know and I can test them out.
Finally, and this one is definitely not a big deal either, but when it comes to vore in MUGEN, most of the characters are already behemoths that take up a large amount of the screen. I want to work on a new vore character in MUGEN using the growth mechanic that I'm working on, but the character should probably be a mid-small fighter, so you can really appreciate the effects of the growth and absorption during battle.
.
.
.
.
.
With that last concern in mind, I'm going to ask you guys for ideas. Obviously I'm not in the market for making an entire character from scratch, because spritework is hell, so I'd rather modify an existing character for vore, like I've done with Breloom and Petey Piranha so far. Here are the parameters that I'm looking for in a potential new vore character:
- Has a naturally medium-small size by default.
- Has potential for a non-vore absorption move (For example: Breloom's Drain Punch)
- And this one is my preference: Is a dragon, lizard, or anthropomorphized plant or bug monster of some kind.
With all of those qualifiers, Breloom IMMEDIATELY comes to mind as a candidate. Problem is, I've already created a vore moveset for him, and I'd like to see if there are any other potential choices to pick from. I've taken multiple looks through the online MUGEN fighter databases, but could never seem to find anyone to fit the bill. If I can't think of anything, I'll probably just work on Breloom since he would probably use these new mechanics to great effect, but I'll keep looking on this front. If you guys have any ideas though, I'm all ears. Give me all you got!
In [Statedef -2], which is active at all times, I slapped in the following:
[State -2, SizeChange]
type = angledraw
trigger1 = 1=1
scale = 1+fvar(X),1+fvar(Y)
and then, on a move where I want the character to grow (or shrink), I used the following:
[State]
type = varadd
trigger1 = get creative here, though using "animelem = B" for a single spurt of growth, and "gametime%C = D" or "gametime%C >= D" for gradual growth will usually suffice.
fvar(X) = the number here will decide how much the character will grow. Just keep in mind the numbers will usually have to be very small decimals, as an increase of 1 in this variable will make the character instantly double in size.
[State]
type = varadd
trigger1 = same deal, make sure it matches the trigger for fvar(X)
fvar(Y) = this should be the same as the value you placed in fvar(X)
I really enjoy the concepts of absorption and growth mixed in with vore, so I'm glad I was able to make some headway on this. On top of that, we already know how to increase and decrease both the player's and the opponent's HP and Power bars, and there's probably a way to alter both players' Attack and Defense stats, so all of that could lend itself further to the effects of absorption during vore moves.
.
.
.
.
.
Of course, there are still a few problems with just the simple coding I've come up with so far.
The main issue is that the "angledraw" modifier in Statedef -2 is quite literal in its name; it DRAWS your character with a different scale, without actually changing anything about the sizes of hitboxes and hurtboxes. As a result, you could grow a character to a large size, but all of their attacks would be performed as if the size had never changed. As a large character, you could visually reach across the whole screen, but the attack would not actually make contact with the opponent. And as a small character, you could have a big visual distance between you and the opponent, but somehow your attacks would still be able to make contact. To solve this, I'll have to figure out how to make hitboxes and hurtboxes change alongside the growth caused by angledraw.
The next issue is that I can't seem to find a way to apply angledraw to the opponent fighter. While not necessary, it would definitely be a good time to have the option to cause the opponent to shrink as a result of using a move that absorbs on them. The solution to this might not exist, as size changing effects as I know them apply to Statedef -2, and I don't think fighters have access to modifying the opponent's Statedef -2. Of course, if anyone has any ideas to this one, let me know and I can test them out.
Finally, and this one is definitely not a big deal either, but when it comes to vore in MUGEN, most of the characters are already behemoths that take up a large amount of the screen. I want to work on a new vore character in MUGEN using the growth mechanic that I'm working on, but the character should probably be a mid-small fighter, so you can really appreciate the effects of the growth and absorption during battle.
.
.
.
.
.
With that last concern in mind, I'm going to ask you guys for ideas. Obviously I'm not in the market for making an entire character from scratch, because spritework is hell, so I'd rather modify an existing character for vore, like I've done with Breloom and Petey Piranha so far. Here are the parameters that I'm looking for in a potential new vore character:
- Has a naturally medium-small size by default.
- Has potential for a non-vore absorption move (For example: Breloom's Drain Punch)
- And this one is my preference: Is a dragon, lizard, or anthropomorphized plant or bug monster of some kind.
With all of those qualifiers, Breloom IMMEDIATELY comes to mind as a candidate. Problem is, I've already created a vore moveset for him, and I'd like to see if there are any other potential choices to pick from. I've taken multiple looks through the online MUGEN fighter databases, but could never seem to find anyone to fit the bill. If I can't think of anything, I'll probably just work on Breloom since he would probably use these new mechanics to great effect, but I'll keep looking on this front. If you guys have any ideas though, I'm all ears. Give me all you got!
