The New Stuff

To improve the store page I changed the font to the one that is used in Frame, made a few animated gifs and added a demo. The store-page is probably still far away from representing the quality of the game and the feedback on the demo wasn't good, but for now it is what it is.

I added normal textures to all moving objects (including frames). This way big uniformly colored surfaces are avoided, which makes it easier to visually detect movement. Especially for big moving frames this seems important. Usually adding a normal texture is done in a few clicks. However, since I wanted the uv-mapping to scale properly with the objects, all textures are atlased and the mapping has to co-operate with the portal effect it took longer than one might think.

Some rearrangement to the menu, to make it more intuitive.

Camera rotation and position were updated at different times, which could lead to jittery movement. Fixed.

There was a bug, which could potentially lead to crashes during level transitions. Fixed.

When objects go through a frame they are rendered as two objects positioned such that they appear as one object. In some cases these two objects could (very slightly) desynchronize, braking the portal effect. I fixed this by reworking some of the code and decoupling the render position from the physical position.

The Feature Request

I received a feature request from Rocklead to not just change the size of objects by scaling all axis equally, but instead scaling differently in the three axis to deform objects when going through a frame.
While I decided to not implement this, I want to elaborate on the reason for that. I hope that the explanation will make the dev-log a bit more interesting than the listing of to-do's it was so far. Also, this feature illustrates a constant struggle during the development of Frame, where seemingly simple changes lead down a surprisingly deep rabbit hole.

The first question is how preservation of momentum and kinetic energy would work. Either the behavior of an object would be inconsistent when going through frames, or deformed objects would have different inertia in different directions. The behavior doesn't get less weird when rotations are taken into account.

Another problem is that, when scaling differently along different axis, angles are not preserved. E.g. cubes become parallelepipeds and spheres become ellipsoids. Even worse is that the actual collision shape would change permanently when a frame or the object in the frame is rotating. A weird question is if this deformation would stop at some arbitrary point. If yes, where? If no, the object (or if you go through a frame the whole level) would deform everytime the frame or object itself rotates.

None of these reasons make that feature impossible. In fact similar "contradictions" appeared with the mechanics already present. So I could have done the same thing I did before: think about the options available, estimate what those options would implicate for gameplay, make a choice and try to explain or avoid the weirdest aspects of the behavior via careful level design.

However, the constant shape change would necessitate to recalculate and exchange the collision shape every single frame, which could make the physics janky and would be awful with respect to performance.

This could be resolved by only letting axis aligned cubes enter these special kind of frames. However, it felt important to me that the rules are consistent and apply the same to all objects. Thus, such a restrictive mechanic would not be in the spirit of Frame, I think.

Long story short: scaling differently in different axis would lead to awfully strange behavior and would be either computationally unacceptably inefficient or too restrictive.