Smarty

Also carefully check what values go into mx and my. You probably intend them to be the center point of the current instance or the center point of the grid in which the instance sits. I assume you meant the center, otherwise adding exactly 8 pixels to check in every direction wouldn't work. Assuming your sprites / grid cells are not 8 by 8 but rather 16x16, it's usually safer to check the center point of the adjacent cell (so add/subtract 16 instead of 8). This could avoid issues where the bounding box of a sprite (from which instance_position may be checking if it is there) is actually smaller, and your position check is falling between instances.

Do they load their puzzles off of a server? Or is it all packed into the app? Reason I'm asking is I've got an idea I'd like to take a shot at. It requires a picture to be loaded for each "puzzle". I want to keep all the pictures in the game itself, but will the size increase dramatically? They'd be about the same definition as 4pics1word.

I don't know the game, but they could be packed into the app. Obviously this impacts the size, but there's a few tricks you can do to make things smaller. For example, I've noticed when developing for Android that if you double the width and the height of an image (using image scaling), the image quality doesn't deteriorate too much because most smart phones have a reasonably high DPI and they smooth out quite well. This means that you can use smaller resolution images than you're going to display on the screen. And this means that what normally would require storage for 1 picture could now store 4.

An example: I have a Galaxy S (yes,quite old) with a resolution of 480x800. A width of 480 splits up in two images of 240 each. Square images would be 240 by 240 at max and they'd fit tightly in the screen, so let's subtract 40 of each for borders, and you get 200x200. I could use 100x100 images and double their scales to get them where they need to be.

Textures in GameMaker,that store the images, come in various sizes. Let's take a texture of 2048x2048. This is not uncommon for games to use. 2048x2048 can store 20 pictures of width 100 horizontally and 20 of height 100 vertically. And that's already 400 pictures.

Since I don't know the game, I don't know if it reuses pictures for puzzles. But I would certainly do that myself to increase the number of actual puzzles you can make with a limited set of images. All you need to do is "tag" the images with words that describe properties of the depicted item. For example, a wooden table could be tagged with "wood", "table", "legs", "surface", "brown" and "furniture". Once you create a new puzzle, all your game has to do is select a tag from its library and randomly select 4 images from the library that match the tag.

The effort, obviously, is in creating a useful set of images that may carry multiple tags, and making sure a tag appears at least 4 times in the library (since it's 4pics1word).

When you say fanless pc i instantly think of a raspberry pi.

That's one option, but I prefer to go with an system that runs an operating system I'm more comfortable with. The Pi is interesting in the sense that one can install a Linux distro and then improve start-up time and performance by removing everything not required to run a MAME or alike, but having virtually no experience at all with Linux and its distros I'd spend way too much time to bend it to my preferences.

Moderators and Admins with lots of experience in Game Design are the only ones who qualify.

This is a silly requirement. Moderators and admins aren't selected for their expertise in game design, so having a position this forum does not mean they qualify for the project.

Just ask the community for an experienced game designer, and review their portfolio for reference.

I wasn't nitpicking - I was thinking that 2 checks would be better than up to 4 if you were performing it for a lot of instances.

You still need to work out the corner to check, which means you end up with looking at the angle from the center point of the circle to the origin of the instance. If in quadrant 1, use top-right corner. If in quadrant 2, use top-left corner. And so forth. And that's even before checking the actual distance.

And your last point - are you saying that if you rotate your sprite 90 degrees and then find the right edge of the bounding box, GM will actually return (what is now) the top edge? That deosn't make much sense to me or maybe I've misunderstood what you mean

No, the left border is at all times the left border of the projected image. But you get the quadrant the origin is in - with rotation, the origin may be in one quadrant, while a corner may cross the circle boundary in an adjacent quadrant.