6

You're using a std::vector<Bullet>. This has the advantage of keeping data contiguous in memory, so iterating over it is fast (it has something to do with cache efficiency vs cache misses). The way you're using it is slow. auto it = Bulletlist.begin(); while (it != Bulletlist.end()) { if ((it->del)) { it = Bulletlist.erase(it); } else ...


3

Creating a seamless open world without loading bars is not an easy task. There are lots of small and large problems which need to be solved. This is not a beginners project! The basic approach is usually to divide the world into sections and only load those sections which are around the player. When the player moves around the world, new sections and their ...


3

To restart your current scene, you need current scene index or name. And once you have the current scene index or name then just reload it. Here the example that how i done it: public void RestartCurrentScene() { int currentScene = SceneManager.GetActiveScene().buildIndex; SceneManager.LoadScene(currentScene); } Add this to the very top ...


2

If performance is an issue, you might wanna use a design method/pattern called Object pooling. What this method/pattern actually means is that you, at the start-up of the game/level/scene, fill a container (an std::vector, an std::list etc) with a fixed number of objects, bullets in your case. When a bullet is supposed to be shot in the game, the code ...


2

I most often encounter this in the context of Unity, which has the following attributes: Input is checked once per displayed frame, before any of that frame's fixed/variable timestep updates Input is interpreted as one flat state for the entirety of the current display frame, not a queue of events Each logical button has three independent boolean states: ...


2

First of all: M-VC Separate Game from GUI - a suitable approach might be M-VC (Model-View/Controller). If you do it right, there should be NO REFERENCE on the game towards the controller, but the controller knows about the game. Doing it that way you can create controllers for any GUI you want (Android, JavaFX, TCP/IP) without ever changing the game. ...


1

Collisions are part of the physics update, which is typically handled in the fixed timestep loop (what you call "tick" here). By handling collision detection and resolution at a fixed game time interval, you help ensure that the physics play out consistently even on very different hardware. If you do physics on a variable timestep (like in the render loop),...


1

'this' was nullptr and It said that it wasn't able to get the value of the following variables [...] You're trying to modify an object that does not exists. This could have worked in the older days, and you would have had a really hard time to figure out what was going on. Today, the systems are smarter and it's really harder to shoot yourself in the ...


1

The reason you see the rapid back and forth movement as it tried to align itself to the player's axis is because of overshoot, as you probably guessed. I reconstructed what I believe you are trying to do using Vector3.MoveTowards instead. This function is useful because it does not overshoot. Unfortunately this code is untested so let me know if it works. ...


1

Your main game loop should usually loop through 3 main processes. Each of these processes usually run in context to a specific scene/screen in your game .. menu screen, gameplay screen, exit screen , etc. Process input: this is usually where people use an observer design pattern and create an event dispatcher which dispatches events to game objects who are ...


1

Just to expand on the other answers a bit: Unity and Unreal both use separate threads for update (typically called the "game thread") & render, specifically to keep them from slowing each other down. You'll typically see the game rendering lagging a frame behind update / physics because of this. In Unity, graphics operations are internally queued up ...


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