Projecting and designing a game

Anything and everything that's related to OGRE or the wider graphics field that doesn't fit into the other forums.
Post Reply
User avatar
celic
Gnome
Posts: 363
Joined: Wed Mar 23, 2005 11:05 am
Location: Chisinau/Moldova
Contact:

Projecting and designing a game

Post by celic »

Hi all,

I think about how to make a clear design for a game using OGRE, and don't really know how should it look. Maybe someone already have done this and could share some tips.
I want to make a simple car simulation, and the question is how should the project be organized as to not have the physics, collisions, rendering, etc.. mixed all together?

User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Post by Kencho »

It's exactly like designing an application. You have tons of reding out there about how to do that.

Unless you be more specific, I can't help you
Image

User avatar
spookyboo
Silver Sponsor
Silver Sponsor
Posts: 1141
Joined: Tue Jul 06, 2004 5:57 am
x 148
Contact:

Post by spookyboo »

I´m not that experienced with game projects in particular, but I do know how to organise an ICT project in general. If you are starting a project that involves several people and takes at least 2 years, the first thing you have to do is starting with some kind of workplan. It gives an outline of you project and describes topics such as:
- High level requirements (functional and technical): This defines the scope of your game. Is it an FPS?, an RPG?, number of levels, multiplayer and/or single player, multi-platform, directX only, etc.
- Project management: How many people do you need and what are their skills, what are the activities involved (so you don’t have 10 people picking their nose), number of increments, time schedule, etc.
- Tools to be used: editors, engine, 3rd party libraries, etc.
- Configuration management (sourceforge, berlios, ...)
- Quality control: Which coding standards, development guide, starters' guide for new projects members, code reviews, ...
- Testing: How is testing organised?
- Also consider a preparation phase (which includes making the workplan). During preparation you can make a website and do a proof of concept to get familiar with the tools and workflow.
After the preparation phase you make your initial design. Not technical, but functional, together with concept sketches and page layout/flow. Some topics:
Background story, overview of the game flow, User interface, Characters and models, World / Environment / Levels, Audio, Camera
This was how the game will look look. That leaves us to the technical design. Topics:
High Level Architecture (draw an overview of all components), describe how all components work and interact (in full detail). Each component has its specific area of attention, i.e. Animation, FX, audio, physics, HUD, AI, tunable parameters, scene management, persistency, physics, …
All above is mainly an exercise on paper and can take some time, but it will give you the right mindset (you know what you must do and how to do it). Don't make this a hasty exercise. It should cover at leat 80% of the project scope. The other 20% concerns open issues and details that are covered when you get there.

Also take a look at www.yake.org. They are working on a pluggable framework that includes rendering, physics, audio, etc. (they almost delivered version 0.2).

User avatar
celic
Gnome
Posts: 363
Joined: Wed Mar 23, 2005 11:05 am
Location: Chisinau/Moldova
Contact:

Post by celic »

thanks for the replies.

As I'll use OGRE for rendering, I don't want that the rendering layer will contain also the pysics and collision detection stuff, so I suppose there should be many threads, each of them responsible for all appart.

is this a good idea or not?

User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Post by Kencho »

I wouldn't spread everything in threads. For instance, you can use a thread for graphics and sound, another for physics and game logic, and another for AI. Anyways, I'm not a fan of threading (at least threading massively ;))
Image

User avatar
spookyboo
Silver Sponsor
Silver Sponsor
Posts: 1141
Joined: Tue Jul 06, 2004 5:57 am
x 148
Contact:

Post by spookyboo »

I don't understand the rationale of this. Making a clear separation between components doesn't mean that it must be implemented as threads. The hard part of creating components is to define the interface and how they interact. The have to be 'glued' to some kind of framework; there are various techniques how to do this (the 'Dependency Injection' pattern is a nice example of plugin registration). Yake has already given this a lot of thought, so you don't have to reinvent the wheel again.

Post Reply