88

The two are pretty different. The real indicator is in the names. Decision trees are just for making decisions. Behavior trees are for controlling behavior. Allow me to explain. A major difference in the two is the way they are traversed, likewise the way they're laid out and the node 'types' are different. Decision trees are evaluated from root to leaf, ...


84

There are several reasons for that. I'm just gonna touch on a few: It makes your source code a mess. If you have a lot of dialog (trees), a huge part of your codebase is just text that has nothing to do with your actual game code. You'd need to recompile every time you change so much as a single character. The dialog itself is hard to navigate. I imagine ...


77

OpenGL has four different major versions, not counting the versions for mobile devices and embedded systems (OpenGL|ES) and the Web via JavaScript (WebGL). Just like Direct3D 11 has a different way of doing things than Direct3D 8, so does OpenGL 3 have a different way of doing things than OpenGL 1. The big difference is that OpenGL versions are mostly just ...


67

You'd usually use an entity component system (An entity component system is a component based architecture). This also makes creating other entities way easier, and can also make the enemies/NPCs have the same components as the player. This approach goes in the exact opposite direction as an object oriented approach. Everything in the game is an entity. The ...


66

Favour composition over inheritance in your entity and inventory/item systems. This advice tends to apply to game logic structures, when the way in which you can assemble complex things (at runtime) can lead to a lot of different combinations; that's when we prefer composition. Favour inheritance over composition in your application-level logic, everything ...


61

The World should not draw itself; the Renderer should draw the World. The Player should not draw itself; the Renderer should draw the Player relative to the World. The Player should ask the World about collision detection; or perhaps collisions should be handled by a separate class which would check collision detection not only against the static world but ...


59

Usually you should separate the logical state of your game environment from the visual representation. The player might only see a small part of it on their screen, but you still keep the state of the whole level in memory and usually also calculate the game mechanics for the whole level. When your world is so huge that this would require too much ram and/...


53

There are ways to make nice 3d graphics with low memory footprint, however that requires you to have the right experience and knowledge. There are games like .kkrieger which is a 3d first person shooter, with the size of a few kilobytes. This is not just compression algorithms. You can't just make a massive game and press a button and suddenly its 100kb, ...


48

By simply only loading those parts of the world into memory which are close to the player. Anything else is suspended to hard drive. When there is a tiny object laying around two kilometers away, then the player can not see it and can not interact with it. So there is no reason to update it or send it to the GPU for rendering. The smaller the object and its ...


47

No it shouldn't. The only thing you'd be using from the inheritance is the x and y components. The methods used in a Vector2 class wouldn't be useful in a Vector3 class, they would likely take different arguments and perform operations on a different number of member variables.


42

Data-driven coding Every thing you mention is something that can be specified in data. Why are you loading aspecificmap ? Because the game configuration says that is first level when a player starts a new game, or because that's the name of the current save point in the player's save file they just loaded, etc. How do you find aspecificmap ? Because it's ...


41

I initialize my services in my main application class and then pass them as pointers to whatever needs to use them either through the constructors or functions. This is useful for two reasons. One, the order of initialization and cleanup is simple and clear. There is no way to accidentally initialize one service somewhere else like you can with a ...


41

Use a boolean flag. In the example shown, you'd modify the code to be something like the following: //a boolean flag that lets us "remember" if this thing has happened already bool thatThingHappened = false; void Update() { if(!thatThingHappened && mousebuttonpressed) { //if that thing hasn't happened yet and the mouse is pressed ...


39

As you mentioned, an actor can be literally anything; trees, NPCs, buildings, etc. A similar term is "entity". It doesn't need to have a behaviour in the traditional sense, it can be static. It's just a way to say "an object in the game".


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


37

You are going at it backwards. You start with the logical state of your game and model that. The whole logical state of the entire world will almost certainly be too much to be held in memory at once, so you break it down in smaller parts that can be loaded and saved independently. These parts are often referred to as chunks. These chunks can form a ...


35

Here is how a typical rendering engine handles these things: There's a fundamental distinction between where an object is in space and how the object is drawn. Drawing an object You typically have a Renderer class that does this. It simply takes an object ( Model ) and draws in on the screen. It can have methods like drawSprite( Sprite ), drawLine(..), ...


33

The answer is always to use an array or std::vector. Types like a linked list or a std::map are usually absolutely horrendous in games, and that definitely includes cases like collections of game objects. You should store the objects themselves (not pointers to them) in the array/vector. You want contiguous memory. You really really want it. Iterating ...


27

One quick way to get key-value pairs in Unity's inspector is to define a serializable entry class, and then use an array or List<> of them. eg... public class SpellAnimationMap : ScriptableObject { [System.Serializable] public class SpellAnimationEntry { public Spell spell; public AnimationClip animation; } public ...


27

At first you see that your commands are in the form of a list, so your first instinct might be to recreate that structure, and each dwarf will run through that list in sequence. What I suggest though is to break the list into steps, with each step having prerequisite(s), and then you run the entire command in reverse. Let me demonstrate with an example: ...


27

I think not overthinking this issue will give the best results so I would just implement a simple key-value saving system into your game that you store along your other save data and then load on-demand when you need to access a previous state. The flow could look something like this: Load level from file Before placing a tile / object check if it has a "...


25

A common approach is to have a component-based approach where the base-class "Unit" just implements the most basic aspects all units have in common, while each unit then has a list of multiple component-objects which say what it can do and how it does it. For example, a tank might have the components Mobile, Destructible, Attacker, an immobile turret only ...


23

TL;DR: Your game objects do not know about each other, nor do they perform checks against other objects. You create a collision detection and collision resolution pattern that checks your game objects and performs the appropriate actions to simulate your game physics. The Good Stuff From previous attempts at writing collision detection and reading this ...


22

You have two very different things to manage: The server must manage the entire world, in an authorative manner. For that, communication with N clients (where N is "massive") is necessary. The client could, in principle, know about the entire world, but it needs not. For the client, it is sufficient to know about what's nearby the player. Assuming for ...


21

Save the seed which you used to generate the world, and the modifications either as atomic "commands" or the results of those. Then when loading the saved game, you do the following: Procedurally generate the part of the world you're currently visiting. Apply the saved commands, or overwrite the generated elements with the saved ones. Update: And of ...


21

I've worked quite a bit with Mecanim in Unity, and feel I have a quite good understanding of how it works. Like you say, blend-trees are almost definitely the way to go for doing locomotion. Blend-trees are generally for when you want to continously blend animations to create the final output. Like give the player the control of how fast the avatar is ...


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