Jump to content
  • Advertisement

ThePointingMan

Member
  • Content count

    52
  • Joined

  • Last visited

Community Reputation

228 Neutral

About ThePointingMan

  • Rank
    Member
  1. ThePointingMan

    Inversion of control across libraries

    Yes, this sounds a lot like what I am trying to do. My confusion comes from the three separate libraries in your example (Engine lib, GraphicsGL4 lib, and the Graphics DX9 lib) all needing to know of some kind of abstract/interface GraphicsEngine class. In your example it looks like App game's constructor take some kind of abstract GraphicsEngine pointer, so app must know of this abstract class. In that case GraphicsEngineDX9 and GraphicsEngineGL4 must both also know about this abstract class, as they would be children of it so they can be passed into that constructor. Each of these classes are in different libraries though, so where does this abstract class exist? Does a copy of it just exist in all the libraries? If it exists in the Engine so that App can use it in its constructor, then how will GraphicsEngineDX9 or GraphicsEngineGL4 know about it? If it exists in GraphicsEngineDX9 then the engine would contain it since it contains the GEDX9 Lib, but then would a copy of it have to exist in GEGL4? That seems a little odd to me, but maybe it is fine? Perhaps I'm just missing some concept of abstract classes that is important here? There might be something I'm missing in what you are saying though, because I'm not entirely sure what you mean by "translation unit."
  2. Alright so lets say I've got a little library for graphics called... "GraphicsLib", a Physics library called "PhysicsLib", and another to hold them together... the "EngineLib." How can I go about making sure that EngineLib is not entirely dependant on GraphicsLib and PhysicsLib? I've read about Inversion of control/dependency injection and it sounds like it's the right thing for this, but it's left me a little bit puzzled.   What I've read about dependency injection is that you would create an interface and then inject the actual object you want it to be into the object using it. So in this example lets there would be an interface for the graphics and physics and then the Engine class would have a setter for each of those interfaces.   Now that's pretty straight forward but what happens when the graphics system isn't part of the same library? the interface needs to exist in both sections, the engine needs to know of the interfaces existence so it can call all of its functions yes? but then the graphics and physics libs need to know of their respective interfaces as well so they can inherit from them. Is Dependency injection really not the tool for the job here or am I just thinking about things all wrong?   I've also thought of an alternative where there is another library that both the "Engine" and the "Physics/Rendering" libs use that contains interfaces for everything the engine might use but... that seems like it could be a bit of a stretch to force this to work.
  3. I am liking the idea of the higher level code with knowledge of both ideas, and then keeping the actual character in the dark about everything, seems to be what most of you are suggesting too. So if I'm getting this right, the player itself will basically just be a block of data, it has some render information, its transform, and maybe some collider information, but it doesn't really do anything. Then I have some higher level systems like one for keeping objects grounded that has information about the physics world. the gamestate passes everything that needs to be effected by this system to it, all the players/npc's etc. Another example could be like... a player controller that tells the player to move based on input or something. Nothing is actually done by the character, only by things who's purpose is telling the player to do things.      Yeah haha, this is something I'm trying to push on myself, it's so easy to get lost in the idea of engine construction and completely forget about what you wanted to use the engine to make. I'm just making small scale 2D stuff too, so I really don't need to go overboard on engine construction.
  4. Heya! I've been doing some work on a little engine for myself, and I've stumbled upon a little thing that I'm not entirely sure how I should approach. I'm not sure how I should handle instances where an object needs to communicate with one of the modules of the engine. A specific example of this would be for a raycast. If I have a player who needs to care about whether or not their on the ground for example, when I update the player I'm going to want them to shoot a raycast down to see if there is in fact something beneath them. This would mean that the object needs to know about the physics systems existence, a dependency that I'd rather avoid! Searching through some older topics I've seen a suggestion that the objects store a pointer to the scene, and then the scene contain things like the collision system etc, an idea that scares me for similar reasons. Am I just being too paranoid about this? Functionally it would work to have these dependencies, should their existence bother me or would anyone be able to explain to me some better designs on avoiding these kinds of dependencies?
  5. I'm currently going to school for programming, and my 3d graphics teacher absolutely hates unity. He complains about how he can always tell when a game was made with unity because the load times will be huge for small things and he will think to himself, "That shouldn't have taken that long." Another complaint of his is that it does everything for you and thus leads to incredibly generic games. I rather like unity, as it allows me to wip up a game fairly quickly without having to worry about first making a framework, but I must admit hearing his hate for it does spark a bit of fear in me, in the long run if my productions do get bigger, despite unity's ease of use, will it harm my product in the end, or is that entirely dependent on the user? If my fundamentals of coding are strong enough does it's easy workflow still come with a price or is it just as efficient as any other engine or is my teachers hate for unity justified?
  6. ThePointingMan

    Smoothing out the ray tracing of a surface on a curve

    For the hover mechanic, I shoot a raycast straight down from the center of the ship, if the distance from the start of the ray to where the ray hits is shorter then a specific amount it moves it back up to the minimum distance. As for the physics engine, It seems as though Unity uses the PhysX engine. Unfortunately I can't give you specific pieces of code right now as I am not at my house, but when I return there I will put up some more info on how I am doing everything. I think this first suggestion AllEightUp gave will probably do the trick though! Thanks very much for your input. I'm also thinking of doing something like what rumblesushi suggested, I'm thinking having a raycast at the middle, nose, and back, all checking would probably be best.
  7. I've been using unity for some school projects recently, and I made a  racing game fairly similar to F-zero GX. It was really unpolished though, and I've got a question about one thing that I thought really needed polish. While the hover car goes along the track, it shoots a ray directly below it and orientates itself so that the car's up is the same as the surface's normal. Gravity is always pulling in the hover cars down direction. The biggest problem I am having with doing this is that with upward curves. Lets say I was doing a loop de loop. The car would move forward by an amount, then orientate itself and move forward again. If you are going fast enough though, you end up moving so far forward that you tap the surface of the loop de loops curve with your ship, making you loose all momentum. Does anyone have any ideas as to what I could do to work around this?
  8. Behold I am learning!
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!