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


34

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


12

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


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


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

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


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


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


3

It isn't uncommon for parts of a code base to be considered cornerstone objects or a foundation class, but that doesn't justify it's life cycle to be dictated as a Singleton. Programmers often rely on the Singleton pattern as a means of convenience and pure laziness rather than taking the alternate approach and being a tad more verbose and imposing object ...


2

Your question is a bit wider than you exposed I think. Player and Map are two objects and should be thought as it. They are not different, from an engine point of view, of a ping-pong table or a flying toaster. That said the question is : how to make NORMAL objects findable and communicate? For a map / player relation I usually put responsability... on a ...


2

A big reason for storing in text files is reusability. Creating a text game framework that reads your maps, dialog, and other resources from a text file allow you to reuse your framework for other games. Going beyond text games this is how big budget titles like Call of Duty release a new game every year. Another reason is portability. You can use the same ...


2

I think it is too easy to be the 'wither-than-white' guy and recommend warmly using an external text resource file. Why? Because there's a choice here that's about balancing each solution's cost/issues/advantages. When using an external file... Well, I guess the other answers explain the benefits well enough. But what about the costs? You have to define a ...


2

I think a key phrase is separation of concerns. If your code doesn't include the text than the code get's less complex. The programmer writing the code doesn't have to think about the specific text and can focus on the code. He doesn't have to think about localization. The person doing the localization doesn't have to worry about the code.


2

I can't believe noone mentioned this yet, but a big reason is to make localization A LOT easier. If you need to support English, French, German, Spanish, Portuguese, Italian, Russian, Chinese and whatever other language you're aiming at, hardcoded requires you to have separate code-behind for every language. It also means that if you need to remove certain ...


2

For the sake of making changes faster, it speeds up development on larger productions by tons. You don't need to teach everyone to learn how to go in and edit source to make simple changes. By dragging it out of the actual code, more people get the chance to fool around with, it's easier to find out what options you can play around with and the whole ...


2

That said, there is no golden rule for that kind of thing, but it will mainly affect your architecture. I would suggest you to take a look at the component pattern (which is used by some game engines such as Unity). This pattern will allow you to to "attach" component on game entity. In your case you will have, for example, a SnakeController component in ...


1

For engines written by you in native code Separate your render logic out. Every cycle, run all your game / simulation logic in one phase, and once that's all complete, run all rendering logic -- this includes animation. Since rendering and animation are separate, run game logic timers that use the same duration as the animations, but only have game logic ...


1

Getting null reference exception is normal since they were created in the previous scene and destroyed in the current one. To move them to the next scene, you need to call DontDestroyOnLoad. Why don't you create your assets after the scene is loaded? GameManager should be responsible for creating player and enemy objects and keep track of the game state. In ...


1

You need to remember that C++ is a multi-paradigmatic (OOP, functional, procedural, ..) language and you should use the programming paradigm that best solves your current issue. OOP doesn't lend itself well to this problem. In OOP you think about single objects in isolation (concept of "a tile"). But most of your algorithms will operate on a whole ...


1

I would advise against using inheritance to manage different tiles. Imagine how annoying it would be having to define a new class every time you add seemingly different types of tiles. That would result in a lot of implementations for simple things like a grass or a dirt tile. It is much simpler and more maintainable to make tiles configurable. Define a Tile ...


1

I guess licensing can also be a reason not to include content in the code. For example, your code might be FLOSS, but you don’t want to license your content at all (maybe you want to publish your game code so that others can use it for creating similar games with different content) your code might be FLOSS, but you want to use a Creative Commons license ...


1

Singleton is a famous pattern, but it's good to know the purposes it serves, and its pros and cons. It really makes sense if there is no relationship at all. If you can handle your component with a totally different object (no strong dependency) and expect having the same behavior, the singleton may be a good choice. On the other hand, if you need a small ...



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