Jump to content
  • Advertisement
Sign in to follow this  
Elenesski

Graphics Adapter Strategies

This topic is 4070 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

A good 12 months ago I starting thinking about writing a game. At that time, I wrote a back story to the premise and started down the grand game writing path trying to do elaboration on the graphics aspects where I've been preliminarily stuck. These days I have a different angle on the story (same concept) which would enable a broader playing style. I have little experience with graphics implementations, so rather than spinning my wheels in the sand, I've decided that I'll work on the game mechanics; make that fun to play, then work on the graphics in a much later stage with a game developer/publisher (assuming I get that far). I have expert level object-oriented design, development with patterns and system level enterprise component architecture experience; temper your responses with that in mind. My question is if I do not pick a graphics engine to start with and work only on the mechanics and assuming that my design is competent and high quality, would a potential game developer be more apt to writing adapters to their graphics engine to hook up my game, or should I assume the game (if bought) it will be rewritten in order to support a graphics model because they are so heavily intertwined? Or are their architectural strategies I should consider in order to facilitate the development of the various adapters? I'm assuming that game design/development is really no different than enterprise application design/development in the sense that the user interface is just a "shell" on top of a domain (aka the game engine).

Share this post


Link to post
Share on other sites
Advertisement
I believe you oversimplify the process a bit. I would just check out a good book on engine design. Dave Eberly has a few good books out there. They give you the math for many aspects of game development and an idea on how to implement it in a engine.
Depending on the target platform a team that works on a game project can be over 300 - 400 people (e.g Medal of Honor, Ghost Recon, GTA). Most of those guys focus on a certain aspect of the game creation process. Naturally there are also games and target platforms that only require much less people. So I would recommend you choose your target platform and game design well.

Share this post


Link to post
Share on other sites
I believe you oversimplify the process a bit. I would just check out a good book on engine design. Dave Eberly has a few good books out there. They give you the math for many aspects of game development and an idea on how to implement it in a engine.
Depending on the target platform a team that works on a game project can be over 300 - 400 people (e.g Medal of Honor, Ghost Recon, GTA). Most of those guys focus on a certain aspect of the game creation process. Naturally there are also games and target platforms that only require much less people. So I would recommend you choose your target platform and game design well.

Share this post


Link to post
Share on other sites
Ideally, the game should indeed be separated from its renderer, essentially becoming a sort of massive MVC pattern. Obviously, to get the game done, you're going to need one or more rendering solution on the back end. Having the flexibility to support multiple rendering solutions can only be a good thing.

One thing to consider is that there are various levels of abstraction going on. There are layers such as Direct3D and OpenGL and console-based APIs, then there are higher-level rendering technologies based on scene-graphs and the like.

The adapter pattern is possibly too innefficiant, and a Facade pattern might be better.


That said, Its probably best to simply choose your intended platform(s) and just get on with it. Presumably you're targetting the PC, where Windows is the primary target. Its unlikely that your game will ever see itself on a console, but I guess its as good a reason as any to choose between what API you will target. Windows PCs and Xbox use DirectX/DirectX-like APIs, while Windows/FOSS PCs, Wii/Gamecube and PS3 use primarilty, or have available, OpenGL/OpenGL-like APIs. Of course, console development is a largely different world compared to PC development, and the rendering back-end is only going to be one of many issues if it were to ever be ported. Console dev is an entirely different mindset, particularly with the PS3 and Xbox360.

Share this post


Link to post
Share on other sites
It's generally a good strategy to have a clear separation between 'simulation' and 'rendering' aspects of a game - I put those terms in quotes because they're not universally accepted terminology, most commercial games these days will have some reasonably well defined separation along those lines though.

That said, depending on what level of visual quality you're aiming for you will find that there may be quite a lot of interaction between the simulation and the rendering code. Without thinking in advance about what information is going to need to be passed from the simulation to the renderer to achieve the visual quality you're aiming for you will probably find you will have a fair amount of rework on the simulation side when it comes to implementing the visual side.

For a simple 2D type game the communication between the simulation and the rendering might be little more than the position and animation frame of each entity together with information on what part of the world to display. For a complex 3D game a lot more information needs to be communicated, including position, orientation, animation state (potentially quite complex) and any game specific variables that need to affect the visuals. If the simulation includes physics then the physics system will also need to pass information to the renderer, possibly combined in some way with animation state. The renderer will have to keep track of large quantities of assets (textures, meshes, animations, vertex and pixel shaders, etc.) and you will need code that understands how to associate all the visual assets that make up a visual entity with the simulation driven entity it corresponds to.

It makes for a nice clean setup if you can make communication between the simulation and the renderer one way (the simulation pushes data to the renderer but never gets information back). Various factors complicate this simple vision though and require some extra work to achieve without feedback.

The animation system is one example of this - if you want smooth transitions with animations then the AI and simulation logic that drives animation states may need to know information about how long a given animation clip lasts and about what transitions are valid at what point in the animation. If you treat animation clip data as a purely visual asset then your clean one way communication becomes a problem. Pathfinding may need information about the bounding volume of the current entity (also affected by animation state) as another example.

Similarly some aspects of UI code present conflicts between efficiency of implementation and clean conceptual divides between simulation and rendering. Selecting units with the mouse for example needs access to data about the positions of the vertices in the model in the current animation state. Placing buildings in an RTS game needs access to information about the terrain and the size and shape of the building models and other nearby objects that may obstruct them. There are numerous other examples that require extra work to maintain a clean separation and one way communication between simulation and rendering.

The upshot of all this is that while it makes sense to keep a fairly clear separation between simulation and rendering, don't expect to be able to ignore the visual aspects of the game until after the simulation is finished unless you are aiming for very simple visuals. Depending on the type of game you are aiming to make and the complexity you are aiming for in terms of visuals you will have anything from minimal to very significant problems adding the visuals in later without significant changes to the simulation code.

Share this post


Link to post
Share on other sites
Thanks, this is exactly the kind of feedback I was looking for.

I can develop the model first.

Cheers,
- El

[Edited by - Elenesski on June 26, 2007 1:22:45 AM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!