Tag Info

Hot answers tagged

81

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


74

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


36

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


30

Putting game content data in code means that to see any potential change or iteration of that game content data, you have to recompile the game itself. This is bad for two reasons: Many languages that games are written in have long compile times. C++ is particular can be very bad in this respect, and C++ is a very common language for large commercial ...


25

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


16

From an API design perspective, when deciding whether to make multiple separate communicating programs or just one, the question is: can each program function meaningfully without the others? The answer will vary based on your project and preferences. If they can't, it's not worth thinking about. Clearly they're so heavily linked that they're not really ...


14

I won't discuss about the evilness behind singletons because Internet can do that better than me. In my games I use the Service Locator pattern to avoid having tons of Singletons/Managers. The concept is pretty simple. You only have one Singleton that acts like the only interface to reach what you used to use as Singleton. Instead of having several ...


11

is it worthwhile to have a separate process that listens for connections and messages from clients and sends the data via local sockets or stdin to another process that runs the actual game server? To answer whether it is worthwhile, you had to first ask yourself, what is the problem you are trying to solve by adding a dedicated queuing service. If it ...


10

Reading all these answers, comments and articles pointed out, especially these two brilliant articles, http://gameprogrammingpatterns.com/singleton.html http://gameprogrammingpatterns.com/service-locator.html eventually, I have come to the following conclusion, which is kind of an answer to my own question. The best approach is not to be lazy and pass ...


10

If you can make sequences pretty general, there's not much of a spaghetti code. In case of deliveries e.g.: WorkTask operates with a WorkPlan. Workplan says what kind of resource unit must pick, from what kind of house, using which walk animation, using which work animation, time to work and all such details. So in the end WorkTask might look like: Find ...


9

The primary difference is how up-to-date the strategies are. The immediate mode used in the first tutorial: glBegin(GL_QUADS); glColor3f(1, 0, 0); glVertex3f(0, 0, 0); glColor3f(1, 1, 0); glVertex3f(100, 0, 0); glColor3f(1, 0, 1); glVertex3f(100, 100, 0); glColor3f(1, 1, 1); glVertex3f(0, 100, 0); glEnd(); Is outdated and not supported on ...


8

You should consider shader programs as similar part of the state as textures. Changing the state is expensive, so you may be able to get away with combining several textures to one to avoid texture changes; the same applies to shaders - you may be able to combine several shaders to avoid state changes. Similarly to combining textures, combining shaders ...


8

I'll try to answer to the best of my knowledge, with little knowledge about the specific case of UE4, but rather on the general technique. Graph based materials are as much programming as writing the code yourself. It just doesn't feel like it for people with no background on code, making it seemingly easier. So, when a designer links a "Add" node, he is ...


7

As always, as always, it depends. But first, I would like to argue that hard coding is not bad by itself. I have hard coded content, specifically dialog text, in some simple games, and the world didn't end. We programmers love abstracting things, but remember that each layer of abstraction you make will make your program more complex and more difficult to ...


6

It is fine to have lots of instances. An instance of a class without virtual methods is just like a POD C struct in terms of memory consumption which is similar to primitive data types. It is no problem. Your concern when instantiating many instances of a class are resource related I would think. CPU - should not be affected because you will be ...


6

A design pattern I've enjoyed using has two types of things: task management and task execution. Task management asks the question "What should I be doing right now?" And task execution asks, "How do I complete the current task?" Task Managers The job of the task manager is to constantly look at the AI's internal state (read-only) to determine whether new ...


5

Because operations dealing with objects and their locations, such as collision detection and filtering nearby objects, are so heavily used in games, it is common practice to use one or more spatial data structures to describe your world. Some examples of these structures are grids, octrees, or the classic scene graph - a tree storing relative ...


5

From a performance standpoint, having data in memory is orders of magnitudes faster than having it in a database. There are two reasons to put data into a database instead of storing it in memory: You have more data than fits into memory You want to make sure no data is lost in case of a (intentional or unintentional) server shutdown As you already said, ...


5

In a "pure" ECS, your entities consist of just a unique ID, which shared among its components. For example you may have these entities: Entity ID 123, it is drawn and moved Entity ID 234, which is only drawn Thus you'll have the following component collections: Drawn components: <123, 234> Moved components: <123> There is no need to filter in ...


5

So this is basicaly topographical sorting problem. You have a graph, each node is a task that needs to be done, and some nodes depend on some other nodes (this is represented by an edge in the graph from depending node to the node it depends on). You want to do all the tasks, so you need to produce SOME ordering of the nodes that is topographicaly OK (the ...


4

Deep within the game engine your mesh is defined by your vertices, your indices (which define how to draw the triangles using the vertices), and its material (which consists of the shader as well as other parameters). Submeshes allow you to define separate lists of indices and materials (depending on the engine) over the same vertex data which is useful not ...


4

Constructors and destructors in C++ are about the lifetime of the object. Your problem is that you are mixing up the lifetime with the desired behavior of the object. The solution is to decouple them. Give the appropriate entities an "OnDestroy" function, which is called by your game logic when the entity should be (according to the rules of the game) ...


4

I wouldn't bother that much with trying to fit the game in the mold that comes with MVC or any other pattern until I know for sure that it's the simplest way to develop it. Especially since most of the time you'll implement multiple known patterns in the same program, or alter patterns after you notice they don't quite fit in your program the way they were ...


4

You really don't have much choice. Ignoring some (IMO) terrible other options, you can either: a) couple your behavior to specific animations - so artists don't make one attack animation, they make several that your behavior plays at the appropriate times or b) have animations emit events and export state variables that game logic is driven from - ...


4

I agree with ratchet freak. As long as you have a single gameserver, it's not worth the trouble. However, this architecture might prove useful when you need to scale up horizontally. When one gameserver is no longer enough and you need to distribute your game on multiple gameservers for performance reasons, the "socket server" architecture could very easily ...


4

It's not necessary, in the sense that you can make it work. But your approach is somewhat... awkward. In your approach, the pre-render and post-render work (such as clearing the appropriate render targets, and then presenting the final frame the screen) has to be done before and after getUserInput(): while (game_is_running){ prepareForRender(); ...


4

I will risk and post almost-opinion based answer. What Unity is missing is decopled "system" element. It would be much nicer to have "Component-Entity-System" instead of current "Component-Entity". That is because of the problems you mentioned. The problem of communication you have mentioned can by solved by adding System. Unity Component, holds both, data ...


4

One way of handling this could be to implement some form of graph system: http://en.wikipedia.org/wiki/Graph_%28mathematics%29 Or as a state machine: http://en.wikipedia.org/wiki/Finite-state_machine In both cases you describe your quest states (stages) as nodes, and the edges/transitions as the actions that can be performed to move from one state to the ...


3

It's best to keep things as simple as possible. Duplicating the same shader for every object is unnecessary and will quickly get bloated. You also don't want one giant shader that covers every possible use-case, as this causes unnecessary overhead. There are several opinions on shader management and no "optimal" way to approach this. I've even seen some ...


3

I don't think that you should go with static class members (you didn't mention language but I assume some kind of OOP) because that just hides "singleton" in a different place. Switch things around so your Game holds a bunch (map, set, list, array, whatever) of these across-room global puzzles. Make it so your rooms can ask the game about a puzzle it's ...



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