However, in my game, when the player survives for a certain amount of time, I want to introduce more elements into the game, so I might then have a ‘level2′ Scene (although strictly, from the player’s perspective, the game is perceived to be one big rolling level)…..

So, as you can see, Level2 is exactly the same as Leve1 but now I’m also drawing my ‘pink-enemies’, I can keep doing this for ‘levels’ 3 through 10 but I’ll end up duplicating and simply adding to each level each time. Seems like a lot of effort just to introduce 1 or 2 new things every ‘level’.

Using conditions within my render / logic?

Is there a cleaner / tidier way of achieving that which I’m trying to achieve? I could do away with all my individual ‘Level’ classes altogether and just work straight out my MainGame class’s Render() and Update() methods, but then I would have to have something like:

And then a similar switch in my logic. I’m not sure about this however, as it adds additional switch/conditional statements in my rendering and seems somewhat ‘amateur’ however, I could be completely wrong and this may be an acceptable method that people do use.

Am I missing any other obvious cleaner / cleverer way to do this (similar to my first method but without the duplicated super method calls)

Before addressing the specifics of your question, I do want to point out that I disagree with your approach to your inheritance model.

A Game generally does not implement a Scene but instead a Game consists of one or more active Scenes that are being rendered and updated in a main loop. It’s important to think about whether a class relationship can be described as has-a versus is-a. In the former, it implies composition and therefore a property/variable of the class. In the latter, it implies inheritance.

Therefore as I said, a game has a list of active scenes so the code might look like:

What’s important here is that you have a solid basis for core game logic that is independent of what your scene logic may be. This class could hold a list of active rendered game objects, it might hold a reference to your camera, graphics context, etc.

If you build off what ratchet said, your Scene essentially has a list of GameObject instances that represent your various enemies and get instantiated when the scene is loaded. As a scene gets updated, any enemy logic can be updated and during draw you actually render each one. During the unload, you free any resources for each GameObject associated with the level.

Not only does this give you good separation of concerns and responsibility, but it also opens the door for having multiple active scenes that are contributing to the same rendered view; such as when you pause the game and render the main menu or as you want to introduce a complex scenario into a level randomly :p.

If you now use the term State rather than the term Scene; you’ll notice this is precisely the State design pattern and is often implemented in most game engines in some variant providing precisely this kinda functionality.