Various questions, hope they'll be easy to answer.

Started by
5 comments, last by Krohm 18 years, 4 months ago
I'm new to OpenGL, but am spending all my free time learning about it and how to use it. A couple friends and I want to make our own game, but we want to run it off our own engine. Several of us are proficient in C++, and we're going to use 3ds Max 8 for our modeling. First, is advanced knowlege of OpenGL and C++ enough to make a suitable engine for our game? Second, where should I start? Third, am I completely missing something very important that no one has yet informed me of?
Advertisement
1. Normally yes, but an engine needs big effort
2. Window creation, Renderer init, Texture loading and so on
3. Use shaders, that erally saves work. OOP is not a question its requirement

edit: I forgot to mention:

- search through gamedev.net forum
- google is your friend, believe me
-----"Master! Apprentice! Heartborne, 7th Seeker Warrior! Disciple! In me the Wishmaster..." Wishmaster - Nightwish
Quote:Original post by Hypoon
Third, am I completely missing something very important that no one has yet informed me of?

Yes, games are more than just graphics. [rolleyes]
Yes, games are more than just graphics, but graphics are all I have to worry about. I'm director of graphics, the others are directors of sound and story. The team consists of about 12 to 15 people.

Also, I use google a lot, but I don't like all the junk-results, as I call them.


[Edited by - Hypoon on December 17, 2005 2:35:41 PM]
Quote:Original post by Hypoon
First, is advanced knowlege of OpenGL and C++ enough to make a suitable engine for our game?


Your maths needs to be solid. You'll at the very least have a reasonable ability in algebra, and know the basics of vectors and matrix arithmetic - or at least the principles.

Quote:
Second, where should I start?


Do a small amount at once. Don't try for anything too fancy.

I'll assume that you've already completed a OpenGL base code doing simple things like drawing hard-coded shapes using immediate mode.

You'll need

- OpenGL setup code (I assume you already have this)
- Texture loader (Included in many libraries)
- Model loader (Included in some libraries) - loader / renderer go hand-in-hand, or you could take somebody else's and modify it to suit your needs.

Quote:Third, am I completely missing something very important that no one has yet informed me of?


Making a game is a lot more than just graphics. You'll need:

- Object management
- Input handling
- Physics handling - even if very simple (e.g. 2d) - includes collision detection, clipping etc.
- Timing - the game needs to go at an even speed regardless of renderer speed etc.
- More advanced graphics optimisations - such as culling and LoD - only needed once your game gets somewhat more complicated.

Plus loaders for whatever level file formats or other custom file formats you need to load.

You'll want to start off with:

- A vector class - pretty much essential, takes a lot of effort out of doing things
- A matrix class - if you plan on doing your own transformations - which is necessary for many types of game.
- A viewport setup routine - to set up your view port with a perspective projection (1).

There are lots of other decisions you'll need to take on the way, such as how to actually do the rendering - some objects might need more than one pass, you might need to do one pass for opaque objects and come back for translucent ones. You might need to do depth sorting for some of your rendering - depending on whether you use z buffering etc.

Mark

(1) Only if you're using a perspective projection of course - some games (f.e. isometric) use orthographic (i.e. axonometric)
1. sort of, but realtime 3d graphics need to be written in it's own little way, that takes time to learn, do most of the nehe tutorials to about 30-40 and you will have a pretty good idea how to do it.

2. the tutorials as i hinted above.

3a. Read the forum faq.

3b. Make a game design document, without it your game will die the "didn't know what to do next so we just added stuff until it sploded" death or the "We all had a slightly different vision" death.
In this document you should find everything about the game and more.
If you think it's even closely related to the game, and can be expressed with words or images it should be in there.
If not then put it in there anyway.
Quote:Original post by Red_falcon
1. Normally yes, but an engine needs big effort

I definetly agree with this. My experience tells me that you should be able to allocate "code runs" lasting at least half a day and at least 2/3 times per week (depending how good your memory is). If you do short code runs you'll end up coding a whole mess. If you don't have enough runs per week your engine will develop inconsistent evolution schemes.
In both cases, conceptual integrity will be lost and you'll have to scratch it.
Quote:Original post by Red_falcon
3. Use shaders, that erally saves work. OOP is not a question its requirement

This is also definetly true but remember that a strict OOP design is hard to design... actual GPU hardware sometimes does not fit in the paradigm (say you want to batch all the trees togheter or make a texture atlas).
Shaders are a MUST. They both save you a lot of time and allow much fancier effects, not to mention the extra hype added! ;)
Quote:Original post by Red_falcon
- google is your friend, believe me

I believe this forum is also pretty useful, as well as OpenGL.org (but its search engine is ugly, you're better with using google here).
I tell you this because I also hate the junk results. Asking things on forums will end up in saving a lot of time in most cases.
Quote:Original post by Hypoon
I'm director of graphics, the others are directors of sound and story. The team consists of about 12 to 15 people.

It seems that you have lot of manpower at your disposal.
Good luck with your technology, I believe you've good chance of succes!
Just a little note however: make sure to manage programmers correctly or the code will turn out to be a mess.

The first question you may face is:
Do I want to join the <FEATURE_X> bandwagon or to devolop something different?
You're warned: the latter could blow up development times by 100x pretty easily...

Also speak to people doing sound and/or scripting (a script is what you give to actors) because you'll have a glance on what features you'll need to support (example: volume metrics to support nice EAX, a scriptable texturing mechanism...).

Previously "Krohm"

This topic is closed to new replies.

Advertisement