xxxx-building-tools.md

Feature Name: building_tools_for_art_team Start Date: 2022-06-20 RFC Number: (leave this empty for now - the core developers will give you a number to put here when the RFC is submitted) Tracking Issue: (leave this empty - the core developers will give you a number to put here when the RFC is submitted)

Summary Building tools will be added/improved for artists to work more efficiently directly in Veloren.

Motivation Why are we doing this? What use cases does it support? What is the expected outcome? The main reason is for artists to be able to load in their assets in the game more efficiently and to be able to use Veloren terrain and building system to connect the assets more properly. This will help create better mockups to help procgeniuses in their work. It will also make for better release party maps (bigger and better, with more possibilities). The expected outcome is that mockup creation process will be improved for artists, which will bypass the limits of MagicaVoxel. Moreover, it might also motivate more people to create mockups if the ingame tools are improved. Another outcome would be that a “creative mode” (similar to Minecraft’s) would be introduced in Veloren, which will help map makers in the future when doing custom maps for the game. In the future, having tools for custom maps will be a great addition.

THIS IS NOT MEANT FOR THE CURRENT VELOREN GAMEMODE. It is before all a development tool for artist in the game before being a new gamemode. Guide-level explanation Either the introduction of a /gamemode command to switch gamemode and enter creative mode that will have all the features listed further down / Or an improvement of the current build mode keeping the same command.

The features below are either new features or improvements and expansion of current features.

Short-Term Features:

Flying: Flying is similar to minecraft flying mode, where you can stay at the same height in the air and go up or down with space and shift. (Currently, the flying staff is not usable while building because they are both used with mouse, and you can’t stay at the same height without moving). Flying is essential to build on large scale areas without complexity. Example of its use: You are working on a cliff, and need to place blocks really high, so you fly instead of creating a stair with blocks that you will then remove.

Building improvements: Hold click to place and remove blocks faster. Speed of block placement is increased when click is held. Example of its use: You want to dig the terrain a bit so your asset fits more in the terrain, you want it to be fast to not lose a lot of time.

Importing .vox assets in the game: (Currently, there is only a green box to show where the asset will be when importing an asset.) The asset about to be placed appears in the green box to see in what direction it is facing but it is not placed on the map yet, it has no physics, just visuals. The voxels have no detail and shader, they are only there to see exactly how it would look. (similar to schematics litematica mod on minecraft, that lets you preview the structure that's gonna be built without actually building it)

On the left you have the preview of the asset, and on the right you have the asset once it’s placed.

There is a /rotate command to rotate the asset by 90 degrees BEFORE the asset is actually placed. There is a /undo command to remove the last asset that was placed. Example of its use: You want to have a house that faces the sea, but when previewing the asset you see it’s not, so you use /rotate. You place it but realize it is one block too high, so you use /undo and redo it one block below. It takes 2 minutes.

Long-Term Feature:

Command to give gameplay use to areas of the map: You can create an area around your asset that will have a specific gameplay use instead of just being a visual asset. /set_area x y z Example: You created a town with assets but you want villagers to spawn in it. You use the /set_town and the range of the area so villagers will appear and the town now interacts with the world. /set_gnarlingcamp or /set_airshipstation, etc.

This will allow to have blank maps in terms of spots, towns, cities and dungeons

Reference-level explanation This is the technical portion of the RFC. Explain the design in sufficient detail that: Its interaction with other features is clear. It is reasonably clear how the feature would be implemented. Corner cases are dissected by example. The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. Drawbacks Why should we not do this? This section is really important. An RFC is more likely to be accepted if it recognises its own weaknesses and attempts to consider them as part of the proposal. Remember: Listing drawbacks doesn't mean an RFC won't be accepted. If anything, it gives developers the confidence to move forward with the RFC, knowing what impact it may have. Some commands or features might be hard to implement (notably the /undo or the /set_area commands). The /set_area could affect rtsim or econ if it happens AFTER those systems happen, and it might be tricky to make the /set_area before econ and rtsim exist.

Rationale and alternatives Why is this design the best in the space of possible designs? This system combines MagicaVoxel and Veloren to use the advantages of both programs. MagicaVoxel is really tedious for large scale terrain, while Veloren provides massive terrain easily. By improving the implementation of small/medium scale assets in Veloren, it is now possible to directly assemble assets in Veloren while using terrain to create cities, towns, dungeons, etc. What other designs have been considered and what is the rationale for not choosing them? The creation of a voxel art software designed for Veloren was/is considered, but it requires a considerable amount of work and an entire reorganization of artists working process. What is the impact of not doing this? Mockups will have to keep being limited to MagicaVoxel terrain, which isn’t anywhere close to the quality of Veloren terrain. They will also have to be smaller as the work time of current process is significantly longer. As a long term impact, it will be impossible for players to make custom maps (custom assets on maps).

Prior art Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are: Does this feature exist in other games or engines and what experience have their community had? For community proposals: Is this done by some other community and what were their experiences with it? For other teams: What lessons can we learn from what other communities have done here? Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. This section is intended to encourage you as an author to think about the lessons from other games: provide readers of your RFC with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other projects. Note that while precedent set by other games is some motivation, it does not on its own motivate an RFC. Please also take into consideration that Veloren sometimes intentionally diverges from common game features. Unresolved questions What parts of the design do you expect to resolve through the RFC process before this gets merged? What parts of the design do you expect to resolve through the implementation of this feature before stabilization? What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?