Solving problems caused by the Player Tile

If you look inside the default brains of objects such as coins doors and goblins you will notice they use the Player tile to detect your player character. Most of the time this is fine. However, sometimes it does not work how you expect, goblins can attack thin air, signposts can show their message constantly, and coins can vanish when there is nobody near them. What is going on?

What is the player tile?
Despite it’s title the Player tile does not just refer to your controlled Player Character. In fact, it isn’t a single object variable at all, it is an object set. It detects all “player objects”.

What is a “player object”?
A player, as defined by the Player tile, is any object that contains control codes on its first page. A control code is one that requires a button press; something like:

WHEN [A][pressed] DO [jump]

In a basic game you will probably only have one object with these types of Kode lines in: your controlled Player Character. However if you have a logic cube with a menu in it, or characters with Press A to see next bit of conversation, then these will also be regarded as “player objects”.

Why is using the Player tile a problem?

Lets say you have a logic cube which has instructions in it for your game. The player can see these instructions by pressing the LB button. Having this control Kode in the cube will define it as a “player object”.

Goblins detect neutral objects and enemy objects and players to attack. When it comes across the logic cube, it thinks it is a player and will attack it. So your goblin appears to be attacking thin air (as the logic cube is invisible normally).

If you place a “player object” next to a signpost, that signpost will continually show its message – and this will be visible through props and terrain all over the map.

Any detect player or see player Kodes will react to player objects. This could cause objects being removed from your game or performing an action before the real player is detected.

Solutions

1. Do not put control Kode on the first page of an object if you do not want it to be a player object.
This is not always convenient, but is the simplest solution if you have already built the game when you discovered the problem.
I find the best solution is this

page 1
WHEN DO [call page][2]

Then carry on with your kode. Because there is nothing on page 1 your object will not be regarded as a player tile. This is the best solution if you find you have a problem after you have made a brain.

2. Change all the detect player, bump player etc Kode lines to [detect] [IWP:your player] instead of the [player] tile.
Although fine for placed objects, this will require you to use templated versions of default objects and characters you create in game, or you will need to replace the brains of all gallery created objects with an amended version of their brain that you have saved using replace brain. Would have to be implemented from the start of your build. Not suitable in a multiplayer environment.

3. Same as above but use [global][objvar:THE player] in your Kode instead of just [player]. And put this is in your Player Character brain

WHEN [once] DO [global][objvar:THE player][=][me]

4. Same as above but use Multiplayer – player 1 tile instead of a global object variable

WHEN [once] DO [player 1][=][me]

5. In a multiplayer environment it gets trickier. You would have to create an object set of “players” and each object would have to determine whether the player it was detecting was in that set – and therefore a valid player. You would also need to use this method if you had multiple characters in the game that you controlled, but not using multiplayer.

WHEN [detect][player] DO [objvar:queryplayer][=][it]
…WHEN [global][objvar:players][contains][objvar:queryplayer]

6. or you could use the player 1-4 tiles

WHEN [detect][player 1][or][detect][player 2][or]…etc

Comments are closed.

Website Powered by WordPress.com.

Up ↑

%d bloggers like this: