Plan at least 1-2 days to test your game thoroughly to fix any potential issues before sharing to the Gallery or Publishing to LAND. If your Experience includes a lot of custom mechanics that combine logic or branching gameplay, it may be a good idea to plan for 1-2 more days to test it thoroughly and have time to make any improvements needed.
Testing your game is essential to its success, but no matter how much you test, issues can sometimes occur against expectations. It is your job to protect the player to the best of your ability in case this happens.
If the player gets stuck, their only way to escape may be to use the /respawn command. This will spawn them on the Avatar Portal.
To avoid frustrating players, build a checkpoint system into key areas of your Experience to teleport players past challenges they've already overcome so they won't need to be repeated.
Common Issues to Look For
Traps
Problem:
Players can't escape some areas they've fallen into by jumping or squeezing between blocks and assets.
Usual Causes:
An avatar's jump is 1.5 blocks high.
An Asset's invisible collider(s) can block movement through areas that appear to be open.
Solutions:
Check for areas 2 blocks or more deep. Add blocks to be used as steps or fill holes.
Asset colliders are not visible in Game Maker. Test in Play mode to verify collisions allow the free movement players will need.
Awkward Collisions
Problem:
There are unnatural collisions with Assets that distract from immersion and add frustration.
Usual Causes:
Some Assets need more polish so they look identical, but have more realistic collisions.
Some objects are aesthetically pleasing for your scene, but difficult to move around or over.
Solutions:
If you created the Asset, check that the collider is as close to the visible voxels as possible. If not, modify it using the Animator module in VoxEdit to break it down into more models with their own smaller colliders. See Break Down Objects for more information.
If the collisions are caused by objects on a pathway, such as grasses or rugs, select the objects, open the Properties Panel, and .
Broken Mechanics
Problem:
Gameplay can be broken due to custom logic not working as expected.
Usual Causes:
Occasionally, there are known issues with certain releases of Game Maker.
Logic must communicate either on a synchronised [MP] layer, which reflects change at the same time for all players, or on a client-only [SP] layer, which is based on an individual player's progression in an Experience. Quests only communicate with client-only [SP] behaviours and components.
Objects can't send messages to themselves.
If many things are triggered to happen by the same message and there are other sub-events triggered, the outcomes may not happen in the order intended.
Some objects have a special logical role in your Experience, such as a quest giver, and need protection from accidental destruction.
Many behaviours and components have a range of communication in order to send messages to other objects.
Solutions:
Check Game Maker Change Logs for known issues, make sure you're using an updated version, and ask in Discord if other players are having the same issue.
Check that messages flow properly in the [MP] and [SP] layers for the intended gameplay. Many behaviours and components have both [MP] and [SP] versions available so you can modify the communication flow if needed.
Add a test object to turn on a light or pop up a speaker dialogue when a message is received to rule out whether the cause of a messaging bug may be the trigger object or the receiver object. Make sure objects that will receive a message are in range of other objects that will send them.
Create small delays in messages being sent using Timed Events behaviour so your logic can have time to sequence smoothly.
Make sure Quest giver objects have "plot armour." Remove the Health component that applies by default with many non-player character behaviours.
Broken Game Flow
Problem:
Players can skip past gameplay, break the triggers for gameplay intended for later, or trigger gameplay in an unintended order.
Usual Cause:
A simpler logic setup allows players to trigger events anytime. You must identify the conditions that need to exist for certain logic to be "unlocked" in order to create the game flow you intend.
Solutions:
Verify that player actions earlier in the game flow will not make it impossible to complete a Quest intended for later.
Use natural physical barriers as part of the narrative, which can be removed to open access to new areas and their logic.
Access to Off-Limits Areas
Problem:
Players can access areas they shouldn't.
Usual Cause:
Your Experience needs polish to focus players on the gameplay areas you've designed with text or visual cues and physical barriers.
Solutions:
Lead players in the right direction with hints in the dialogue, clear instructions in quests, quest markers, and design details that draw their eyes to go to the right places at the right time.
If physical barriers are needed, it's best to create natural barriers that fit into your narrative.
In some cases, invisible objects with collisions can be used as barriers.
Some objects include default behaviours, such as platforms or doors, which should be removed to prevent access to unintended areas.
IMPORTANT: In addition to testing your game in Editor mode in the Game Maker, it is strongly recommended to share your Experience to the Gallery and test it there.
In some cases, Experiences in the Gallery or Game Client behave differently than your results from testing in the Editor. Testing thoroughly in the Gallery will give you enough time to deal with unexpected surprises.
Some objects with behaviours or components may respond more consistently if the message they receive is sent from a Message Broadcaster or if a message is that has been applied to the object.
Add a Toggle Behaviour component to any objects whose behaviour should only be active at certain times in your game's flow (for example, ). Trigger the behaviors to turn on and off with messages sent when events that happen just before it are completed. Verify that logic which should not initially be "on" has the proper initial state and is triggered on at the right time.
