38

When you are comming from non-game application development, then you need to be aware of a couple things. Relational databases have a niche role in game development. You really only need them when you have a massive multiplayer game where most of your players are offline most of the time. There are also some niche applications like online scoreboards or ...


5

I believe an option available to you is to use std smart pointers, more specifically the std::shared_ptr and std::weak_ptr. Typically, those pointers represent ownership. They also offer a ref-counting mechanism, and I think it's this feature that you're after. std::shared_ptrs hold a reference to a dynamically allocated object, a count of "hard" ...


4

What kind, and how many, allocators you need depends on what you're doing with memory. If you want a particle system, then you should probably create a pool allocator, as it's often the most efficient for the job. If you have assets that are loaded and unloaded sporadically, you'll need a more dynamic allocator (which is often less performant). So it all ...


3

Code vs. content Game level layout is typically stored separately from your codebase. Why? Because as you've discovered, the cost of change for code is higher than the cost of change for say, a text file. In your simple case, I would opt for something like what Angband does to describe its vaults: %%%%%% %%%..##..%%% %%....####.......


3

Why have we arrived at the convention that rotations should be counter-clockwise then, even in engines where positive y is down? Have we? Let us try CSS: const box = document.getElementById("box"); function step(timestamp) { let deg = timestamp/10; box.style.transform = "rotate(" + deg + "deg)"; window.requestAnimationFrame(step); } ...


3

Your DontDestroyOnLoad is exactly how I did it in Cognizer. I have hooks in the first script of each scene that will create the Game Manager object if it doesn't already exist. So I can start any scene, and everything works fine. Cognizer doesn't work unless the player has selected game settings through MainMenu, so each scene has BootToMainMenu.cs attached:...


3

The greatest problem when it comes to parallelization is sharing data between threads. When multiple threads read and write the same data structure simultaneously, then you will have a myriad of problems. Either you get very difficult to reproduce bugs due to race conditions (bugs which only happen when one thread writes something while another thread reads ...


3

You don't gain any benefit from polling for input faster than you act on it. Even if you read the input early on your input thread, it's just going to sit in queue for the next game update step to pick it up, accomplishing nothing in the meantime. So the situation is equivalent to the game update thread just reading all the input since the last update, and ...


3

In the book, the subsection 5.4.3 you took the example from is about "ideas". It doesn't seem like the code snippet is meant to be great C++, just good enough to serve as an example that explains the concept. Yes, you can substitute any hash map. "how would you then access the hash table in the rest of the game engine?" From the book, ...


2

A common solution to free systems from having to process every single event is by using a subscription architecture. Individual systems can subscribe to specific types of events. The event dispatcher manages these subscriptions and dispatches events to only those systems which subscribed to them. You can then further enhance the architecture by allowing ...


2

The current setup I'm using is to have a scene dedicated to GameManager objects (input, audio, game services, etc). Obviously that means I'm using a multi-screen setup. It looks like this: Loading scene Game Manager scene Main menu scene UI scene Base level scene (used by all levels) Unique scene per level At runtime, the Loading scene scene is set as the ...


2

One way to handle functions that don't logically belong to any one scene is to put them into an object that doesn't live in a scene at all, but rather as an asset in your assets folder. For instance, we could make our manager a ScriptableObject: [CreateAssetMenu(fileName = "GameManager.asset", menuName = "Managers/Game Manager")] public class GameManager : ...


2

To address your initial concern, unless you are targeting older generation consoles or embedded devices, you probably don't need to worry about fragmentation. With that said, one way you can address the problem is to have a dedicated memory pool for strings which are then interned. With string interning in C, you create a hash table where the keys are ids ...


2

Vaillancourt's answer covers why we need to provide floats to work with our graphics acceleration APIs, but I think we can go a bit deeper into why do our graphics acceleration APIs expect floats in the first place. So why do we even have graphics acceleration APIs? It's important to remember that one of the big reasons hardware graphics acceleration came ...


2

FString (and all types that are prefixed with U,F,T etc.) are custom Unreal Types. They have special behaviour and work hand-in-hand with Unreal's Typesystem and Garbage Collection. Use string and other raw types if you want to program plain C++ Code. Use the Unreal Types if you want to interface with your Game.


2

This is the idea how to upload data to gpu: glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, m_vboID); void *vbo = glMapBuffer(GL_ELEMENT_ARRAY_BUFFER, GL_WRITE_ONLY); memcpy(vbo, indices, byteSize); glUnmapBuffer(GL_ELEMENT_ARRAY_BUFFER);


1

I generally prefer ScriptableObjects for storing data that: You want to be editable with a GUI in the Unity Editor (as they can be edited in the Inspector much like the components on a GameObject) Is determined at design time and will not change at runtime You want to be able to assign to fields in the Unity Inspector Here's the typical strategy I'll use ...


1

Let's say you have two ordered lists of nodes that connect two rings. For this example: list1 is the more inner ring with nodes a b d c list2 is the more outer ring with nodes Q R S T I'm going to refer to the nodes & edges between rings as 'spoke nodes & edges' and I'm going to assume that they line up in a one to one fashion. That means there ...


1

About option 1 (that's the one I suggest because I used a similar approach): Main drawback of such approach that I need to implement some kind of workaround to feed transformation to this models. I don't think it's a "workaround". You need a function in a system that will propagate the physics simulation results to your Transform (for those ...


1

In first case, you are creating God's Facade (combination of God Object and Facade), which sole purpose is convenience. There are many downsides to it, but I want go straight to the elephant in the room: you'll have to build underlying systems first before you can build your facade on top of these. My conclusion here is that facade should be optional and low ...


1

While this depends a lot on the amount of your items and the data associated, I do not see much issue with using an EAV solution - anything currently in use will be stored in RAM as regular old objects, all the "heavy" database interaction happening only whenever inventory is loaded/unloaded as the player enters/leaves the game. If you insist on more ...


1

One way this can be solved is with the notion of Archetype. An Archetype is the set of components a particular entity needs. So in your example you have two archetypes: (position, velocity, visible) and (position, velocity). For each archetype, you store an array of each component it needs, densely packed, representing all entities of that one archetype. ...


1

You could have a function that takes in a string, which can be loaded dynamically, and returns a new ability. Ability createAbilityById(String s) { switch (s) { case “leap”: return new LeapAbility(); case “foo”: return new FooAbility(); ... } } You can also look into reflection if your language supports it, but it may be ...


1

I would suggest two different ways of solving your problem. One close to your current implementation and another more abstract concept, but that is easier to use in the long run. First the simple changes. If i understand it correctly, your roles are all subclasses from objectclass. Since objectdoesnt have the onDraw-method, you cant just add it to the ...


1

If you distinguish these button types by making derived classes for each, I would have the AbilityButton class have an abstract Draw() function and each of the derived classes would then implement the draw function their way. Then you would be able to have a list of AbilityButtons and call their Draw() method, not caring if it is one or the other from the ...


1

What you want is baseclass inheritance or an interface. If the UseAbility method is same or similar among "Classes", you probably want a baseclass otherwise an interface. Lets take the interface route for now. The interface (lets call it PlayerClass) defines the UseAbility method. interface PlayerClass { void UseAbility(yourKeyType key); } All your ...


1

I'd recommend you solve this with composition over inheritance. Let's say we have an ability interface: public interface IAbility { void UseAbility(); } Now my berserk ability can be a MonoBehaviour component that implements this interface: public class BerserkAbility : MonoBehaviour, IAbility { public float duration = 5f; public float ...


1

As I understood it, i would make a table "Inventory" this table would contain just things like "ID", "Reference to the item" and then also additional columns like "durability", "attribute1", "attribute2".


1

Others already gave good answers, but i wanted to add and clarify couple of things. There are various approaches to architecture and it may seem like Actor is the same as Entity or GameObject, but there are pretty big differences between them in practice. Actor indeed lives in a Scene and acts, "living in a scene" means that it has some positional ...


1

If this object belongs to a scene, I would consider the scene an object in and of it self. In other words, I would have a top level object with a SceneXManager, with references and/logic for the objects inside itself. The SceneManager would be enabled, and the reference to the other object would be set via the inspector. Then it does not matter if the ...


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