Getting Started with Light.VN Commands Pt.2
Archived from Ko-fi, without images
Other Light.VN posts
Continuing from Part 1, this time we'll be covering the coordinates, acceleration, camera setting, and screen space section from the official Light.VN wiki on Commands!
As you write Light.VN commands, you usually have to supply parameters. Other than filepath, when working on the V part of Visual Novel you'll most often encounter coordinates and acceleration.
Coordinates
Coordinates are commonly written in [x y r] format, with r being the layer. Contrary to what you might have been used to in some other engines, higher number=closer to you, so components in layer 30 will be shown on top of components on layer 10. In 3D camera mode, you'll also have to supply the z-value.
Coordinates represent how many pixel it takes to position the picture starting from the upper left corner of the screen (0 0). so (50 100) means 50 pixels to the right and 100 pixels... down? It might be more intuitive for some people, but for people well-versed in mathematics, it might take some time getting used to.
You may have some difficulties placing your sprites correctly. In that case, you can use the command pane at the lefthand side of the screen to position your sprites directly on the screen, but if you want to know why you can't seem to get it just right when dealing with raw numbers:
Remember that the displacement is counted from the edges of your picture. If your game's resolution is 1280 x 720 and your image is 1280 x 720, then placing it at (0 0) should give you the whole picture. If your picture has transparent areas and the image is not properly centered, you may need more adjustments. (I'd assume not everyone will be happy calculating things and may rely on their feelings when placing elements on the screen). I recommend getting a tool like Pixie that can tell you the exact screen coordinate of your cursor.
But Pixie is wrong/I have calculated the image size but it's still appearing in the wrong place! Be careful! Your native screen resolution might not match your game's resolution, so you see things where it shouldn't. Light.VN has variables like lvSystem::ViewportSize() to help you with that, but generally you should have this in mind when designing your screens. If you are planning for heavy upscales/downscales I'd recommend making a test screen and test it in different graphical settings before you commit on the whole game.
For visual flairs, you can arrange your elements off-screen/partially off-screen and reveal them with clever animations and cameraworks.
Accelerations
Light.VN allows you to supply a time parameter to your effect commands and an optional acceleration type. The default and most basic one is a1, comparable to linear in Ren'py, meaning the changes will unfold in an uniform speed throughout the supplied time value. However, it has 17 other acceleration types (from a2 to a18) in its arsenal, and knowing your options is the key of mastering animation. It can be difficult to imagine how each acceleration type looks, like, so tatsu in Light.VN Discord has a script and video about it on Youtube.
I have adapted the script into Light.VN EN plugin (with consent) and translated the comments, so you can add your own custom movements and see how it compares to the built-in presets. For time being, the script is hosted in the Light.VN Discord. I may host the files in itch.io if I do more script translation and there is a sufficient demand. In general, a2 to a9 are three sets of three accelerations, decelerations, and a combination of accelerations and decelerations, while a10 to a18 provide you with more exotic behaviors suitable to combine with stretch and squash animation techniques.
Camera Options
At the end of every visual asset declaration command (bg, cg, ...) you can supply an additional parameter: camera options, available as follows:
on_camera means the asset will always stay stationary within view, no matter how you move the camera. Useful for overlays and decorations.
2DView means it will be rendered with 2D calculations.
3DView means it will be rendered within 3D. Be careful. When you have components rendered in 2DView mixed with components rendered in 3DView, you may have difficulties locating some of them in the preview.
lock_y means the object will not appear to rotate when you move the camera along the y-axis, so you will have the object faces you all the time when the camera rolls sideways.
lock_xy means the object will not appear to rotate when you move the camera vertically or horizontally (it will still respond to changes relative to z-axis).
When you're doing 2D assets on 3D planes, experimenting with lock_y and lock_xy will help you find a good angle to set the scene. Try playing with these properties in the visual preview to get a sense of how they interact.
Bonus: adding 0 to the end of an asset declaration (e.g bg0) means the asset will start at 0 alpha (visually) or 0 volume (acoustically), which will be useful in making smoother transitions.
Screen Spaces
This feature allows you to group components together just like virtual workspaces, usually for organization purpose. It's also useful in defining boundaries of a particular functions/features, because you can set an effect to apply to a whole screen space or only within particular screen space.
Screen spaces use the concept of a stack, and at the very bottom the default vn_screen_space_main always exists (you cannot delete it).
When you instantiate a new screen space, it will temporarily duplicate all the current keybindings, and moving forward any keybindings you create will be bound to the uppermost screen space unless otherwise set.
When the screen space is deleted, all keybindings will be released and the keybindings associated with the space right below it will be active.
This means suppose you're playing the game on the lowest screen space (with a quick menu and click to continue) and pressing the menu option will bring you to the menu screen space (layered on top of the main vn screen). Clicking here will not push the dialogues forward, but set to whatever control you have for the menu screen. When you exit the menu screen back to the game screen, the click to continue becomes active again.
You can specify a particular screen space when using an effect command, and this will take precedence over individual target specification. If you do not explicitly mention the screen space you will target, it will affect the current uppermost space.
If you have multiple components scattered in multiple screen spaces, using All or regex targeting will still affect only one screen space (either the default topmost or the one you specify).
全画面領域 Full Screen Area - targeting this means you are targeting all screen space at once, so clear 全画面領域 means it will clear everything in all screen spaces.
Important: make sure to delete a screen space after you delete every object on that space. If you delete a screen space while an object still remains, you may find it difficult to target that object.