First, hi to everyone and thanks for all the great advice. It is very much appreciated. I have recently started work on my first multi-screen game. I've done the pong/breakout/tetris clones, and I wanted to sink my teeth into something meaty and challenging(for my level of experience). I am working on a 2D tile based RPGish game. Basically, I want to create a short, 30-60 minute, polished game. This gives me an opportunity to focus my efforts on the engine, on learning how to do simple cinematics, simple AI, basic encounters and basic, but somewhat more challenging collision detection. It's a lot of fun and slow going because, of course, each step is a whole new suite of learning experiences. One of the things I am running into now is just the whole organization of the game. As I work on new aspects of the game I continue to run into design questions I have never before encountered. For instance, I want to add a cinematic. So I have a real generic sprite class that defines sprites and various features of them (size, position, type like character vs background, and so on), but as I add a cinematic I realize I'm not sure how to store all the aspects of a small animated scene. Should I create a new class just to deal with cinematics? How is this timed? What controls the resource communication from the renderer to whatever stores the game state to so on and so forth. I wonder, should I stop here and try and design an overall game organization chart knowing full well that it is doomed to failure, or should I continue to plod along knowing that this experience is just lessons I can apply on the next game where such a chart might be designable with this as background? My fear (if you can call it that) is that I will code myself into some corner and make the game unfinishable. Any thoughts, opinions, on or off topic are welcomed. Again, thank you and thank you for your time. -Ezekiel

What I understand as cinematic is either a cutscene or a full-motion video. What you're talking about sounds more like animation to me. How about a new AnimatedSprite class that is backed by an array of sprites and cycles between them based on whatever you want (time, proximity to player, some other condition?)

Communication - if you want to decouple the scene and renderer, you will need some other object somewhere which knows about both and transfers the relevant data from one to the other.

Since you have no clue at this point how everything fits together, I think it's time for some top-down design, but ultimately there are some things / challenges that you will only realize the existence of once you start coding (or at least, that has been my experience so far). IMO, creating a game you have no idea about is a somewhat iterative process, with a bit of coding followed by a bit more design etc. I doubt that there is such a thing as coding yourself into a corner from which refactoring can't help you escape, but upfront planning is always prudent.

Edit: Ok, I probably misunderstood about cinematics. If you mean cutscenes, go with Lazerbeard's approach, but I think you'll want some kind of translation layer between the script and the rest of the game. You want to be able to write in your script: MoveTo(actor1, waypoint5) and have the engine translate that into a set of commands in the action queue of your actor. So you'll want to define a set of functions for handling cutscenes and expose these to your scripting environment. At the lower level, it should be similar to how your AI does things: translate a high-level conceptual order (attack player) into a low-level move/action list (move north, move east, fire weapon).

I think there's no need to link scripting to graphics directly - just think of it conceptually as another kind of input that affects the world state (just like regular input and AI input). You'll also most likely want to turn off regular input and user interface when doing cutscenes.

[Edited by - lightbringer on May 3, 2009 2:50:26 PM]

So, first, its perfectly OK if you just pick a direction, try it, and if that doesn't work, you learn from it. The more difficult a project you attempt, the more chance of failure you have, but the more you learn. Coding yourself into a corner is possible, and happens often to learning developers, just dust yourself off and try something different.

For my two cents, try to create an engine housing completely separate components (little to no direct ties from engine to engine), then create game logic and objects from these components.
Some popular components include:
Input
AI
Graphics
Physics
Sound
Messaging system

These are separate projects, and at least in our project, we can run these components separately from another, game objects are composed by aggregating relevant component parts into a type. Each component will have its own update, and your game objects have their own update, but now all the relevant data is held in an outside specialized controller, game logic is created by asking certain components the result of their own update, doing your own logic, and then passing that info to other components.

For instance when you are walking around town you might need to gather input from the input class, then determine a position(or velocity, whatever data physics wants) to move in. Then during the update phase you would update physics on all objects, then in each object, pass the final position/rotation to the graphics component, who would display this on the screen.

For cinematics, you might just create objects from graphics components and a scripting component. There, the scripting component directly tells the graphics component where to place objects in the scene, and the graphics component would draw them there.

This approach is nice, because you can separately test each component to ensure it is working properly, and because you can mix and match components to create new objects. For an RPG, especially one with menus and such, I would heavily recommend you look into a scripting language, like LUA, or even just do something like XML to manage your items and such. This will make tweaking stats like "how much armor here" or "how much damage here" much easier to tweak, since you don't have to recompile the game, and your items will be well organized.