• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
lrh9

Multiple Renderer Implementations

4 posts in this topic

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
	}
}

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

0

Share this post


Link to post
Share on other sites

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

Edited by the mole
1

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

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!

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0