Tag Info

Hot answers tagged

79

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


35

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


29

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


18

The Application.Run call drives your Windows message pump, which is ultimately what powers all the events you can hook on the Form class (and others). To create a game loop in this ecosystem, you want listen for when the application's message pump is empty, and while it remains empty, do the typical "process input state, update game logic, render the scene" ...


18

As long as you keep your system relatively simple, this should work. But when you add things like temporary skill modifiers, you will soon see a lot of duplicate code. You will also run into problems with different weapons using different proficiencies. Because each skill is a different variable, you will have to write different code for each skill-type ...


13

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


12

I can't imagine designing a game without using object oriented programming, because my entire understanding of how to design a game-program is based on OOP. Then it will probably be good for you to try writing some programs in non-OO style. Even if you discover that this is not pragmatic for you, you'll probably learn a lot along the way that will help ...


12

They're typically not even handled by the same machine, much less the same codebase. The user profile is handing by a service that deals only with users. The simulation server deals with in-game things. There may even be another session server that ties the two together. The simulation server has an ID that corresponds to each user, so its Player class ...


10

Mick West's article explains the process of linearising entity component data, in full. It worked for the Tony Hawk series, years ago, on much less impressive hardware than we have today, to greatly improve performance. He basically used global, pre-allocated arrays for each distinct type of entity data (position, score and whatnot) and references each array ...


9

Any object-oriented program can be refactored to a procedural program by replacing all classes with structures and converting all member-functions into stand-alone function which take the object which would be this as an argument. So missile.setVelocity(100); becomes setMissileVelocity(missile, 100); or when that function is trivial, you just do ...


9

Isn't the code supposed to be analyzed from top to bottom like in regular Python so that the enemyTurn() is called just once and then the game goes back to waiting for user input? The code is executed just like normal code; your assertion here is correct except that your code doesn't have anywhere that "waits for user input." The function ...


8

String-keying / Hashmaps Are fast, as read time is amortized O(1), meaning that read access is usually very fast, but in worst cases (rare, but not unheard of), it can be quite slow. Worst case results from hash collisions. Implementations sometimes have to be built, or found (for instance, in C). Writing / finding a performant string-keyed map ...


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

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


7

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


7

window.localStroage is a more modern alternative to cookies. It allows you to store (semi-)persistent data in the users web browser which will survive a browser restart. The client-sided javascript can access it without having to consult a server, which makes it quite fast to access from the client. But contrary to cookies, localstorage is not directly ...


6

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


5

In object-oriented programming, you expose private data with getter-methods. When your player-class wants to know the terrain-type of a tile, it would call level.getTerrain(int x, int y). That public function of class Level would access the private terrain array and returns the value of the terrain tile. When you don't want the player-class to depend on ...


5

If console only, you have far less hardware related issues, since your pool of supported devices is minimal. With a PC, every last component can be made by someone else. So the list of potential compatibility issues is near endless. The newer Windows platforms have tried to standardize drivers a bit, but that doesn't really change the overall idea I'm trying ...


5

First, Fix Your Timestep. The component update should always have a fixed time interval. This is critical for stable physics and can avoid bugs in other systems as well. You may have cases where the time interval becomes huge, too. This can happen if you set a breakpoint while debugging. You'll want to cap the update time used for the time accumulator ...


5

If you're already putting in solid efforts to abstract engine code from game code, AND you want to keep your various game projects up-to-date with the latest version of the engine, then and only then would I suggest keeping it in a separate repository, since that would make it worth the effort. Otherwise, if you're only developing a single game, don't worry ...


5

I do it as follows: All OOP classes/methods have access to this. In order to utilise this in a non-OO approach, simply pass in whichever instance (see next point) this should be, as the first parameter. Now, as for instances, you can pass structs into your functions as this, but I find the best way to achieve good cache performance for objects which are ...


5

This is still, essentially, a factory, just not one that creates things via runtime keys. It uses compile-time keys (effectively) instead. You have touched on the major downside: you'll need to make this factory accessible everywhere you want to be able to create entities. This, however, is also an upside because it means you can control what interfaces are ...


5

AI being costly, performance is often the driving factor in architecture. To ease your concerns around data access models, let's consider a few different AI examples both in- and outside of the games industry, working from that which is furthest from human navigation to that which is most familiar to us. (Each example assumes a single, global logic ...


5

What you describe is a classic "pull" model of querying the world. Most of the time, this works pretty well, especially for games with basic AI (which is most). However, there are a couple of points you should consider that might be downsides: You probably want to double buffer. See game programming patterns on the subject. By always requesting the data ...


5

If it were me I would give each NPC agency of their own - if each one has a simple goal ( get as far as possible from Zombies/get as close as possible to humans ) that they act on, you can get quite interesting behaviours from relatively simple inputs without too much processing. The downside of this is that if you have a lot of them around you are going ...


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


4

A common approach is to write separate renderers or renderers with "feature gates." That is, you can make separate files for each API (GraphicsGL2.cpp, GraphicsGL4.cpp, etc.). You can then make some kind of IRenderer interface each implements or you can simply have one header and conditionally compile the renderer .cpp files for each platform (compile-time ...



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