Continuing on with updates, I started on a few skills for the project. In the demo, the player's commands wasn't the standard Attack-Skills-Guard-Items but something like Play-Battle-Tactics-Items, where three of the commands were their own trees. In addition, Play and Battle targeted their own array of enemies, meaning you'd have to prioritize which enemies you had to face. It also means that Battle skills could never strike an enemy marked for Play, and the tree will even seal itself when there are no Battle enemies.
I could also restrain these skills further. Anything that requires a mouth, arms or legs would be sealed regardless of which skill tree it's in. Items would be delivered by a drone, which I can seal by having an enemy emit an EMP. Perhaps instead of a paralysis, I would simply seal the rest of the skills.
Games, Sprites and Scripts, courtesy of Polyedit2000.
7/29/19
Rubber Rubber Demo
Status: Tech Demo
Link: https://www.mediafire.com/file/mook897rptr6avc/Face2Face.zip/file
Here's a quick demo to show off that thing I started a few days ago. Not much at the moment, but it's a start.
Features:
-Talk to the green guy to change how these prototypes look.
-Talk to drone with the cat to see how the battle system works with an actual enemy on the field.
-Talke to the pink statue to see her in all her glory.
7/27/19
Who to Smack
Don't have a pic right now, but I managed to work the Vore DBS into the Rubber project. As a reminder, the Vore DBS's key feature would change what you can target. For this project, your targets are mainly influenced by your skill type.
Currently, there are three skill types planned:
-Fun- These only target rubber-bound enemies.
-Fight- These only target normal enemies.
-Survive- Aside from skills that help your party, the skills here can target any enemy (but can't damage them).
-Items- Pretty standard in any project.
Currently, there are three skill types planned:
-Fun- These only target rubber-bound enemies.
-Fight- These only target normal enemies.
-Survive- Aside from skills that help your party, the skills here can target any enemy (but can't damage them).
-Items- Pretty standard in any project.
7/25/19
Prob Solved
Changing how the face got randomized in the enemy didn't work somehow. Instead, I placed the randomization at the next imporant place: the sprites. Thankfully, this solution works and multiple copies have their own faces. Also, I've changed the randomization as well; it used to rescue into another branch when files didn't exist, but now I use the directory to find all related files. This means that I also removed the "default face" and the "number of faces", reducing the guesswork needed.
That is, you no longer need to label pictures as face1,face2,face3. You can name them as facebearded,facecheeky,face1.
Also, I added the Face-Toggle to this script. By typing a string into this method like "face", you can hide the face of battlers. Namely, if you happen to have a 2-faced naga, you can remove both of their faces.
That is, you no longer need to label pictures as face1,face2,face3. You can name them as facebearded,facecheeky,face1.
Also, I added the Face-Toggle to this script. By typing a string into this method like "face", you can hide the face of battlers. Namely, if you happen to have a 2-faced naga, you can remove both of their faces.
7/24/19
One Prob For Another
So far, I managed to upgrade the script to paste a face on a battler to have multiple layers, front and back. However, this currently works on one copy of an enemy (aka ABC). If I had two copies of an enemy (AA), the randomization doesn't take effect, though the default face will still work. I might have done something different with where the randomization takes place, so I'll look into that when I get home.
7/23/19
Rubbery Preview Garnered
I started a new side project to take a break from my main project and hopefully gain a new perspective. This is what I have so far: 3 battlers and a few faces to start. I have a snippet to randomize the hue and am using a script to randomize the face.
Features to add:
-More layer support for the face script, so I can add back hair and even tails/wings.
-"Battle System" to play with these foes. You'll still have regular skills to deal with interlopers.
-Some more randomization. Perhaps change the size and positioning too.
Tip: As I just discovered, RPG Maker's naming system is based on the name, not the battler id. This means that if you have three enemies with the same name, you can set up different poses or minor stat alterations.
7/22/19
7/19/19
Randomly Posting
If you couldn't tell, I'm posting each time I make minor adjustments. Hopefully I would have actual content sometime.
The last post was about Free Formation, turning a party of 1-2 into x-1-x-2. Now, if you have Hit 3 Random Enemies, you would be hitting one of those two twice, but with Free Formation in mind, it got me thinking about rocks that would hit a spot even if the actors weren't there. At the time, the snippet that would hit a spot regardless of whether it hit players or now had attacks based on its position.
I made a copy of that snippet and got it to work as a replacement for Random Attacks, even getting it to work on groups rather than one by one.
The last post was about Free Formation, turning a party of 1-2 into x-1-x-2. Now, if you have Hit 3 Random Enemies, you would be hitting one of those two twice, but with Free Formation in mind, it got me thinking about rocks that would hit a spot even if the actors weren't there. At the time, the snippet that would hit a spot regardless of whether it hit players or now had attacks based on its position.
I made a copy of that snippet and got it to work as a replacement for Random Attacks, even getting it to work on groups rather than one by one.
7/16/19
Free to Be Where I Be
I decided to add Himework's Free Formation to my main project. Normally, a party only has order so a party of three would be 1-2-3. Free Formation adds some "blank spots" so that I can arrange the party as 1-x-2-3. In a normal RPG Maker project, this is purely aesthetic. However, my main project does use "Line Attacks", or attacks that will strike a certain line (example: if an enemy only attacks the character in front of them), and it is surprisingly written for Free Formation's party placement.
That's not saying that the script was fully compatible with the game. While the battle side had no surprises, I had three other snippets that also played with party placement:
-Party Formation in Battle - This snippet swaps around characters in battle. I made a small edit to cap the swap to the current party. May have to change this again to see how the formation affects outside of battle. Also, should make a variable that functions like the battle switch but would limit the 4+ party swap outside of town.
-Party Formation in Menu - My current snippet would keep characters at their position, so swapping the leader would not place one person in the front. So far, I managed to make this snippet work by inflating the clone array to be similar to the positioning array and compacting it after the swaps, yet swapping a character to the 4th empty position would set that character to the spawn point. This may be because I've written non-existent characters to not really move, so I may have to update the movement system to move empty characters with the party.
-Party Rotation- Himework's script that rotates the current player of the party, aided with a snippet to keep characters at their position. It works by copying the formation code, but I'll have to see how this is affected by a party bigger than 4.
Also, the current Line Attacks are written with the enemy's position in mind, but I will probably write a Random Line Attack in case I want random attacks to strike positions rather than the remaining actor.
---
Edit: Solved it mostly. When sorted or summoned, the relocated character should appear 1-2 spaces from the next person. The bug was in multiple places, though I believe the main bug was because I have a return code in a method designed to return things, meaning it doesn't even return a proper nil.
That's not saying that the script was fully compatible with the game. While the battle side had no surprises, I had three other snippets that also played with party placement:
-Party Formation in Battle - This snippet swaps around characters in battle. I made a small edit to cap the swap to the current party. May have to change this again to see how the formation affects outside of battle. Also, should make a variable that functions like the battle switch but would limit the 4+ party swap outside of town.
-Party Formation in Menu - My current snippet would keep characters at their position, so swapping the leader would not place one person in the front. So far, I managed to make this snippet work by inflating the clone array to be similar to the positioning array and compacting it after the swaps, yet swapping a character to the 4th empty position would set that character to the spawn point. This may be because I've written non-existent characters to not really move, so I may have to update the movement system to move empty characters with the party.
-Party Rotation- Himework's script that rotates the current player of the party, aided with a snippet to keep characters at their position. It works by copying the formation code, but I'll have to see how this is affected by a party bigger than 4.
Also, the current Line Attacks are written with the enemy's position in mind, but I will probably write a Random Line Attack in case I want random attacks to strike positions rather than the remaining actor.
---
Edit: Solved it mostly. When sorted or summoned, the relocated character should appear 1-2 spaces from the next person. The bug was in multiple places, though I believe the main bug was because I have a return code in a method designed to return things, meaning it doesn't even return a proper nil.
7/15/19
Friends on the Inside
The danger of making your "big" game is that you have so many ideas you don't know where to begin, and without a beginning, you can't even plan the ending. So my theory to cure that is to craft a smaller game to bleed some of those ideas into there. No title for it yet.
Ideally, this small game would be a vore game. You would star as a person who would eventually have a whole population in your belly. Think of this like the Snake game I made, only without the party lag.
Ideally, this small game would be a vore game. You would star as a person who would eventually have a whole population in your belly. Think of this like the Snake game I made, only without the party lag.
7/10/19
One of a Kind
Surprisingly, the loot table snippet was shorter than I expected.
For the loot table, I put a notetag in an item, then when the item drops, it would see if there is a loot array before selecting one of those items instead. And as a shortcut, the item/armor type of the loot is based on the drop item.
As a reminder, the Smash Power/Difficulty slider would drop more items on higher difficulties, so a "drop set" can grant me Potions and Ethers.
For the loot table, I put a notetag in an item, then when the item drops, it would see if there is a loot array before selecting one of those items instead. And as a shortcut, the item/armor type of the loot is based on the drop item.
As a reminder, the Smash Power/Difficulty slider would drop more items on higher difficulties, so a "drop set" can grant me Potions and Ethers.
7/9/19
Pulling Out of the Tar Pit
I've been lazy, have I? Just trying to get back into RPG Maker. Started with two things on my current project:
1. The Smash Power concept of determining overall loot and damage (by comparing both sides) was replaced by a difficulty "slider". While it uses the same base code, the change would remove the extra layer of complexity on enemies and items.
2. The encounters were updated. Before, a map would have generated an enemy based on progress in a dungeon. The current change would have stronger fights show up with higher difficulties. I am also thinking for certain encounters to show up based on certain states or switches, but too early to tell at this point.
1. The Smash Power concept of determining overall loot and damage (by comparing both sides) was replaced by a difficulty "slider". While it uses the same base code, the change would remove the extra layer of complexity on enemies and items.
2. The encounters were updated. Before, a map would have generated an enemy based on progress in a dungeon. The current change would have stronger fights show up with higher difficulties. I am also thinking for certain encounters to show up based on certain states or switches, but too early to tell at this point.
Subscribe to:
Posts (Atom)