Continously movement when pressed button instead of single presses.
Goal field that only activates when the Orientation is right.
It checks the orientation of all 3 axis and the object distance for a certain amount of precision (always account for rounding errors):
vecx=Vector([1,0,0])
vecy=Vector([0,1,0])
vecz=Vector([0,0,1])
veclist=[vecx,vecy,vecz]
own.color=(0,1,0,1)
for vec in veclist:
if abs(own.getAxisVect(vec).dot(Cube.getAxisVect(vec)))<0.9 or (Cube.worldPosition-own.worldPosition).length>0.1:
own.color=(0,0,1,1)
own.color=(0,1,0,1)
scale=Cube.worldOrientation @ Cube.worldScale
for i in range(3):
if abs(abs(scale[i])-own.worldScale[i])>0.1 or (Cube.worldPosition-own.worldPosition).length>0.1:
own.color=(0,0,1,1)
bge/UPBGE 0.2.5 compatibility: all bpy.dimensions replaced with simple obj.scale
rotated whole scene for easier xyz Orientation.
Controls:
WASD or Gamepad Left Stick
Rotate View:
Left/Right Arrow Keys or Gamepad Right Stick
Red boxes: change size
Blue boxes: Goal
Gaps can be overcome with matching size
Joystick can be set at Cube property 'Joystick'
I really have to begin making a little game with perhaps 3 mini levels now.
But before here’s a little update:
The drifting on the moving platform that you see in above video comes from my system to addthe linear velocity of the platform to the cube.
That has some delay.
Usually there are 2 ways to get no drifting:
Parenting an object to a moving object. (not possible with my rotation system)
Copying and setting the Position as a predraw function (works for UPBGE 0.36+ but UPBGE 0.3 still lags. AndWould be little bit more complicated code anyway)
My workaround is this:
The actual platform is slow-parented to the invisible moving dummy object.
The velocity is taken from the parent and with the correct slow-parent value everything looks quite synced.
The slowness-factor of slow-parent in UPBGE 0.36+ is different from 0.3 so for compatibilty it is set with: if bge.app.version>(3, 0, 0): own.timeOffset=5
Here is the game with 5 mini-levels.
They are very small and quite easy to reduce frustration
New:
moving ‘enemy’-objects
Sound relative to Player Position
Expandable:
New Levels can easily be created just by duplicating the Spawner and Goal objects.
I would love to see some creations!
Welcome
Move the Cube through the maze to the Blue Goal Box.
You size and orientation must match.
Blue boxes: Goal
Red boxes: morph to another size
Do not touch metall
Gaps can be overcome when big enough
Controls:
WASD or Gamepad Left Stick or Hat or Buttons
Rotate View:
Left/Right Arrow Keys or Gamepad Right Stick
Joystick Selection Menu:
Show/hide: J
Toggle through: Left Mouse Click
Restart Game:
Enter Key
Expandable:
To make more Levels just duplicate 2 objects:
Spawner and Goal
To start the game in any Level set the Property 'Level' of object 'goal_control'
Finally I found a workaround for a bug in UPBGE 0.36.1 !!! (Above Game updated)
In this game the morph fields and enemies are cubes that are scaled down to 0.99 so you won’t collide with them when you’re sitting next to them.
I had the problem that in 0.36.1 I couldn’t get out of the reach of a morph field once I stepped in.
**0.36.1 Collision Sensor doesn’t turn off at the same distance it turned on with “Box”-Collision Bounds (like 0.3 does) **
(And no, this has nothing to do with setting collision margins and can’t be fixed this way.
And yes, I need to use Physics-Type “Box” because I’m scaling)
Don’t know if this is intentional or a bug or if 0.4 will behave the same.
Here is a test file with 2 colliding Boxes with Physics-Type “Box”.
The left can be moved apart in finest increments with tapping “A” and “S”:
In UPBGE 0.3 You press 1 x A and the Collision ends. And 1 x S and Collision starts.
In UPBGE 0.36.1 You press 34 x A and the Collision ends. And then 34 x S and Collision starts. There is an overlapping. UPBGE_Collision.blend (819.2 KB)