Tag Info

New answers tagged

0

I think you should keep things simple in this case. The three switch system is a challenge with a solution and this Puzzle has two states, currently solved correctly and currently unsolved (or solved and then reverted to unsolved for some reason [timer?]). So you have a Boolean value and you need to store it somewhere in your game so the door could get it ...


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


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


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


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


0

(I cannot comment so I'm answering) If you build an array with reference for the types of the files (I don't know much of C++, so I'll pseudocode) tiles[0,0] = ref_to_fire_tile tiles[0,1] = ref_to_fire_tile tiles[0,2] = ref_to_grass_tile ... Where ref_to_*_tile holds a reference for a specific type of tile which inherits from a generic one, this way ...


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


0

To give an example to my comment public class Tile { //some variable stuff; public Tile() { //some constructor stuff; } } public class FireTile { //some variable stuff; public FireTile : Tile() { //sets player on fire //some constructor stuff ...


0

It sounds like what you want is named delegates. If I understand it correctly, your actions are just a call to a function in an existing component. Then all you need is to store a member function pointer and a pointer to the component, instead of a custom class. You can do this directly with member function pointers, or wrap it in a delegate class. It would ...


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


0

You should take a look at how games like Minecraft, Halflife, and World of Warcraft handle this, most games take the simulated client input actions and send them to the server and simulate the world on both the client and server and correct when the simulations differ by correcting the client state to match the server state. Here you can see the entire ...


0

It isn't necessarily as clean cut as you expressed but in overly simplified terms and generalized notions, you are on track. The thing to remember is that the client expresses it's intent to perform some operation. Some operations are entirely authoritative by the server. In these cases, the server must respond before the client can proceed. This works ...


0

The engine already uses many singletons. If someone used it, then they should be familiar with some of them: Unfamiliarity isn't the reason why singletons need to be avoided. There are many good reasons why Singleton is necessary or unavoidable. Game frameworks often uses singletons because it is an unavoidable consequence of of having just a single ...


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


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


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.


0

A thought. Have the player have their own world that's synched with the server world, then check for out of sync by using a special sync object with positional values (compare them every so often).


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


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


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


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

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


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


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


-1

An essential ingredient of singleton-elimination which opponents of singleton often fail to consider is adding extra logic to deal with the vastly more complicated state that objects encapsulate when singletons give way to instance values. Indeed, even defining the state of an object after replacing a singleton with an instance variable can be difficult, ...


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


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


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


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


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


0

Singletons to me are ALWAYS bad. In my architecture I created a GameServices collection that the game class manages. I can search add to and remove from this collection as required. By saying something is in global scope you are basically saying "this hting is god and has no master" in the examples you provide above I would say most of those are either ...


0

There is no reason for the Map and Player objects to communicate at all that I can see. So far as what you've told us we can assume that Player object only holds data about their position, but then what does the map hold? (rhetorical Q). It sounds like the objects are doing the same job. I.e. the map already knows the Player object's position. If your map ...


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



Top 50 recent answers are included