Identical Games

Name:	Shrinkgrowrays
Version:	0.0.0
Author:	Dennis Payne
License:	CC0
Operating System:	Any supported by Minetest
Website:	https://github.com/dulsi/shrinkgrowrays

Shrunken Hero

My youngest searched for a mod for Minetest to add the Thing from the Fantastic Four. Needless to say no one had created such a mod. I thought about it and figured I might be able to solve the problem.

I haven't created 3D models but there are a couple golems for Minetest. I decided I liked the look of the Mineclone 2 golem the best. An artist would create a rocky texture that could be applied to the model. I simply downloaded a Thing skin and copy and pasted the textures over the golem textures.

It looked good. My son was pleased. I didn't want to restrict the Thing to the Mineclone 2 subgame so I copied much of the code into a separate mod. When the mod loaded up the Thing was tiny. The copied code missed a very important line:

visual_size = {x=3, y=3}

This line told the game to render the model at three times it's size.

Shrink/Growth Ray

Fixing the mistake was easy but the implications of this setting ran through my mind. You could create a ray that alters the setting to grow or shrink a monster. A quick search found the Open AI mod already implemented shrink and growth ray guns.

The implementation did not satisfy me. The shrinking and growing was tied into the monster API from Open AI. If you shot a monster which used a different API like mobs or mobf, it would not do anything. As those other APIs are far more common that left it of limited use. The effects also took a little time to complete. I wanted something more instantaneous.

I copied the rayguns into a new mod and hacked them to work as I desired. They didn't work. It seemed simple. In physical.lua, it got the visual_size and collisionbox and applied the multiplier. My code failed to find those members.

The reason for that was hinted at just below that in the lua code:

self.object:set_properties({collisionbox = self.collisionbox,visual_size=self.visual_size})

The visual_size and collisionbox members that were being manipulated were not the actual settings. They were copies. With that discovery, it didn't take to get and set the true settings with the shrink and growth rays.

My original plan was to increment or decrement the x and y elements of the visual_size every hit with the weapons. That turned out to be difficult because I couldn't find documentation on the collisionbox. While monsters would normally have the same x and y values, that was not required. If they are different, the collision box would need to be expanded differently for width and height. Rather than try to decipher the values, I decided to just go with halving and doubling the values.

Allowing unlimited shrinking and growing would have probably crashed the game as the kids pushed it to the extreme. Open AI combated this with the size_change it added to all monsters. This won't work since I don't control the monster APIs. Instead when a monster is first hit by a shrink or growth ray, the original visual_size and collisionbox are copied into member variables like Open AI keeps. This allowed a limitation to the size changes. It does make my mod incompatible with Open AI which should probably be addressed.

The slow growth of Open AI did have an advantage over the instantaneous growth in my implementation. The y coordinate of the monster is not the ground they are walking on. When the monster was enlarged, it would appear in the ground. If the change was slow, the monster might have walked or jumped out ot the block. The Open AI code listed the third element of the collisionbox as being the height. When a monster grows in my mod, the position adjusted up to prevent getting stuck. Shrinking was ignored because the monster appeared a little up in the air and fell down.

Flaws

Open AI had a check which I removed looking at the mob member variable which was added by that framework. I expected that means my shrink and growth rays could affect more than simply monsters. The kids discovered that dropped items are entities in the game engine and can be affected. The more interesting effect was the raft. If enlarged or shrunk, the player would also be enlarged or shrunk when they got on the raft and returned to normal when they got off. Interestingly I have not been able to enlarge or shrink players outside of the effect on the raft.

The shrinking and growth effects proved to be temporary but not by design. If you shutdown the server, the monster would be normal size when restarted. I have not tested if Open AI has the same flaw. Due to the greater integration with the monster API, they may detect the size_change at startup and apply it to the monsters.

Another big flaw with the mod is the lack of an effect. Shrunken monsters are just as tough and dangerous as their larger versions. Larger monsters have no additional toughness or reward. If shearing a large sheep produced more wool, the growth ray could be a valuable tool. That may be difficult to implement without integration with the monster API so that shearing knows the monster is enlarged. You could potentially still create a map were a player could enlarge monsters to prevent them from following through narrow corridors.

Recipes and Mineclone 2

If you aren't playing in creative mode, you needed some way to craft the shrink and growth rayguns. Adding a recipe for the Minetest game was very simple but my kids often play the Mineclone 2 subgame. I checked the existence of "mcl_core:iron_ingot" as a registered crafted item. If the item is not found the recipe used two steel ingots, a mese crystal and a diamond. If the iron ingot exists, the recipe used iron ingots, redstone, and a diamond.

The dependency file listed default and mcl_core as optional dependencies. Which is not entirely correct. Minetest has no way to specify that one of the two mods is required. For now just enjoy shrinking and growing in either the default game or Mineclone 2.