<![CDATA[hiddenone's Resource Warehouse - Game Making]]>Sun, 09 May 2021 12:33:25 -0700Weebly<![CDATA[Storing Information: An Abuse of Arrays]]>Mon, 27 May 2019 17:00:00 GMThttps://www.hiddenone-sprites.com/game-making/storing-information-an-abuse-of-arraysInformation is a super important part of my game, since without it how could players choose which Hero to send to which World?  So finding a good way to share all that info is something I've been spending a lot of time on, as you can see with the current version of the World Info sheet:
Picture
There's a lot of room for details there, but how is it all stored in the game?  In variable arrays.
Variable arrays are possibly the most used thing in my game right now, I use them to store all sorts of info, from the Hero details to the MC's current mood and employment status.

Which means I have a pretty big autoevent that sets everything up.  That's not too bad, but it did make it hard to look at the event and be able to easily judge what each script call was setting up.
Picture
A shortened version of the first autoevent iteration.
Just look at that horizontal scroll bar!  It may not be too tough to find right variable like that, but it is definitely tough to make sure I'm tweaking the right part of the array when I'm testing things.

​I knew I needed to change how I set these up, just for my own ease of use.  So I decided to have only one variable per script call, and separated each section with a comment just so that I can quickly tell what I'm looking at.  I also used one of the minor bonuses of arrays, the comma, to break up the script call onto multiple lines.  Now while the event is much longer to scroll thru, it's much easier on me to be able to find just what I'm looking for.
Picture
Part of the current event.
I'm happy with how the event is set up now, since I can make edits to things as I go a lot more easily now.  It makes adding new Heroes and Worlds a lot simpler, which is great!  Now I can add as much as I want without ending up too lost in the event.
]]><![CDATA[Why Reincarnation Assistant?]]>Mon, 20 May 2019 17:00:00 GMThttps://www.hiddenone-sprites.com/game-making/why-reincarnation-assistantInstead of another week of eventing details, I thought it'd be fun to explain why I'm even making this game.  I'll be setting it up as a question-and-answer thing, so if you have any questions of your own feel free to ask them in the comments!

Why make a game? You're a resource creator, not a game dev!

It honestly seems to surprise some people when I tell them I like to make games.  That's what got me involved with making resources in the first place, I wanted some sprites that didn't exist for my project so I learned how to make them.

My main love has always been games, and finding new ways to make RPG Maker do what I want it to.  Making resources is fun too, but just can't compete with bringing a project to life.

Why Isekai?

The reason is stupidly simple: I was reading a lot of isekai stories when I came up with the idea for Reincarnation Assistant.

The whole idea of isekai lends the perfect backdrop for a game where you have to send the right people to do certain jobs.  It also means I can mix and blend concepts from genres like fantasy and sci-fi naturally, since summoning people from multiple worlds means I'm not trapped in a single genre.

Why a business office?

Because it's an uncommon location for RPG Maker games, and it's funny.  I could have set the game in a fantasy temple, but that makes it feel more serious to me.  The juxtaposition between fantastical concept and the sterile feel of an office building just felt more amusing to me.  And since I want this to be a comedic game, setting it in an office made the most sense.

Who is the player character?

The player takes control of Mana (who they can rename, if they want), a new person at the company who takes on the job of assistant to a very laze God of Reincarnation.

The player can choose between three appearances: man, woman, and tentacle blob.  Mana's personality is formed by player choice, so the more you choose the 'sarcastic' option the more likely Mana will reply to comments with a snarky comeback (of course, you could make Mana polite as well).
Picture
The three current appearances for Mana

How many possible heroes and worlds will there be?

As many as I can come up with!

A more serious answer would be around 20 of each.  That feels like a good number to me, enough to give players a lot to do and play around with without making so much work that the game will never get done.  I'm planning on having at least a few different reasons for each world to need a hero, so even if there are only 20 worlds there will still be a lot to do even if you have sent a hero to each world once.
Those are some of the questions I thought would be interesting to have answers to, but if y'all have other ones just comment and let me know!
]]><![CDATA[Sharing Hero Information - Superhero Stat Cards]]>Mon, 13 May 2019 17:00:00 GMThttps://www.hiddenone-sprites.com/game-making/sharing-hero-information-superhero-stat-cardsInformation about the available heroes in my game is important, since knowing enough about the hero could be the difference between sending them to a world that they can help, and sending them to a world that will eat them up and spit out their bones.  But too much info could be just as bad, since the player could end up confused about which info in important to know and what's just there to fill space (the hero's race was one box I considered adding, but decided that the image should convey that info well enough).  So I needed to find a way to get enough info across, without overwhelming the player.

There's already been a lot of improvement from the first version, but there's still more I know can be improved.
Picture
The biggest issue I was having was with the actual stat box.  I put numbers in it, but exact numbers aren't going to be important when picking a hero.  Obviously choosing a hero with a low Attack to send to a world that needs a strong warrior would be a bad idea, but it wouldn't matter if the hero had an Attack of 8 or 9.

So I considered using words instead.  It gives the player enough info without dealing in numbers... But something still wasn't feeling quite right.
Picture
Numbers vs. words: which is better?
That's when Biestmann on the forum made an amazing recommendation: using an icon-based rating.  It shows all the info I want, and even fits the look I want better than words!  So I went ahead and added them in.
I'm hearing mixed opinions on whether the different ratings should have different colors or not, but luckily it's simple enough to switch the numbers in the \i[n] icon command. ^^

Since icons don't take up all that much space, I could resize and reorganize the entire hero info layout.  Now it should be easy for the player to take a quick glance at the info and see what's important.
Picture
Yes, his name is Example Hero. He's the Harold of Reincarnation Assistant's available heroes
Information for the world's is set up in a similar manner, though it still needs tweaking.  But it shows the most important thing, the 'Hero needed:' box, and that means I can rough out the hero selection mechanic now to allow for more heroes and more randomization.
Picture
Example-opolis is not the most exciting world, but at least it exists
]]><![CDATA[Eventing a Picture-Based Menu]]>Mon, 06 May 2019 17:00:00 GMThttps://www.hiddenone-sprites.com/game-making/eventing-a-picture-based-menuSince so little of Reincarnation Assistant is a normal RPG, the default menu just doesn't fit.  Instead of finding or requesting a plugin, I decided to event it.

This isn't a tutorial, just a look at how I'm doing things.  If y'all would like a more in-depth tutorial, leave a comment and let me know.

 First Iteration - Putting the basics in

Time to get the basics in.  I only need Items, Save, and Exit really, so I can just start with three pictures and highlight the one the player is currently choosing.
Picture
A lot of the basics stay the same between each iteration, so I'll just go over the main things quickly.
◆Change Menu Access：Disable◆Control Variables：#0001 Random # = 5◆Show Picture：#5, menu_item_icon, Center (288,324), (100%,100%), 255, Normal◆Show Picture：#6, menu_save_icon, Center (576,324), (100%,100%), 200, Normal◆Show Picture：#7, menu_exit_icon, Center (864,324), (100%,100%), 200, Normal
This sets up which picture the menu starts on, and adds all the images to the screen.

The rest of the event (minus the very last command) is put into a loop, so that it will repeat until the player want to leave the menu.
  ◆If：Script：(Input.isTriggered('right')) || (TouchInput.isTriggered('right'))    ◆Control Variables：#0001 Random # += 1    ◆If：Random # = 8      ◆Control Variables：#0001 Random # = 5      ◆    ：End    ◆  ：End  ◆If：Script：(Input.isTriggered('left')) || (TouchInput.isTriggered('left'))    ◆Control Variables：#0001 Random # -= 1    ◆If：Random # = 4      ◆Control Variables：#0001 Random # = 7      ◆    ：End    ◆  ：End  ◆If：Script：(Input.isTriggered('ok')) || (TouchInput.isTriggered('ok'))    ◆If：Random # = 5      ◆Script：SceneManager.push(Scene_Item);      ◆Break Loop      ◆    ：End    ◆If：Random # = 6      ◆Script：SceneManager.push(Scene_Save);      ◆    ：End    ◆If：Random # = 7      ◆Show Choices：Exit Game, Return to menu (Window, Middle, #1, #2)      ：When Exit Game         ◆Script：SceneManager.goto(Scene_Title);        ◆      ：When Return to menu         ◆      ：End      ◆    ：End    ◆  ：End  ◆If：Script：(Input.isTriggered('cancel')) || (TouchInput.isTriggered('cancel'))    ◆Break Loop    ◆  ：End
Some conditional branches to check which buttons are being pushed.  If the player hits the right arrow key then the choice moves to the the right, and if the player hits enter then it selects the highlighted menu option.

The variable is set to not go beyond 5-7 just because those are the picture IDs I choose.  There's no deep meaning to it, but it is important to know for the next part of the event:
  ◆Comment：Change picture tints  ◆If：Random # = 5    ◆Show Picture：#5, menu_item_icon, Center (288,324), (100%,100%), 255, Normal    ◆Show Picture：#6, menu_save_icon, Center (576,324), (100%,100%), 200, Normal    ◆Show Picture：#7, menu_exit_icon, Center (864,324), (100%,100%), 200, Normal    ◆  ：End  ◆If：Random # = 6    ◆Show Picture：#5, menu_item_icon, Center (288,324), (100%,100%), 200, Normal    ◆Show Picture：#6, menu_save_icon, Center (576,324), (100%,100%), 255, Normal    ◆Show Picture：#7, menu_exit_icon, Center (864,324), (100%,100%), 200, Normal    ◆  ：End  ◆If：Random # = 7    ◆Show Picture：#5, menu_item_icon, Center (288,324), (100%,100%), 175, Normal    ◆Show Picture：#6, menu_save_icon, Center (576,324), (100%,100%), 175, Normal    ◆Show Picture：#7, menu_exit_icon, Center (864,324), (100%,100%), 255, Normal    ◆  ：End  ◆Wait：1 frame
This is where the event changes the picture that's highlighted.

The wait is there because otherwise the event tries to run constantly, and lags the whole game.
◆Script：for (var i = 5; i < 7+1; i++){ ：Script：$gameScreen.erasePicture(i); }
After leaving the menu, it's important to erase all the pictures so they're not in the way.  Instead of using a bunch of Erase Picture commands, I use this one to get rid of all of them at once.

So the menu works, but it's not all the exciting... Time to complicate it!

Second Ite​ration - You spin me right 'round baby

Instead of having the pictures stay static, it's a lot more interesting to have them move to be centered when they're selected.  It doesn't take too much extra work to do it really, just have to set up some move picture commands in the conditional branches.
Picture
I did need to add in a fail-safe though, since the menu will try to keep moving the pictures and lock up without them.
  ◆Control Variables：#0009 namebox icon test = Random #
I find another variable that doesn't need to remain the same during the game, and set it to equal the menu variable at the very start of the loop.  That way it will not change even if the player hits left or right until the next loop occurs.
  ◆If：Random # ≠ namebox icon test    ◆Conditional branches go here!  ：End
Then all I need to do is put all the move picture conditional branches in the above conditional branch.  It simply checks to see if the player hit the arrow keys, if they did then the variables won't match and the pictures will move and if the variables do match then the event skips it.

Now the menu looks a lot more interesting, but there are still issues.  The pictures are tied to IDs, which means some of them move under other pictures but over the last one and that can look a bit odd.  I needed to find a way to alleviate that issue.

Third Iteration - Adding some extra spin

My awesome coding buddy Galenmereth released a cool plugin that let me put in some fancy movement to the pictures, so I grabbed it and ran with it.

Instead of having the pics in a straight line, I set them up in an oval so it looks like they're rotating into place.  To make it easier on the player to see, I put in a background to hide the map.

I also added an Options menu option, since it makes sense to let the player change music volume and such while playing.
Picture
While setting up the plugin commands for that plugin, I realized that I could condense all the conditional branches into a few script calls if I was smart.
    ◆Plugin Command：AnimationCurve BackOut    ◆Script：if ($gameVariables.value(1) == 5 ) {var left = 8} else {var left = ($gameVariables.value(1) - 1)}    ：Script：$gameScreen.movePicture(left, 1, 288, 250, 75, 75, 200, 0, 30);    ◆Plugin Command：AnimationCurve BackOut    ◆Script：$gameScreen.movePicture($gameVariables.value(1), 1, 576, 324, 100, 100, 255, 0, 30);    ◆Plugin Command：AnimationCurve BackOut    ◆Script：if ($gameVariables.value(1) == 8 ) {var right = 5} else {var right = ($gameVariables.value(1) + 1)}    ：Script：$gameScreen.movePicture(right, 1, 864, 250, 75, 75, 200, 0, 30);    ◆Plugin Command：AnimationCurve BackOut    ◆Script：if ($gameVariables.value(1) == 7 ) {    ：Script：var back = 5} else if ($gameVariables.value(1) == 8 ) {    ：Script：var back = 6} else {    ：Script：var back = ($gameVariables.value(1) + 2)}    ：Script：$gameScreen.movePicture(back, 1, 576, 150, 50, 50, 150, 0, 30);
Using script calls meant that I could check the menu variable and up keywords (like 'left' and 'right') so that the proper picture is moved.  It's a lot simpler than having four conditional branches that have all the commands for each layout possibility.

​The menu is close to what I wanted now, so the last step is to add in just a few details to make it easier for the player to navigate.

Current Iteration 

Happy with the new spin, all the event needed was a few labels (added with kido0617's Window Manager plugin) so that it was clear which picture does what.  For now, I've made what I wanted so I can move onto the next thing.
Picture
Now that I'm happy with my abilities to event again, I'm ready to jump back into getting the main mechanics implemented...

I see a lot of variables in my future.
]]><![CDATA[Deciding on a style, & How to Resize Ace tiles]]>Mon, 29 Apr 2019 17:00:00 GMThttps://www.hiddenone-sprites.com/game-making/deciding-on-a-style-how-to-resize-ace-tilesWhile working on the mechanics for my project, I realized that since the game all takes place in an office building that I should go through my immense collection of graphic packs and see if any work fit.  And I found one!  The DS+ pack has a lot of tiles that are perfect for a modern office, and it's in a nice pixel style too.  There is a problem though...

The pack is for Ace, not MV.  While I could use a plugin to have the tiles all work well, I didn't want the maps to all feel really small due to the different between tile size and resolution, so I've decided to resize the tiles to work.
Picture
Resizing all the tiles is still a work in progress
Unfortunately Ace tiles can't just be doubled to work in MV.  Since I'm sure there are other people who'd like to know a way to do it, here's my method!

Resizing Ace (32x32 pixels) tiles to fit MV (48x48 pixels)

Picture
Step 1: Resize
First things to do is resize the tile by 150%, with Nearest Neighbor turned on.  That will keep things from blurring, though it does mean we have uneven spots in the tile (compare the top of the paper holder to the bottom and you'll see what I mean).
Picture
Step 2: Remove all double pixels
Next, go in there and remove all the points where pixels tried to double during the resize.  We don't need everything to be thicker, just larger overall.  Don't worry about things looking perfect right now, we'll go in and clean in all up later.
Picture
Step 3: Clean up one part of the tile
I'll focus on the loose paper and pen first.  The pen is simple enough, it just need to be straightened and thinned down a bit so that it doesn't look like an over-sized kid's marker.  The paper is so simple that it barely needs any attention, I just removed on row of pixels so that it wasn't quite so tall.
Picture
Step 4: Clean up rest of tile based on Step 3's finished result
That just leaves the paper holder to finish.  I don't want it to be giant, since it's just meant to hold a few sheets of paper, so I shrink the width of it to be closer to the paper's size.  The shading is already almost perfect, so just a bit of touching up is needed.
Picture
Step 5: Final tweaking and adjustments
Last thing I do is look it all over and decide if anything needs tweaked.  The paper in the paper holder is too small, I decided, so I made it a pixel taller to look more like the loose paper's size.
Picture
And that's it!  Now we have a tile that doesn't seem too small for MV's default tile size.  Of course more complicated tiles, such as plants, will take more work to get looking right, but these basics should get me through all the tiles.
I've only finished upgrading a few tiles, but you can already get an idea of how it will all look at the end.
Picture
With a style settled on and side mechanics roughed out, the next thing I should focus on is getting the main gameplay mechanic, the 'sending heroes to worlds' mechanic, fleshed out from the one-map challenge game's version.
]]><![CDATA[A New Game, & An Abuse of Variables]]>Mon, 22 Apr 2019 19:05:20 GMThttps://www.hiddenone-sprites.com/game-making/a-new-game-an-abuse-of-variablesIf you check out all the pages on my site, chances are you've noticed a new page under 'Game Making'.

Reincarnation Assistant: 9 to 5 is the current game I'm working on.  It'll be the full version of my short One-Map Challenge game, where Mana is an assistant to a God of Reincarnation who ends up being forced to send people to different worlds that require an Isekai hero to come help.  This full version will have a lot more to do than just that, as well as having more than two characters.

The fact that there will be more than two characters meant that I needed to find a good way to keep track of all their names and friendship statuses.  While I could just write it out for each message and use a ton of conditional branches, I decided to find a cleaner way to do it: variables.
First, some background as to what I even want.  I'm using some of Yanfly's plugins to adjust the message size and add a name box, but I decided I also wanted to show an icon in the name box so that players can easily tell what the characters thinks of Mana (who's the main character).  That's easy enough, thanks to Yanfly's plugin I can just stick this code into the message:
​\n<God of Reincarnation \i[97]>
And it'll make the name box appear like this:
Picture
But the problem occurs when I decided that I wanted to be able to change the name of the characters and the icon image.  If I continued doing it the way above, then I'll need to have a conditional branch to check what exactly is supposed to be displayed... And honestly that's way too much work to do and means there's so many chances of myself messing up (Dog of Reincarnation has already appeared in one name box, and I'm sure there are much worse spelling mistakes possible).

I started by using two variables, one for the name and one for the icon number.  It turns out that you can stick a variable inside the icon control character, which makes life so much easier~
​\n<\v[8] \i[\v[9]]>
That means that instead of having to write out the name box and have conditional branches to make sure the right one is shown each time, I can just change the variables to have the right things show!

So I added those to my event, like so:
Picture
Which resulted in these options, depending on which choice was selected:
Picture
Picture
Perfect!

​But I decided to make life even easier on myself, and grabbed Yanfly's message macro plugin so that I didn't have to remember which variables are for which characters.  So now the name box info was all stowed in an easy to remember line:
\m[re-god]
While two variables are required for this method, I'm sure with a bit more work I could get it down to just one by using an array in the variable.  But for now, I can safely move forward with roughing out mechanics and cutscenes without needing to worry about making a mistake in a name box while writing things out.
I know this is a bit different than my normal resource blog posts, but ​I really want to share more about my personal game making methods so I thought a weekly(?) post where I talk about an issue I had while developing and how I found a way to work around it. 

​Hopefully some of y'all will find these useful in solving some of your own problems, or at least interesting to see how I over-complicate my dev life.
]]><![CDATA[IGMC 2018: Ready, Steady, Go!!!]]>Thu, 01 Nov 2018 17:17:58 GMThttps://www.hiddenone-sprites.com/game-making/igmc-2018-ready-steady-goThe IGMC (Indie Game Making Contest) started this week, and I decided to take part!  I'm working with my team from last year's contest, and we plan on making an even better game than last time.

What does that mean?  More mechanics, more gameplay, and more beautiful art!
Picture
Art drawn by the incredible Plueschkatze
We decided on a side-scroller style game, focused on exploration and solving puzzles in an overgrown post-apocalyptic world.

So far we've evented a few of the basic things we'll need, like an updating journal and a backpack to show all the items the player has collected (if you'd like to see an example of the prototype backpack in action click here since my site seems to dislike videos).  It's all evented, so this contest will be a good chance for all of us to stretch our eventing skills.

Story is currently our weakest thing.  We know that we want the main character to be searching for their sibling, but we still haven't decided on the main reason why.  Hopefully we'll figure out something by next week, or else it will be tough to get the dialogue written.

It's still the start of the contest, but I'm happy with the progress made so far.  Still have a lot to do, though!

​Happy game making!
]]><![CDATA[Evented Place-able Crafting System]]>Wed, 23 Aug 2017 19:44:32 GMThttps://www.hiddenone-sprites.com/game-making/evented-place-able-crafting-systemFor my game I wanted a crafting system that was more than just an option in the menu.  I wanted the player to be able to set down ingredients onto a table and then try to craft something with it.  But there wasn't a good way to do that.

​Until now.
Picture
Harold can now follow his dream to become a master chef! (Click to download the demo project)

What this system can do:

  • Let the player choose which ingredients to try to combine
  • Leave ingredients on the table until the player either crafts or picks it back up
  • Lets ingredients be added in any order
  • Let the player use different methods to craft with the same ingredients to receive different results

What this system can't do:

  • Make recipes for you
  • Keep track of which recipes the player has discovered
  • Make you a finished game

Think this crafting is for you?  Then read more to see how it's done.

Step 1: Decision Time

Possibly the most important step and definitely the first thing to decide before getting things set up: just what do you want the player to be able to make?
Picture
No, Harold, no you do not.
Since everything is evented for this system, it's best to keep things simple.  If you want hundreds of possible recipes, perhaps it's best to go use a crafting plugin instead.  You can use this system, but it's a lot more work on the developer to make sure everything works.

You don't need to know every possible recipe, but it's a good to have a general idea of what you'll be able to make.

For this tutorial I've decided that there will be 3 ingredients and 2 methods of cooking that will let Harold make 4 cooked dishes.
Picture
That's much more manageable, Harold, thank you.
Now that we know what we'll be making, it's time to decide how many possible ingredient spots we want the player to have.  If you've already come up with all of your recipes, then it should be the maximum number of ingredients used.  If you haven't decided on those, then consider with sticking with only 3 or 4.  The more spots you have the more variables you'll need to use, and the harder it will be to keep track of all of your recipes, so try to keep it under control.
Picture
Simple recipes don't need a lot of spots, 3 is good.

Step 2: Set up Your Variables and Items

With the big decision out of the way, it's time to start setting things up.  Let's start with the variables we'll need.  Each ingredient spot needs its own variable to keep track of what ingredient was added (labelled for easy reference).  We also need a variable that we'll use to store and compare the ingredients to later.
Picture

Next, let's get our items taken care of.  Harold's already decided what ingredients and cooked foods we'll need, so we just need to stick them into the database.

Since there are a few item types to choose from, decide whether or not you want the player to be able to see what ingredients they have.  If you want them to be able to see them, choose either 'regular item' or 'key item', and if you don't want the player to be able see them pick 'hidden item A' or 'hidden item B'.  There isn't a wrong choice for this, but make sure that all ingredients have the same item type (since we'll be using the select item event command later).

For this tutorial we'll have both the ingredients and cooked foods be 'regular items'. 
Picture
If you think you're going to add in more ingredients later, leave some spots open in the item list.  It'll make life a lot easier, because once you start making recipes you shouldn't change the locations of the items in the database list.

Step 3: Create the Ingredient Events

Now it's time to start the actual eventing!  We'll start with Ingredient #1's spot.  The first command we add is 'select item', with the variable set to 'Ingredient #1 ID' and the item type set to 'regular'.  This lets the player choose what item to put down onto the table.

Next are some conditional branches that check what the variable we just set equals and removes the proper item from the player's inventory.  We don't want the player to be able to keep putting down infinite items, now do we?
Picture
Nice and simple, but it's not much to look at, is it?
Of course, there are some issues with leaving the event like this.  The player can add items, but can't pick them back up!  So we need to include some more event pages that will both change how the spot looks and let's the player pick the item back up.

One event page for each possible ingredient (remember when we talked about keeping things simple?  The limit to event pages is one of the reasons to do that), with it's condition set to the corresponding variable.  Interacting with the page will give the player back the item, and reset the variable to 0, so that the player can put down another ingredient if they want.
Picture
That's totally a box of fish, not clams. They're just clam-shaped fishes.
Now the event's ready to use!  Unless you've done what did in this tutorial and made both the ingredients and cooked foods 'regular items'.  Doing that means that the player can choose to put done a cooked dish, and totally mess up the recipe!

To prevent that, we'll include another conditional branch that checks if the variable is larger than the highest ingredient ID that tells the player they can't add that and resets the variable back to 0.  Reseting the variable is super important, since if we don't do that then the recipe will fail later!
Picture
Now that's what I'm talkin' about!
I added one final page to the event that has a variable >= 4 condition and doesn't have a graphic, so that if the player does try to add something they shouldn't then there won't be any flash of an ingredient appearing.

With Ingredient #1's event finished, we can copy and paste it to make the other two!  We just have to make sure to change every spot where a variable is mentioned to the one that fits that event (so Ingredient #2's variables should all be 'Ingredient #2 ID').

There is a way to remove the correct item with only one conditional branch if you use a script call:

$gameParty.gainItem($dataItems[$gameVariables.value(3)], -1);

It takes away one of whatever item the player selected.  Check out Ingredient #3's event in the demo to see it in action!

Step 4: Creating the Crafting Event

With the ingredient spots finished, the only missing piece is the actual crafting event.  The first and most import part of the event is this script call:

var array = [$gameVariables.value(1), $gameVariables.value(2), $gameVariables.value(3)]
​array = array.sort(function(a, b) {
return a - b;
});
$gameVariables.setValue(4, array);

Make sense to you?  If it does, then you're better at javascript than I am.  If it doesn't make sense, let's look at each part separately.

var array = [$gameVariables.value(1), $gameVariables.value(2), $gameVariables.value(3)]
This part is what takes our 3 ingredient variables and puts them all in an array as a single list.  Say the player put Seaweed in spot #1, Fish in spot #2, and Rice in spot #3, that would make variable #1 equal 3, variable #2 equal 1, and variable #3 equal 2.  This scriptcall takes those numbers and puts them into an array like so: [3,1,2].

​array = array.sort(function(a, b) {
return a - b;
});
This is where the real magic happens.  It takes the array we just made and organizes it into numerical order, so if our array is run through this it becomes [1,2,3]!  This makes it amazingly easy to compare to recipes now, since we only need the recipes to be in numerical order as well.

$gameVariables.setValue(4, array);
This last part takes our sorted array and puts it into our combined ingredient variable.  And now it's ready to be compared to the possible recipes.

Now that we sort of understand the scriptcall, we can put it into the event along with some conditional branches to compare the player's combined ingredients with the recipes we made.  We're using another script call, this time checking to see if our variable matches a recipe (the recipe is presented as another array).

$gameVariables.value(4).equals([0,0,1])

So in this example it checks to see if the player added just one Fish to any of the spots.  If they did, then it rewards them with a Roasted Fish.  And that's it!  You've just evented a crafting system!
Picture
The simplest layout for the event, it just checks for a match and gives the player their reward.
Of course, there are a few issues with leaving it like that.  First off, the ingredient variables are never reset, so the player could just keep clicking the event and receiving Roast Fish.
Picture
That's because you're not a developer who's trying to make things balanced, Harold.
So let's add a reset for those ingredient variables.  There are two places you could put it, depending on whether of not you want the player to be able to retry with the same ingredients or not.  If you put it above the conditional branches, then the items will be taken away, as if the player ruined them by failing.  If you put it inside each of the conditional branches, then the player will be able to go pick the items back up and try something new.  Do whichever one you want.

We've also added some comments from Harold, so that the player is informed about what they made.  At the very end of the event is the failure message, which tells the player that the combination they tried just didn't work.  To make sure that that message doesn't accidentally play if the player is successful, we put an 'exit event processing' into each conditional branch, so that the event stops running once it's found a successful match.
Picture
Now we're cooking! Literally!
Once you've added all the recipes you want to include, you can truly call your crafting system completely functional!
Picture
Yes you can! There's just one more step.

Step 5: Testing and Celebrating

With all our events finished, we just need to test everything.  Time to try adding all of your items to see if any sneak past, and to make sure that all of your recipes work.  Double and triple check that you're using the right variables in the right spots (it's easy to forget to change one conditional event, and that can cause everything to break).  Once you've tested things, then you can celebrate your success!

If you'd like to take a look at how all the events work together, go ahead and download the demo project: crafting_demo.zip

And that's it!  The more ingredients and recipes you add, the more complicated this system can get, so start simply to get the hang of it.  Good luck with your game making!
Picture
Thanks for taking the time to read all this!
]]>