SHOOBINATOR'S PROFILE

As it's currently 1am where I am, I am too lazy to write a full review, but I wanted to at least say that I had a fairly great time with this game. I liked many of the concepts for each of the puzzles. Particularly, the having-to-mess-up-some-steps-but-not-too-many-before-the-path-is-blocked-off puzzle. I liked the room with the boulders and teleporters, but I'm mixed on that one because it was a lot of simple trial and error, which ate up most of my time on the first run. I got to the last puzzle on my 2nd run. Although I like the stop-and-go concept, the execution here is greatly flawed because since the direction you move changes at random in less than a second even if you move veeery slowly, you are still very likely to step on a teleporter. The delay between flashes needed to be set to a fair minimum.

This is kind of uncanny because I also remade the Mario button puzzle, not for my major game, but as a sort of side test.

Anyways, I recommend using a common event for the button puzzle. Even for something like this, common events are still your friends! They are like functions, or methods, if you are familiar with other programming languages.

This is the exact event I used. Use it however you please:


This right here might look more complicated at first, but besides this event all you need for each button event is the following:

• Whenever you step on a button, set the variable SwitchNum to a value X (I will explain what X is shortly).

• Then, call that common event.

• Each event will need a 2nd page with its own switch that will keep it "pressed down" whenever you stand on it.

You also need to set the variable ModulusNum to 4 at some point when you enter the room and begin the puzzle. In fact, if you are only trying to copy this puzzle to a tee, make what is shown as variable #3 here, the value of 4. In the test game of mine, I actually had different sizes of grids for different difficulties so I just made this value a variable instead. Although I think a 5x5 grid is actually impossible to complete with this kind of puzzle! :P

X is a value that corresponds to location in an imaginary grid, or array as shown, which represents the button grid:
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16

However, where it says in that common event code to 'check left' or 'check right' it means when X is one higher so one spot right of 4 would be spot 5. Also, if you don't know what mod (short for modulus) is, it's a mathematical operation between two positive integers denoted by % which yields the remainder of whatever the yield would have been if the operation were division.

An example: 5 % 2 = 1
5 / 2 = 2 remainder 1 so the 5 % 2 = 1

Another: 9 % 3 = 0
9 / 3 = 3 remainder 0 so 9 % 3 = 0

The modulus is needed to help determine which buttons are being toggled in the grid.

I hope you found this helpful!

Both good suggestions, but I got the shop menu to work how I intended. This "shop" (not really a shop, more of another menu) is going to be called by an item that you get early in the game and will be available in your inventory.

I intended for this item to be used at any time that you can access the main menu, so the town shops idea wouldn't quite work for my idea. You will be able to reallocate points like Badge Points in Paper Mario, so that battles will be as much about preparation as execution and there won't be the inconvenience of going all the way back to town in the case that you needed "that one spell" that you realized would be particularly useful in a certain area.

Maybe I'll get around to posting a video of exactly how this system will work.

Practice, practice, practice. Great ideas are needed to make a game but so are determination and hard work. If you're ever in the need for additional motivation/inspiration, watch Indie Game the Movie.

If you can do at least three of the things you listed on your own and release some kind of demo, you'll be more likely to find someone to help with, say, mapping for example.

Good luck!