Choice of code design

Discussion in 'Game Development (Technical)' started by lordmetroid, Aug 25, 2007.

  1. HairyTroll

    Original Member

    Joined:
    Jul 29, 2004
    Messages:
    582
    Likes Received:
    0
    And where OOP isn't just limited to the 'OOP flavour' of Java or the 'OOP flavour' of C++. As both of these only support a subset of the whole OOP superset. Hence the need for design patterns to bridge this gap.
     
    #121 HairyTroll, Aug 31, 2007
    Last edited: Aug 31, 2007
  2. HairyTroll

    Original Member

    Joined:
    Jul 29, 2004
    Messages:
    582
    Likes Received:
    0
    Aha the 'annoying' pattern. I'm off to slam my head in a door now.
     
  3. bvanevery

    bvanevery New Member

    Joined:
    Jun 25, 2007
    Messages:
    369
    Likes Received:
    0
    Which means that some of these Design Patterns aren't that useful in the abstract. Rather, they are Language Inadequacy Patterns. I'll be reading up on Multiple Dispatch / Multimethods; a Vistor Pattern is just proof that something is missing.

    I got pissed at Scheme when I realized it contained no inherent dynamic dispatch, which I take for granted in C++ ala virtual functions. I could write my own dispatcher, which is great if I'm doing language R&D and actually want to, but from a productivity standpoint that's bollocks.

    I could use someone else's dispatcher; for instance Chicken Scheme has TinyCLOS. But I could not see committing to TinyCLOS as the way I'm going to write all my code from now on. I investigated Functional Programming languages because I wanted to get away from OO limitations, not just find some new cobbled together way to do them. If it's going to be almost like I'd do in C++, but with a gratuitously different syntax and a marginal gain here or there, I'd just as soon write it in C++. Generally speaking, C++ can make me money and the more exotic languages cannot.
     
  4. oNyx

    Original Member

    Joined:
    Jul 26, 2004
    Messages:
    1,212
    Likes Received:
    0
    I don't really want to spoil the fun, but all projects have different constraints, goals and environments. Batching for example isn't always necessary and quite often it isn't even possible to begin with. Some APIs simply don't offer something like that. If your game runs fine on the target platform it's fine, isn't it?

    As if that wasn't enough obviousness already... increasing the complexity of the code is alright as long as it's worth it (pwoar!). That is: if it lowers your hourly wage, it was a mistake. Sounds simple and well, it really is that simple.
     
  5. jlv

    jlv New Member

    Joined:
    Feb 8, 2007
    Messages:
    78
    Likes Received:
    0
    I didn't think I said anywhere that Car should be a subclass of Mesh. What I'm asking you is how do you write Rendersystem.renderNextFrame() without something like Mesh::draw()?
     
  6. voxel

    voxel New Member

    Joined:
    Oct 29, 2006
    Messages:
    176
    Likes Received:
    0
    It doesn't, but from the free/cheap public 2D/3D frameworks I've seen - this is a common practice and fine for small scale projects with single platform targets.

    To abstract the Mesh / Sound / Physics object from the underlying tech (DirectX / FMOD / ODE) is another level of complexity... when I mean abstracting, I also mean NOT using any of the headers. I didn't think I was clear the first time. You want to limit the external dependencies to a single area. This is why you see InputManagers, SoundManagers, etc. instead of objects inheriting from SoundObject (ok that's silly).
     
  7. voxel

    voxel New Member

    Joined:
    Oct 29, 2006
    Messages:
    176
    Likes Received:
    0
    Car would be associated with 2D/3D data via member pointer / inheritance / hashtable - whatever you decide. i.e

    class Car
    {
    private:
    Vector position;
    Quaternion rotation;
    Material material;
    RenderableData* mData;
    };

    In RenderSystem, it walks through it's list of renderable objects and decides, in order, what is rendered: background, opaque, transparent, particles - and potentially material sorting too (or whatever it wishes). RenderSystem goes through each objects render data (usually VertexBuffers) and sends it to DirectX/OpenGL/new-API.
     
  8. Huge

    Original Member

    Joined:
    Sep 22, 2005
    Messages:
    142
    Likes Received:
    0
    It helps a lot to talk about real examples, and I think voxel's example gets to the point. His RenderableData is probably going to be loded from a file by the gfx sub-system. It's going to have a "render" function. I don't see any way around this really. I would then imagine the Car's render function to look something like:

    Code:
    void Car::Render()
    {
       mBody->Render();
       if (IndicatorIsOn() && ( ((int)(GameTime()) %2) == 1))
          mBlinker->Render();
    }
    
    This is not going to have a performance impact - infact you could easily script it if you wanted to.

    When you talk about virtual functions, you need to consider the grainularity - and getting that right is an engineering problem. (ie, domain dependent, bit-of-an-art).
     
  9. Bad Sector

    Original Member

    Joined:
    May 28, 2005
    Messages:
    2,742
    Likes Received:
    5
    Wouldn't this make keeping the renderer state changes low a little harder?

    I would do something like this
    Code:
    struct Renderable
    {
        Mesh *mesh;
        Material *material;
    };
    
    // blahblah //
    
    class Car : public WorldEntity, Renderable
    {
        float carSpecificVariable;
    };
    
    // blahblahblah //
    
    class Scene
    {
        // ...
        Collection<Renderable*> renderables;
        // ...
    };
    
    void Scene::init()
    {
        for (each renderable object in the scene)
            renderables.add(the object);
    }
    
    // more blah //
    void Renderer::render(Scene *scene)
    {
        for (each renderable object in scene->renderables)
        {
            /* put the object in a render array and base
            ** the object's position in the array on the
            ** combination of material so little state
            ** changes will occur. Hopefully. */
        }
    }
    
    The above is something that comes off the top of my head, but i would start with something like that. From my perspective, this has the advantage that separates the renderable objects from the world entities (an entity can be something else, like an event trigger) and the rendering process and state change optimization is done where it should be done: in the renderer. IMHO this part has no place in game code or scene code (or even in a scene manager) because different rendering systems needs different kinds of optimizations and this shouldn't be merged with the rest of the engine.

    EDIT: ok, i just saw that voxel seems to say something like that :p.
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer