We’re rewarding the question askers & reputations are being recalculated! Read more.

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 ...


10

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 coming from Unity, then ...


8

In general, it's not a bad idea to separate the game mechanics from their visual representation. When you have a game logic which is completely oblivious to how it is displayed on the one hand, and a graphic engine which creates a visual presentation of the current game state but doesn't care about how this state is created on the other, your code will be ...


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

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

I won't say it is impossible, I will say it seems impossible but I love the idea and you should definitely try it. I would start with duplicating the question on https://photo.stackexchange.com/ As for what techniques I would try: make a photo with a high contrast lightning, probably achieved by some back-light, e.g. a lamp hidden behind one of trees (or ...


4

Most levels in 3D platformer games are built on a 3D grid. The old Tomb Raider games are very obvious about this. (Press forward and the character moves one square every time, you know you can jump 3 squares if you are running but only 2 if you are standing, etc.) Even more recent examples, such as Darksiders 2 follow the same idea. The character has a ...


4

The Game State Management sample that deals with screen transitions can be found here. (The MSDN site recently updated their App Hub url's so I'm guessing a lot of links will be broken for a while) Personally I find some of the code to be too complex for beginners, with the constant use of events to be fired when menu items are clicked, and layering of ...


4

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" ...


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 ...


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

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

The AndEngine documentation states that a Scene is nothing more than a mere container for a specific game state. Logically, if it makes sense for each "level" to be a state - (they are distinicntly different and require some complicated setup or it's just easier), just drop the scene. A scene is a self-contained state - just make sure to be careful that ...


3

Generally you should prefer composition over inheritance where possible. In this example I would not have Sprite as a base class that game objects derive from. Whether to draw a sprite or not would just be a property of the Entity object. I might have Sprite and Text following a Drawable interface, and just associate them with Entities as appropriate.


3

Generally speaking, most people plug in a 45 degree angle in for the FOV. If you do this, a camera is then usually positioned just far enough away to include everything in the scene. No default on this distance because scale is so arbitrary in a 3d virtual world. There is a concept of a default lighting rig where you have 3 directional lights. One lighting ...


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

I think following link become useful to you in managing multiple scene in single game. https://sites.google.com/site/matimdevelopment/creating-and-managing-scenes Also in AndEngine forum, we discussed about this topic that link I provide to help other guys. http://www.andengine.org/forums/gles1/how-to-manage-multiple-scene-t10350.html


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

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

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

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

Try opengameart.org. There are some great models there. Mind the licenses though. :)


2

Consider to use component-based game object system: https://stackoverflow.com/questions/1901251/component-based-game-engine-design It is very flexible and modern approach which is good for middle- and big-sized games.


2

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 ...


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

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

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 ...


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