Runtime Level Design

Community Showcases
1

Hi everyone,

This is the official forum for the Runtime Level Design (RLD) pack. RLD is a Unity plugin that contains powerful level design tools that can be used at runtime. Incredibly handy if you need to build a runtime editor or a game that contains level design elements.

Presentation video:

Jump right in an learn how to build a dungeon:

Many more video tutorials can be found here.
API Docs are available here.

Cheers,
Andrew

1 Like
2

Hi everybody,

Version 1.1.6 is now live on the Store. Here is the list of improvements and bug fixes:

Improvements:

  • it is no longer necessary to attach colliders to game objects. The system can now interact with 3D and 2D objects even if no colliders are present;

  • 2D sprites can now be selected correctly even if they do not reside totally inside the XY plane;

  • the selection box scale factor has been transformed into an offset (value which is added instead of multiplied). This was necessary because a scale factor will produce inconsistent results for objects of different sizes;

  • it is now possible to specify if lights, particle systems, empty objects or sprites can be selected;

  • improved performance for visible object determination. This data was necessary in some situations (such as when selecting objects with the selection rectangle) and it is now cached and only updated when necessary;

  • it is now possible to specify if the object selection boxes can be drawn. This can be controlled from the EditorObjectSelection Inspector or from script: EditorObjectSelection.Instance.ObjectSelectionSettings.ObjectSelectionBoxRenderSettings.DrawBoxes = desiredValue;

  • the application no longer acquires the vertex snapping data at startup. For larger scenes, this can lead to big load times. The system now acquires the vertex snapping data only when it is needed. The algorithm used to calculate this data has also been improved (e.g. the floor object from the Survival Shooter Unity package was taking around 16 seconds to have this data calculated. Now it is computed almost instantly);

Bug fixes:

  • fixed bug which was causing selection boxes to be rendered incorrectly for terrain objects;

  • fixed bug which was preventing the selection system to work correctly after using the move gizmoā€™s terrain surface placement functionality (i.e. the selection system would become disabled);

3

Hi everybody,

Version 1.1.7 is now live on the Unity Asset Store. Below, you can find all features/improvements and bug fixes that have been made:

New features:

  • scene gizmo (no smooth perspective switch; the switch is done instantly);
  • surface placement and axis alignment for mesh surfaces for the move gizmo;
  • axis masks for all gizmos (please see the ā€˜SetObjectAxisMaskā€™ and ā€˜SetObjectAxisMaskā€™ in ā€˜Gizmo.csā€™). When an axis is masked, the gizmo will not be able to transform an object using that axis. For example, for a rotation gizmo, when an axis is masked for an object, the object can not be rotated around that axis. Same for the other gizmos;
  • it is now possible to specify if a selection rectangle can be used for object selection. You can use the Can Multi-Selectā€™ toggle button inside the EditorObjectSelection Inspector to toggle the selection rectangle;

Bug fixes:

  • fixed null ref exceptions thrown when switching between scenes;
  • fixed bug which was causing inactive objects to get selected;
  • fixed gizmo position not calculated correctly when first object was selected;
  • fixed grid was being rendered by all cameras which were active in the scene. Now, only the editor camera is used to render the grid;
  • fixed camera background flicker (could sometimes happen when quickly moving and/or rotating the camera or when focusing the camera on a large group of objects in ortho mode);
4

Hi,

Great asset, but I think it would be even better if the forced camera controls and undo-redo system were optional. Right now I cannot use this asset because it interferes with my own camera, shortcut keys and undo-redo system.

5

Hi there SunnySunshine,

I remember I solved the same problem for you in the past quite some time ago (more exactly 5th of February 2016) and I sent you the package without all the other systems in place. So I do not understand the reason why you wrote this message here. If you lost the package, I can send it to you again. :wink:

Best Regards,
Andrew

6

Thanks for the fast reply.

Yeah, I just started a new project, and while I do still have that package you sent me lying around somewhere, I just think it would be neat if this asset actually supported these things by default. Iā€™d feel a lot more comfortable downloading assets from the asset store that I know have been adapted to the latest versions of Unity rather than using some package that is nearly a year old (and even older as time goes by). A lot of people use their own camera rigs so I think the feedback is valid.

Btw, another thing I noticed is that the angle snapping is a bit unorthodox in this asset. When you start dragging normally (without snapping) and then enable it (by pressing control), the snapping will occur according to when ctrl was started being pressed rather than according to itā€™s original orientation when drag was initiated. Thatā€™s not how snapping usually works in 3D authoring software.

7

Aā€¦ I understand. You would like to use the most recent version of the package. Makes perfect sense :slight_smile: Well, regarding the camera, you can easily do that by disabling the EditorCamera script and attaching your own script on the camera. The only thing to keep in mind is that it has to be the same camera object that is created when you initialize the system.

Regarding snapping, I will look into it and see what can be done.

My fault with the name, sorry about that. I honestly didnā€™t think it would cause any trouble :wink:

8

Thatā€™s the thing though. Itā€™s pretty big to assume the user only wants to use that specific camera. There are so many different systems, and imo objects should be selectable and the gizmos usable regardless of what camera is used.

I may be wrong here, but I think the main thing people want when buying this asset are the gizmos. These other systems should be addons to them, not mandatory components that are automatically added even when disabled.

Shortcut keys should be possible to disable, or at least tweak, and the actions these keys execute should be available programmatically without having to edit your source code. Undo-redo should be optional as well.

I sent you a PM with some other suggestions.

9

And it works awfully. You gave no option to stay with simple collider system. Tragically inefficient.

Hint: Image game object with collider only without mesh which acts as a group for children models.

10

Hi there,

I am sorry to hear you experienced problems. I understand the example you provided, but have you actually experienced any slowdown?
In any case, this option will be available in the next update.

EDIT: Part of the reason why this system was implemented was to allow 2D sprite objects to be selected correctly. 2D colliders did not work well with the selection mechansim. I do not remember the exact issue, but I needed this for multi-selection.

Thanks for the hint!

11

Sorry XGT08, no hard feelings. I simply updated library because i wanted some of functionality and API change was so big I spent whole day to merge things in project to find out that performance dropped 2-3 times.

I will send PM to you with pointing where and why I have these drops.

12

No problem :slight_smile: I sent you a PM in response.

13

Hi there!

Iā€™m interested in purchasing your product.

My main use would be to tweak objects while actually playing the game, so Iā€™d like new instances, new positions, new scaling to be kept while returning to the editor.

Is this possible to do out of the box, or do I have to code it myself? Are you providing another asset to do some runtime permanent changes to the scene?

Thanks for your time.

14

Hi there @NeatWolf ,

EDIT: Wow. I initially thought you were talking about another package (I mixed the forums up :)) and my initial answer was related to that instead. So to rectify, at the moment this is not possible, but if you give me some time, I will try to do it. One note from me is that the way I can see this implemented is that it will require you to attach a special script to all objects that you wish to have their info persist. Would that be acceptable to you?

Best regards,
Andrew

15

Hi, I believe so, thanks, but I still havenā€™t even got the asset :wink:

But Iā€™m still a bit confused about what exactly the asset (and Runtime Widgets, and Octave3D) does.

By Runtime you mean, in the Game View, or runtime as per in a complete build?
Could you please compare your products? There are a few parts that seem to overlap.

16

Hi there, :slight_smile:

Ok, so hereā€™s a short summary for all packages:

  • Runtime Transform Gizmos - allows you to use transform gizmos (like the ones inside the Unity Editor) either in the Game view (while in play mode) or in a build to move, rotate and scale objects. The idea is that you sometimes may need to build an application (or game) that requires object manipulation at runtime (build or game view). Unity has an API for allowing you to work with gizmos but only inside the actual Editor environment and they are useful when building Editor extensions. This package also contains some bonus features like a camera, object selection and Undo/Redo. Currently, these are all coupled and must be used together (except for the camera which can be replaced with a few constraints). I am trying to decouple the systems to make them work independently as much as possible. Still in work.

  • Runtime Widgets - same as the previous package, but this package gives you access to those visual widgets that you see when editing colliders, lights etc inside the Unity Editor. For example, if you have a box collider in a Unity scene and click on Edit Collider in the Inspector, a visual representation (I call it a widget) will appear which can be used to alter the box collider size. Again, it can run inside the Game view or inside a build. A package like this might be useful if you were implementing an Editor-like application which allows the users to change properties for different colliders, lights, reverb zones, controllers etc. This package also comes with an Undo/Redo system. This package does not require 'Runtime Transform Gizmosā€™ although the 2 can be integrated to work together. There is a chapter in the Runtime Widgets documentation about how the 2 Runtime packages can be integrated, but this will change when the system coupling in Runtime Transform Gizmos will be removed. In that case the integration might require developers to write a bit more code, but it would be more flexible.

  • Octave3D - this is a powerful level design which runs entirely inside the Unity Editor (no game view or build). Contains snapping functionality ideal for working with modular pieces, mesh spawning/painting, a prefab management system and many many more features.

You probably mean Runtime Transform Gizmos and Runtime Widgets. Octave3D doesnā€™t have anything in common with these 2. The overlapping has to do with the fact that they both implement functionality which exist inside the Unity Editor but allows developers to use that functionality at runtime (build or game view).

I hope this helps, but please let me know if you need more info.

1 Like
17

Thanks!

I think I may need more Octave3D than Runtime Transform Gizmos (of course, everyone has its needs, I may eventually need all 3 assets in the future :wink: )
My only reason to buy Runtime Transform Gizmos would be for the unimplemented feature of making object ā€œstickā€ to their changes when switching back to the Editor from Play Mode.
That would be really helpful when you need to do a lot of fine-positioning of objects but you also want to see it how it looks in game with all its features running (PostFX, camera settings, being able to determine the distance of a platform and tweak it in at play time, fixing wall holes, spotting glitches, checking for actual positions of the objects according to the playerā€™s view and logic, checking for distances, eg: decorating a house)

18

:slight_smile: Great!

I guess when you talk about changes, you mean position, rotation and scale, right?
Well since I am already working on an update for Runtime Transform Gizmos, I can try to implement that feature. I think it will work. Just please allow me some time, I guess 2 or 3 days to fully be able to come up with a stable solution. I donā€™t want to make any promises that I canā€™t keep :wink: But my guess is that it will work as long as you can live with the fact that you will have to attach a script to the objects which you would like to persist.

I will keep you updated on this :slight_smile:

EDIT: Strangely enough, Runtime Widgets allows you to preserve the changes made to colliders, lights etc via the widgets in Game view. I do not know why I didnā€™t think of this for Runtime Transform Gizmos also. So this is a great idea and I would like to thank you for it :slight_smile:

1 Like
19

Position, rotation, scale, and maybe duplication, deletion and group selection/manipulation :stuck_out_tongue:
Attaching a script manually on every object in a scene that could be modified sounds very unpractical and time costly. What about centralizing the changes on a single object, or instantiating such components at runtime as soon as an object gets modified, passing the extra info structure (scale, position, location, bool pendingDestroy, GameObject pendingCreate) to be preserved to a PlayModeChangesManager (which basically keeps a collection PlayModeChangeInfo) just before exiting Play mode? This way all these helper components would be destroyed when returning to Edit mode and no further cleanup would be needed :slight_smile:

It was just an idea, but youā€™re welcome, I think this could be a great addition to Runtime Transform Gizmos, or even an idea for another asset :slight_smile:
Iā€™ll be watching this thread so that I can follow its updates :slight_smile:

20

Hi there @NeatWolf

I can understand how the component solution may not be the best out there. I will try to come up with something else. I think you are right in that the changes for an object can be centralized. I will have to see how this fits with the current code base.

One thing to note is that Iā€™m afraid I can not help with the following: duplication, deletion and selection. Selection is something that exists at runtime only, it doesnā€™t affect the selection in the Editor. As for the rest, I believe these require knowledge of serialization techniques which for the moment I do not have :slight_smile: So what I can do is to preserve the position, rotation and scale of the objects. :slight_smile:

1 Like