Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

186 Neutral

About BattleMetalChris

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. BattleMetalChris

    Interfaces and code duplication

    So, the GameObject itself contains almost no data or functionality, except that needed to request and store pointers to the various components? It's basically just a collection (small 'c') of components? Almost everything it can 'do' is actually done by the components, which themselves are stored and assigned as necessary by the relevant logic units (renderer, physics iterator, game logic etc)? So if I had, say, a ball. The 'Ball' object needs to be drawn, needs to move in the world, and needs to react to its surroundings. When it's created, it would request a 'Renderable' component from the Renderer, which would create one, store it and hand a pointer to the new Ball object. The ball could then configure this accordingly and store the pointer. Now the renderer can happily get on with drawing whatever it has in its list without ever needing to bother with the actual GameObject to which each renderable has been attached. The same applies to the physics and game logic components. Am I getting closer?
  2. BattleMetalChris

    Best comment ever

    In a VBA project at work:   ' Bear in mind that every time the middleware gets updated, the API changes; I presume simply to keep VBA developers on their toes.
  3. BattleMetalChris

    Interfaces and code duplication

    Thanks for the advice and the quick replies :)     Riiiiightt..... I think I'm getting there. The concepts are still floating in my head just out of reach, but they're beginning to brush against my fingertips.   So, I could make a class called Renderable, which contains all the basic things such as position, graphics (or location of graphics at least). To make an object Renderable, I'd just add a pointer to an instance of the Renderable class, rather than directly inheriting from it.   My Renderer would need to take an object of type 'Renderer' - I think I see now where Interfaces fit in. I could make my object implement a 'Renderer' interface (but I'll not call it IRenderer, for fear of angering TheChubu...  :wink:  ) and implement a method to direct it to the renderer class. True, I'd need to duplicate those couple of lines but the actual heavy-lifting would be handled by the Renderer component.     Better?     Excellent read, thank you.
  4. BattleMetalChris

    Interfaces and code duplication

    To start, my background is C++, Just tinkering really; a few simple 3D games but nothing professional. Anyway.   I'm starting developing for my Android phone, which realistically means learning Java. Its been pretty easy so far as the two languages are similar.     However, I'm getting a little lost on the use of Interfaces. Every Java resource I've read goes crazy on the idea of interfaces, and uses them for almost everything. What I don't get however, is how they are better than plain old inheritance. The only thing they seem to be able to do is allow (a form of) multiple inheritance, which you're not allowed to do in Java by just extending classes, and in the cases I've been sketching out in readiness for coding, it appears to mean a lot of redundant code.   Say I have a class GameObject, being the abstract base class for everything in my game. Something in the game might be a visible physics object, so if I want an object that does that using Interfaces, I would write a Renderable interface and a Physics interface and implement both.   But say I have an object which doesn't use physics. I would have it implement just the Renderable interface.   Now I have my two objects which I can store in a collection and pass to a Renderer, the interfaces guaranteeing that both objects have the appropriate methods to be able to be drawn.   However, because Interfaces only contain the method declarations, not any actual functionality itself, in this case I'd have to write the drawing methods TWICE, for both the renderable physics object and the plain non-physics object.   In C++, I'd just have them inherit from a Renderable and a Physics base class to give them all the functionality they need, but in Java I can't do that as you can only inherit from one class. Given this restriction, currently, I'm looking at just having a Renderable class extend the Base class, and the Physics object extend the Renderable without using Interfaces at all. But given how much they're pushed in the various coding resources, I can't help but think I'm missing something.       Why are Interfaces used instead of just Inheritance alone?
  5. BattleMetalChris

    Work in progress

  • 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!