Hey everyone! I'm working on implementing a 3D game in Java using LWJGL and the Artemis Entity System Framework. I've done the tutorials on the LWJGL site, and they have examples for older OpenGL (the term I use for OpenGL < 3.2) and modern OpenGL (the term I use for OpenGL >= 3.2). Even though the majority of my player base will be able to play games made with modern OpenGL, I'm wondering if I should support older OpenGL too. However, that's not my primary question.

Even if I decide not to implement a renderer for older OpenGL the possibility has raised what I consider to be an interesting design question. How would I implement a rendering system supporting multiple renderer implementations? My initial thoughts on the subject lead me to believe that by using well designed interfaces I can abstract the rendering process to a set of steps. Then it would be a simple matter of having different implementations of that interface for the renderer variants.

I'm implementing rendering within the confines of the Artemis Entity System Framework, and that basically involves systems processing a collection of entities using their components. So far I think that the minimum components needed to render a renderable entity are its position, scale, orientation, vertex data, textures, and shaders. This is kind of what a not yet implemented rendering system would like.

import com.artemis.Aspect;
import com.artemis.Component;
import com.artemis.ComponentMapper;
import com.artemis.Entity;
import com.artemis.annotations.Mapper;
import com.artemis.systems.EntityProcessingSystem;

public class NotImplementedRenderingSystem extends EntityProcessingSystem
{
	@Mapper ComponentMapper<Component> cm;
	
	public NotImplementedRenderingSystem()
	{
		super(Aspect.getAspectForAll(Component.type));
	}
	
	@Override
	protected void process(Entity e)
	{
		/*
		 * render using entity components:
		 * position
		 * scale
		 * orientation
		 * vertex data
		 * textures & shaders
		 * e.g.:
		 */
		
		Component component = cm.get(e);
		//do something with component
	}
}

I've heard that the best way for an indie game programmer to make games is to get a minimal working framework as soon as possible and expand from that, and I'd really like to be able to get into a rendered world (even if it is just basic geometric primitives with vertex color) as quickly as possible. Thanks for reading!

Hey Irh9,

that is an interesting question.

And yeah, usually abstraction is a good idea - no matter what you want to implement.

But with abstraction your code base increases code complexity and sometimes you also "abstract" it wrong.

Therefore from my point of view - and not everyone will agree on that - I prefer not abstract too much in the first implementation.

I also strongly do not recommend abstract too much when you are not familiar with the frameworks you are using.

Usually they already abstract stuff for you.

If I were you, I would implement one renderer for either modern or older OpenGL.

And if you have at any time in the future the need for a renderer for the other OpenGL you could simply implement it then.

This of course only works when you go with the usual design and programming concepts one should consider while programming modern software.

But it usually is bad to "overdesign" a system from the beginning, only because at some point in the near/far future you might need a feature which would then be easier to implement.

From my experience, this never works.

I've heard that the best way for an indie game programmer to make games is to get a minimal working framework as soon as possible and expand from that, and I'd really like to be able to get into a rendered world (even if it is just basic geometric primitives with vertex color) as quickly as possible. Thanks for reading!

That is always works best and is usually the way you will work when you are alone.

Every time you "expand" from "it" you "iterate" over your work results.

Therefore you can rely on what you have learned in the last iteration and make new decisions about what you want to do in the next iteration.

When you try to build a game a framework is usually a good idea. But that depends on what you want to do.

Framework is not well defined and can mean different things. I would also focus on your use cases (e.g. have a figure collecting coins and get points for it).

A framework sounds overdesign for me at this point.

Other people I've spoken to on IRC have shot this idea down. I'm not really sure how I would name each implementation, but I suggested Renderer20 (OpenGL 2.0), Renderer32 (OpenGL 3.2), etc. and that was panned as a horrible idea. The same people suggested abstraction, but they didn't say where I should put my implementations or what I should call them. Any advice, ideas, questions, guidance?

I'm not sure if I understand correctly, but that does not sound wrong. I can only recommend to read this: http://en.wikipedia.org/wiki/Composition_over_inheritance

If one is not very experienced in programming, inheritance is used, where composition would be a better solution.

I do not know much about the Artemis Entity System Framework, but it looks to me, that you need some kind of abstraction to implement multiple renderers (as already mentioned by the IRC users and that is what they might mean).

The abstraction has to work as a "proxy" or "manager" for the different "component types". Lets call it ComponentManager, which is an interface.

Then you can implement a OpenGLModernComponentManager and a OpenGLOldComponentManager. Your artemis Entity System Framework renderer then use the appropriate ComponentManager (either modern or older OpenGL). The ComponentManager then have to provide methods for the different component types. That depends on what you want to do. The ComponentManager could also work as a "collection" of "component handlers".

In general I always prefer implementing the core features before considering abstraction.

When the features increase, the need for abstraction comes automatically.

When you are a little bit experienced in coding, you get a feeling about when a good time for abstraction is.

I am sorry to give you a very vague answer to your question, but hopefully it helps and will not confuse you ;)

- the mole

I'd recommend not wasting time worrying about how to implement multiple rendering options, and just work on the game. If you think working with 3.2 will keep you more excited, use 3.2. For a small project, the work required to add after the fact is probably less than maintaining, testing, etc. from day 1 anyways.

As for abstraction, be realistic. Abstraction hides complexity. Why are you trying to hide complexity? Is abstracting something going to prevent you from having to write the code? Abstraction makes perfect sense in a large project where the majority of developers have no reason to understand the details, but it makes a lot less sense on a small project. You're not gaining the benefit of letting some people ignore the implementation details, but you're paying the full costs in complexity of design and difficulty of debugging.

Thanks Mole and Richard for the quick replies! Mole gave me an idea to look at some design patterns to see if any were applicable, and from the wiki it seems like the bridge pattern may be appropriate to use for this purpose. It even has an example in Java. Thanks again and keep up the great replies!

I'd recommend not wasting time worrying about how to implement multiple rendering options, and just work on the game. If you think working with 3.2 will keep you more excited, use 3.2. For a small project, the work required to add after the fact is probably less than maintaining, testing, etc. from day 1 anyways.

As for abstraction, be realistic. Abstraction hides complexity. Why are you trying to hide complexity? Is abstracting something going to prevent you from having to write the code? Abstraction makes perfect sense in a large project where the majority of developers have no reason to understand the details, but it makes a lot less sense on a small project. You're not gaining the benefit of letting some people ignore the implementation details, but you're paying the full costs in complexity of design and difficulty of debugging.

I agree with this, but I would add to it. Abstraction is also a useful method of avoiding edge cases which can go unnoticed. The idea of interfaces helps prevent these sorts of problems.