Posts Tagged OO

Renderização e OO – Código

26.11.2007 às 17:48 · Arquivado em Planejamento ·Tagged , , ,

Como prometi, o código que ilustra a parte de renderização. Python não implementa interfaces explícitas, como em Java, então fiz uma ligeira gambiarra com uma classe abstrata. E sim, eu programo em inglês. Me processem :P 

# Object renderer abstract class
class Renderer:
    # Default constructor
    #
    # Raises an exception because this class can't
    # be instantiated. It's used as a base class
    # for other renderer classes
    def __init__(self):
        raise "Can't instantiate this abstract class"

    # Renders an object
    #
    # Renders the object based on its class. It uses
    # an ugly chain of "if else isinstance", because
    # Python can't do method overloading (at least
    # not out of the box). Thanks, guys.
    def render(self, object):
        if isinstance(object, Map):
            self.__renderMap__(object)

# Renderer that uses pygame's routines
class PygameRenderer(Renderer):
    # Default constructor
    #
    # Overrides the base class' constructor
    # to prevent an instantiation exception
    def __init__(self):
        pass

    # Renders a map object
    def __renderMap__(self, map):
        print "Rendering map using PyGame!"

# Renderer that uses OpenGL routines
class OpenGLRenderer(Renderer):
    # Default constructor
    #
    # Overrides the base class' constructor
    # to prevent an instantiation exception
    def __init__(self):
        pass

    # Renders a map object
    def __renderMap__(self, map):
        print "Rendering map using OpenGL!"

Comentários (1)

Renderização e OO

24.11.2007 às 22:16 · Arquivado em Design, Planejamento ·Tagged , , ,

Independente da definição dos mapas, uma coisa importante é definir a forma com a qual eles serão renderizados, assim como para todos os outros objetos de jogo (jogador, inimigos, etc). Uma abordagem ingênua seria acrescentar um método “renderiza” para cada classe, assim cada classe teria conhecimento de como suas representações devem ser mostradas.

Seria algo como:

class Mapa    /* uma porção de métodos relacionados ao mapa */

    renderizaMapa( ... )

A idéia parece legal, mas começa a vazar quando se considera a possibilidade de múltiplos renderizadores. Digamos que além de um renderizador padrão feito com as rotinas do pygame, eu quisesse adicionar um novo renderizador baseado em OpenGL. Fácil! É só adicionar um novo método, “renderizaOpenGL”!

class Mapa

    /* uma porção de métodos relacionados ao mapa */


    renderizaMapaPython( ... )


    renderizaMapaGL( ... )

Mas e se eu quiser adicionar uma outra forma de renderização, por DirectX? Adicionaria um novo método para cada tipo de objeto? Obviamente esta abordagem não é a ideal.Uma solução, que é a que vou seguir, será criar um renderizador de cada tipo, que recebe os objetos que serão renderizados. Assim, para mudar o renderizador para um que usa OpenGL, DirectX ou sinais de fumaça, basta implementar o novo renderizador e substituí-lo, sem modificar o código dos objetos de jogo.

Exemplo para o mapa:

class Mapa

    /* métodos do mapa */ 

interface Renderizador 

    renderizaMapa( Mapa mapa, ... )

class RenderizadorPython implements Renderizador

class RenderizadorOpenGL implements Renderizador

class RenderizadorDirectX implements Renderizador

Em breve mostro o código Python que ilustra essa idéia. Primeiro preciso estudar como (se) Python trata tipos abstratos de dados :)

Deixe um comentário