Tag Info

Hot answers tagged

55

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


33

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


17

To come to your example I will explain my thoughts about Entites in videogames. I won´t discuss the general advantage and disadvantage of objects and classes, neither their whole role in Videogames. Entities in small videogames are mostly defined by seperate classes, in big games they are often defined in files. There are two general approaches to follow: ...


17

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


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


15

I reckon it would be cool that both troll and werewolf inherited its attributes from enemy and overwrote some of them. Unfortunately this approach to polymorphism, popular in the 90s, has shown itself to be a bad idea in practice. Imagine you add 'wolf' to the enemy list - well, it shares some attributes with werewolf, so you'd want to consolidate ...


15

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


13

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


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

Usually the distance of the midpoint of a polygon to the camera is being used for z-sorting. The painter's algorithm cannot be 100% accurate by it's nature. There will always be cases where sorting will fail, no matter what reference point you use. If you want correct z-sorting with the painter's algorithm, you'll have to slice overlapping polygons into ...


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


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


9

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.


8

I'm not sure what you mean by "too heavy," but C++/OOP is the lingua franca of game development for the same good reasons that it is used elsewhere. Talk of blowing caches is a design issue, not a language feature. C++ can't be too bad since it's been used in games for the past 15-20 years. Java can't be too bad since it's used in the very tight run time ...


8

Fundamentally, animation is the changing of a set of properties over time. Animating a health bar rectangle is just changing the width of the rectangle (or maybe the height) over time, whereas animating an on-screen 2D character is basically changing the image used for its sprite as well as its position over time. It's certainly possible to generalize an ...


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


7

Usually you have some separate class that does things like collision detection (collision-solver). So instead of Object A sending a "collide" message to Object B, you have a class that holds a list of all Objects. In one step (or update), the class checks collision for all objects in that list and stops when all objects have been checked. With this setup ...


7

The code in your question is fine. The problem must be in the code above it, perhaps you are doing something like this: // ... if (ks.IsKeyDown(Keys.Down)) { /* ... */ } else if (ks.IsKeyDown(Keys.Down) && (ks.IsKeyDown(Keys.Left))) { /* ... */ } // ... In which case the first condition will trigger and the second will not (due to else). Here is ...


6

Don't conflate the physics modeling of the universe with the graphics, that way leads to madness =) For something like what you're talking about an MVC architecture might work well. M = model. Your model is the physics simulation of the universe. While this may be a singleton you'll find many more arguments to making it a class that can stand alone but ...


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

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

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

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


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


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

Use GetPressedKeys() to get all of the currently pressed keys and iterate through them doing what you want. If you're moving the player or something, create an initial Vector3 at the beginning and add modifier values to it and add it to the player position after the input checking has completed. Something like this: Vector3 positionToAdd = Vector3.Zero; ...


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

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


4

Ogre3D offers a Plugin system, which I understand to basically be the equivalent of a normal .dll library except it has install()/initialise()/uninstall()/etc methods, intended for registering factories. So my confusion comes down to what would be best kept in a Plugin or DLL? Plugins are generally used to extend or build upon the ...



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