I'm currently working on a sandbox game (link if you're interested/need more detailed code), and I've been having an issue with very inefficient code, specifically the code that detects crafting recipes. How it's coded right now looks like this;

when I receive [craft v]
if <(crafting slot) = [Wooden Log]> then 
add [Sticks] to [Inventory v]
else
if <(crafting slot) = [Sticks]> then 
add [Wooden Door] to [Inventory v]
else
say [and so on...]
end
end

So basically, it's a chain of if/else statements, which is obviously wildly inefficient and laggy. Considering how I'm constantly updating the game with new blocks (and thus, new crafting recipes), I wanted to fix this issue. Are there any more efficient methods (there probably are) that aren't too complicated and won't interfere with the rest of the game's code?

You convert the current crafting grid to a code and add the

( item (item # of [crafting grid code] in [recipes v]) of [results v] )

To the inventory and if it's empty delete it again.

Sohta_kun wrote:

I'm currently working on a sandbox game (link if you're interested/need more detailed code), and I've been having an issue with very inefficient code, specifically the code that detects crafting recipes. How it's coded right now looks like this;

when I receive [craft v]
if <(crafting slot) = [Wooden Log]> then 
add [Sticks] to [Inventory v]
else
if <(crafting slot) = [Sticks]> then 
add [Wooden Door] to [Inventory v]
else
say [and so on...]
end
end

So basically, it's a chain of if/else statements, which is obviously wildly inefficient and laggy. Considering how I'm constantly updating the game with new blocks (and thus, new crafting recipes), I wanted to fix this issue. Are there any more efficient methods (there probably are) that aren't too complicated and won't interfere with the rest of the game's code?

Nice catch. That is a great opportunity to optimize your code. You can make a list of recipes and another list of corresponding products. For example:

Recipes:

• log
  
• wood
  

Products:

• wood
  
• stick
  

Then, when you craft, you can only use this code:

when I receive [craft v]
set [product v] to (item (item # of (crafting slot) in [recipes v]) of [products v])
if <not<(product)=[]>> then
add (product) to [Inventory v]
end

dem_bot wrote:

You convert the current crafting grid to a code and add the

( item (item # of [crafting grid code] in [recipes v]) of [results v] )

To the inventory and if it's empty delete it again.

That's a solution I thought about at one point, but I want the recipe to work regardless of the order you put the items in. Is there a way to generate code that isn't order-sensitive? Maybe internal item IDs (even though that would be a lot of work)?

N8_D_GR8_1 wrote:

Nice catch. That is a great opportunity to optimize your code. You can make a list of recipes and another list of corresponding products. *snip*

I'm assuming that only works for recipes that use only one ingredient, though I could probably merge it with dem_bot's idea. That does ultimately lead to the problem of order sensitivity that I mentioned earlier when replying to dem_bot.

That'll require embedded lists. For each non-order specific recipe, check if the grid contains the item and mark the item as checked. If not all items are present, mark all items as unchecked.

With string item names, Scratch doesn't make it easy to optimise further. Other programming languages allow for hashing, sets, and dictionary lookups, and your case could easily be solved with them. Numeric IDs are sensible as they can be associated with items in a list or more easily hashed. It does also come with other benefits like being able to look up additional info with each item such as a description or category.

Also note the “list contains thing” and “item # of thing in list” blocks can be slow as they involve searching every item of the list, only stopping early if a match is found.

I spent a bit of time trying to think of solutions for you but they all involve hashing. I was hoping for something in between the complexity of that and your current solution but can't think of one.

My current suggested method is to make a hash table with keys as hashed sets of ingredients and items as lists of possible recipes.
The hash function can be as simple as: sum their IDs and modulo with the size of the hash table. The order of the IDs do not matter when they are summed; the result is the same. The lists in the hash table are the possible recipes for a given hash and can be searched less efficiently.

awesome-llama wrote:

With string item names, Scratch doesn't make it easy to optimise further. Other programming languages allow for hashing, sets, and dictionary lookups, and your case could easily be solved with them. Numeric IDs are sensible as they can be associated with items in a list or more easily hashed. It does also come with other benefits like being able to look up additional info with each item such as a description or category.

Also note the “list contains thing” and “item # of thing in list” blocks can be slow as they involve searching every item of the list, only stopping early if a match is found.

I spent a bit of time trying to think of solutions for you but they all involve hashing. I was hoping for something in between the complexity of that and your current solution but can't think of one.

My current suggested method is to make a hash table with keys as hashed sets of ingredients and items as lists of possible recipes.
The hash function can be as simple as: sum their IDs and modulo with the size of the hash table. The order of the IDs do not matter when they are summed; the result is the same. The lists in the hash table are the possible recipes for a given hash and can be searched less efficiently.

But wouldn't there be cases where a completely different set of items share the same sum? For example, If Wooden Log had an ID of 1, Wooden Planks had an ID of 2, and Sticks had an ID of 3, Wooden Log + Sticks could have the same sum as two Wooden Planks. Or do you mean something other than numerical IDs?

Sohta_kun wrote:

But wouldn't there be cases where a completely different set of items share the same sum? For example, If Wooden Log had an ID of 1, Wooden Planks had an ID of 2, and Sticks had an ID of 3, Wooden Log + Sticks could have the same sum as two Wooden Planks. Or do you mean something other than numerical IDs?

Last sentence:

awesome-llama wrote:

The lists in the hash table are the possible recipes for a given hash and can be searched less efficiently.

awesome-llama wrote:

Last sentence:

awesome-llama wrote:

The lists in the hash table are the possible recipes for a given hash and can be searched less efficiently.

I'm still confused, school never taught me about this (and instead taught me about point P and linear function or whatever). I think seeing an example might help me understand. Can you describe the basics of this system through Scratch blocks?

The hash table returns a few possible recipes and you will have to then check which is correct. This decreases the amount of work needed, because you don't have to check each and every recipe.

dem_bot wrote:

The hash table returns a few possible recipes and you will have to then check which is correct. This decreases the amount of work needed, because you don't have to check each and every recipe.

So I just have the same recipe in different orders for each result?

Say u just have a hash function that takes the mod 2 of the item numbers of each item in the crafting grid in total and then adds one to it.
Stick is 1
Plank is 2
Stone is 3

If you enter two planks into the crafting bench, the function will return ( ( 2 + 2 ) mod 2 ) + 1 = 1
Then at item 1 in your hash table, it would say lever or stick are possible recipes, because ( ( 1 + 3 ) mod 2 ) + 1 = 1 too.
Adding two sticks and three stones gives ( ( 1 + 1 + 3 + 3 + 3 ) mod 2 ) + 1 = 2 , so pickaxe would be an item in item 2 of the hash table.

dem_bot wrote:

Say u just have a hash function that takes the mod 2 of the item numbers of each item in the crafting grid in total and then adds one to it.
Stick is 1
Plank is 2
Stone is 3

If you enter two planks into the crafting bench, the function will return ( ( 2 + 2 ) mod 2 ) + 1 = 1
Then at item 1 in your hash table, it would say lever or stick are possible recipes, because ( ( 1 + 3 ) mod 2 ) + 1 = 1 too.
Adding two sticks and three stones gives ( ( 1 + 1 + 3 + 3 + 3 ) mod 2 ) + 1 = 2 , so pickaxe would be an item in item 2 of the hash table.

I'm starting to get a better understanding of your idea. It still does seem too complicated and difficult to implement though. It might even end up being less efficient than the if/else spam, unless I'm misunderstanding something again. Are there any potential ways to simplify this method?

The hash table would probably not be more efficient until you have quite a lot of recipes. However having the recipes in a list can help alot. Another thing that can help is try to move everything in the crafting grid to the top left, so recipes smaller than the grid will always be in the same position.

Sohta_kun wrote:

dem_bot wrote:

You convert the current crafting grid to a code and add the

( item (item # of [crafting grid code] in [recipes v]) of [results v] )

To the inventory and if it's empty delete it again.

That's a solution I thought about at one point, but I want the recipe to work regardless of the order you put the items in. Is there a way to generate code that isn't order-sensitive? Maybe internal item IDs (even though that would be a lot of work)?

You can sort the ingredients before comparing them to the crafting recipes

nembence wrote:

Sohta_kun wrote:

dem_bot wrote:

You convert the current crafting grid to a code and add the

( item (item # of [crafting grid code] in [recipes v]) of [results v] )

To the inventory and if it's empty delete it again.

That's a solution I thought about at one point, but I want the recipe to work regardless of the order you put the items in. Is there a way to generate code that isn't order-sensitive? Maybe internal item IDs (even though that would be a lot of work)?

You can sort the ingredients before comparing them to the crafting recipes

You might be a genius.
This solves everything. I'll just create an ID system, and then reorder the ingredients based on the ID number, join them while surrounding them with underscores (to make sure the contains? block doesn't detect any false positives), and then check if the final string matches a recipe stored in a list, and check the next item in the list (the list contains the recipe and the outcome).