Hot answers tagged

14

"Cracks" in the geometry mostly. These games have a few things in common, they have gravity and they have collision detection. These anomalies are locations where the collision detection failed in some way. It could have been sharp edges, gaps or a number of other geometry anomalies. Could even been issues with time steps in the physics engine, where the ...


13

The term "scene" in the context of Godot is kind of a misnomer. What a "scene" actually is in Godot is a reusable object template you can instantiate multiple times. You can edit the instances to give custom properties to each of them or you can edit the scene itself to change the properties of all these objects together. If you are ...


5

I think it's not possible to say that there is one particular reason why clipping through the world happens. Due to the differences in game engines/ physics procedures between games, any number of reasons can lead to this. Stemming off this, I'm quite sure that falling out of the world has not been eliminated, necessarily. Having a few large-scale game ...


5

My guess would be that older engines probably used a quick and simple ray vs triangle test to detect collision with the geometry. That means even the tiniest gap (or a precision error in the calculations) could let the player through occasionally. More modern games will probably use a more expensive test with a sphere or capsule representing the player, and ...


5

Don't hard-code it, or it'll indeed end up very messy. You need to script the NPCs daily routines into some data file (XML or other). Something along the lines of: <npc name="george"> <schedule start="0:00" end="8:00"> <sleep at="home"/> </schedule> <schedule start="8:00" end="9:00"> <walk leave="home" ...


5

Like many optimization questions, the answer here is "it depends." Having separate scenes for each version probably won't increase your game size by much, since the bulk of the storage usually goes to content both scenes can share via sharedassets#.assets files in your built data (textures, meshes, sound & music tend to be the biggest hogs), so in many ...


4

This is the difference between the UI and the in world objects. Your main menu is a screen space UI, the rest of your objects are in world objects, likely sprites. The reason they're vastly different sizes is just how the editor displays their size. The main menu (UI) has its size based on pixels. Maybe something like 1080x1920. The world objects have their ...


4

All you need to do is double-click the object you wish to get close to, in the Hierarchy view. This will rapidly advance the camera to that object's position. You can then use mouse wheel to adjust zoom. Other than this, I don't believe there is anything like hotkey-assigned zoom levels, unfortunately.


4

In Scene view. For Windows: To enter fast zoom mode hold Alt + move mouse holding Right Mouse Button. Press F to Focus on Game Object. Press Shift + F to Focus on Game Object and follow it automatically. Hold Right Mouse Button and move with WASD - the more time you spend doing it the faster speed of movement you will get. Note, that the more you zoom you ...


4

Unity already has a built-in event for doing exactly what you want: EditorSceneManager.sceneSaving Usage: EditorSceneManager.sceneSaving += OnSavingScene; private void OnSavingScene(UnityEngine.SceneManagement.Scene scene, string path) { //do some stuff here }


3

The nomenclature here is definitely odd. I at first thought you were talking about something lower level (like the scenegraph or screen manager for organizing logic flow and/or rendering). I then realized you are talking about what I would refer to as game state. Scenes are a popular term for it now with Unity, so I could see why you would call it ...


3

Prefabs are the way forward. In my opinion, every single entity should be a Prefab, even if you're going to only instantiate it once into the scene hierarchy (like a management singleton class etc). This'll save you many headaches down the line. A change to the Prefab will propagate to every instance in the entire project. Additionally, take a look at the ...


3

It is entirely dependent how you implement and construct your portals in your code, it sounds like you currently rely on the user to physically create a portal from a rectangular shape or poly and transform this into the correct position, which is an editor design consideration. You can however modify how you verify the placement and use of portals in your ...


3

Number 3 is easiest if you have an image that is tileable, meaning that if you put them next to each other you wouldn't be able to pick out the seam. Then you can draw the same image twice once on x,y and once on x+image.width,y. each frame you decrement x until x < -image.width where you add image.width to it. Adding details is easy by drawing some ...


3

Perhaps I´m over thinking it. Yes, you are. Transformation being done in shaders is meant to be literal. "Transformation" in this case being the application of some transform to the various per-vertex attributes. Where that particular transformation comes from is generally irrelevant to the shader. It is given a transformation, and it applies it to the ...


3

I have been in the same situation as you and this is how I solved it. Before that, some clarification: In my SceneGraph each SceneNode keeps track of its own local transform (scale, rotation, translation) and a concatenated transform (world). SceneNodes can have multiple components. BEPUPhysics is the physics library being used, its entity transforms are ...


3

Your idea is correct. The scene can be as big as you want. In fact, you don't need to bound it. You just create the correct camera and then set camera.setChaseEntity(mainEntity); But you are not creating the camera correctly. Look at the constructor: public BoundCamera(final float pX, final float pY, final float pWidth, final float pHeight, final float ...


3

Singletons, PlayerPrefs and the DontDestroyOnLoad flag are already three ways to pass data between scenes. There is also a fourth one: static variables which do not use the Singleton pattern but are only available to the local class. There is also SceneManager.LoadScene ("play_scene", LoadSceneMode.Additive); which loads a new scene without destroying ...


3

Time.time returns the number of seconds since the start of the game. "Start of the game" refers to the moment the game was launched, not the moment the current scene was loaded. If you want this movement to start 60 seconds after a scene has loaded, use Time.timeSinceLevelLoad instead. This returns the time in seconds since the last level has been loaded. ...


2

What you are probably reading is that it's seen as a mistake to reuse a graphics scene graph as the managed scene data structure for the rest of the program to work with. For a long while, back in the stone age, memory was tight and there was only one data structure holding a level together and it served rendering and game logic. Now we have a little room ...


2

Use a piece of data to denote your scenes. A simple enumeration is the easy way; even a string works just fine in a pinch. Your interface should be extended to have something like ESceneType getSceneType(); which returns the type of that scene (e.g. ESceneType.MainMenu or ESceneType.Pause or whatever). You then create a factory object which, using ...


2

Model, View and Projection matrices are passed as uniforms to the vertex shader, which uses them to transform vertex coordinates and normals. Typically projection matrix is constant between frames, view matrix is calculated once per frame and model matrix is unique for each object. Model matrix is in world space. This is of course not the only way to do ...


2

You are approaching the problem from the wrong side. You don't have a scene graph and need to integrate physic engine. You are using a rendering library that uses a scene graph and want to also use a physics library that does not use a scene graph. How about you step one step back and stop thinking about the solution domain (scene graph) and start thinking ...


2

You have plenty of options, and it really just depends on what your style is and the design of your game. One of the easier ways to handle this is with a simple scene manager. The first thing you need for scene manager is a script that persists between scenes. This can be done with a method called DontDestroyOnLoad. A very simple scene manager would look ...


2

Selecting the Camera Object and Ctrl+Shift+F seems to do the work in Unity5.


2

Unless you really have a good reason for having a pure virtual interface, I wouldn't bother. Nothing to do with performance, just the fact that with the interface setup, you have one extra class declaration that needs maintaining. If your scene objects are already encapsulated inside classes, there's no gain in having a virtual interface just to hide a ...


2

In your RespawnPlayer() method you are loading a scene at first. Then checking current position, then translating the player to the checkpoint. Upon loading a new scene, everything resets. In RespawnPlayer() after second line execution, the level manager restarts from Start() ignoring the current checkpoint and player translate codes in RespawnPlayer(). In ...


2

The following worked for me using version 2020: Pressing the F key on a terrain object reset the mouse sensitivity.


2

You can just put the line in the Unity API of DontDestroyOnLoad() inside Awake() method and your object will not get destroyed when you load a new scene. This does mean that you need to manage the object separately or use a Find() method to find and access it in later scenes. Keep in mind that if you include this object in all your scenes, you will end up ...


2

I would keep track of the current scene in a global variable called current_scene and try something like this: func change_scene(scene_path): call_deferred("change_scene_deferred", scene_path) # waits until an idle period when nodes can be removed safely func change_scene_deferred(scene_path): # remove current scene current_scene.free() ...


Only top voted, non community-wiki answers of a minimum length are eligible