Hot answers tagged

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


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


19

Generally it is true, depending on your view point and in which direction it has moved, as well as the viewing angle. Note how in the first camera view, as the Red block is perpendicular to the camera view, the object seems to be twice as large in a perfect 1:2 ratio (Note the arrow pointing that it hits the edge of the view after being moved twice as close)...


17

You want a data-driven approach almost certainly unless your game is going to be completely un-expected and/or procedural generated to the core. Essentially, this involves storing information about your weapons in a markup language or file format of your choice. XML and JSON are both good, readable choices that can be used to make editing fairly simple ...


16

Why would you want to avoid that? Circular dependencies should be avoided if you want to make a reusable class. But the Player is no class that needs to be reusable at all. Would you ever want to use the Player without a world? Probably not. Remember that classes are nothing more than collections of functionality. The question is just how one does divide ...


14

A Poisson-Disk sampling distribution will allow you to select random points a minimum distance apart. Your situation is similar to this question, but since your trees aren't idealized points you'll need to change the distance checking as follows: the distance between a potential new tree & an existing tree, must be less than the sum of their radii. ...


13

Your current design seems to go against the first principle of SOLID design. This first principle, called the "single responsibility principle", is generally a nice guideline to follow in order not to create monolithic, do-everything objects that will always hurt your design. To concretize, your World object is responsible both for updating and holding the ...


12

fixed size array (linear memory) with internal free list (O(1) alloc/free, stable indicies) with weak reference keys (reuse of slot invalidates key) zero overhead dereferences (when known-valid) struct DataArray<T> { void Init(int count); // allocs items (max 64k), then Clear() void Dispose(); // frees items void Clear(); // resets ...


11

Not everything has a dynamic set of properties. In fact, much of software engineering is about trying to pin down a precise and static specification of something. Static hierarchies are easier to reason about because they're broadly fixed in the code. Components can lead to an explosion of possible permutations - great if you need that flexibility, but ...


10

Option 1 is a very bad idea, you might aswell be coding in BASIC. Option 2 sounds good enough for a Snake remake. Now start coding! :-) If you were making something bigger than Snake, or are just using Snake as a toy project to get to know more advanced software engineering practices for games, go for option 3: component-basedentity-system.


9

There is something you are doing right now that you may find that you regret later, even though it seems like a logical thing to do. You are likely to find that making each type of item its own class hard to manage once you have more than about twelve of them. My own inventory management systems don't have different types for items. Instead, I use a "...


8

An object twice as close does appear twice as big. It is a consequence of Thales's Theorem and it is true in the real world. One could argue that Thales's Theorem is the core mathematical tool behind perspective projection and what's known in the graphics pipeline (OpenGL or DirectX) as perspective division. It a theorem you should definitely know, and ...


7

For example, sword and axe are two different classes, both inheriting from weapon. Weapon and potion are also different classes both inheriting from item. I wouldn't do things this way; a sword and an axe differ mostly in their data, not their fundamental behaviors as weapons. Likewise with items. I would avoid this overuse of inheritance, starting by ...


7

Actually that's pretty much true (if you move an object twice as far away it looks half as big) but it obscures how the visual size of objects should change as the viewers moves. Specifically, objects appear to get bigger faster the closer they are. That's because the viewer covers half the distance a lot faster when the object is close, compared to when the ...


6

It would be a bad design to have separate classes for each of the level and will also duplicate your code. Why can't you change the level specific values before starting a new level (have them stored in as some constant or in text file).


6

I think OO OpenGL is not that necessary. It is different when you talk about shader, model, etc class. Basically you would do game/engine initialization first (and other things). Then you would load textures, models and shaders to RAM (if needed) and Buffer Objects, and upload/compile shaders. After that, you, in your data structure or class of shader, ...


6

There is another option. The player and the level are both members of the game object. However, I think the most common practice is to make the player an object inside the level. This has numerous benefits. For example, the level will process collisions between objects. Adding all the objects into the same level pool allows you to reuse the collision code ...


6

(I'm sorry to submit the answer instead of a comment, but I don't have rep yet.) Vaughan's answer is great, but I'd like to add my two cents. One of the main reasons you'd want to use XML or JSON and parse it in runtime is to change and experiment with new values without having to recompile the code. As Python is interpreted and, in my opinion, pretty ...


6

I need a tutorial that does not skip to explain any lines of code. It should also include different independent objects moving/rotating (most tutorials use only one object), as well as imported 3d objects Arcysnthesis is the best modern OpenGL tutorial I know of, using imported objects doesn't add much to the use of the API, and it's usually API agnostic. ...


5

As to but what would the method be when the player logged in and you needed to get their inventory etc You need to look at Managing Sessions and State with PHP or PHP Session Management With Cookies. In general when the player logs in you'll query the database for all the information needed to hydrate the objects associated with the player, such as ...


5

Most games don't have different classes for different entity types, because it's not very flexible. Your example is a classic case of why this is so! Classical OO with one-class-per-noun is great for toy problems but not so good in the real world. I'd suggest using the Strategy pattern, and swapping out a behaviour object that encapsulates the key ...


5

Keep Bullet functionality in the Bullet class. This just sounded like nails against a chalkboard to me: During the iteration, it checks what type of object it is, such as Bullet etc. Once it has checked this, it will calculate where the bullet should move to next based upon the Velocity property. Aaagh. D: It's not the base Entity class' responsibility ...


4

Here's what I would suggest: Start with a GameObject class. These will be objects that can interact with each other. Then, derive three children from it: Snake, Food and Wall. Each will have its own Update function. Finally, you have a Scene which holds a list of GameObject's. The main loop calls the Scene's Update every frame, which calls the Update ...


4

If your level classes have a common Base class you can just create a pointers to it: class Level { virtual void func1() //... virtual void funcN() } class Level1: public Level { virtual void func1() //... virtual void funcN() } class Level2: public Level { virtual void func1() //... virtual void funcN() } Vector<*...


4

There's certainly no "right" way to approach this problem, but there are better ways based on software engineering guidelines and principles. From what you've described, I'd approach the problem this way: A level contains a set of agent objects that exist within the level. Agents could be any kind of character or other entity, player-controlled or not. The ...


4

Data-Driven Design I submitted something like this question to code review recently. After some suggestions and improvements, the result was a simple code that would allow some relative flexibility on weapon creation based on a dictionary (or JSON). The data is interpreted at runtime and simple verifications are done by the Weapon class itself, without the ...


4

Simple Answer Use a class to load the original prefab from Resources.Load(string prefabPath, typeof(GameObject)); Store this returned prefab into a resource pool class by path key. For instance: Dictionary<string, GameObject> prefabLookup; You can then grab the original prefab anytime you need it. Use a helper method to automatically load at ...


3

You're doing it wrong. Making a class for each level? No, levels are data, not code. Make a generic Level class, and then load .level (or whatever) files into it. The files then should just have a list of all the resources that need to be loaded, a list of events/scripts, and so on. Why? Because then you can make a separate level editor, that creates the ....


3

From the easy to the scalable and complex to implement, kind of: A fast to write option is simply to let the HUD know where the player is and let it grab what variables it needs directly. It's not very flexible, but for games where the player is well defined and the scope of the game is tightly contained it can work well enough. This is a tightly coupled ...


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