Well.. yep. You are maybe right.
The basic concepts about 3D rendering are interesting and very useful to know. Sometimes lots of abstraction could bloat the code and even make it more complicated than it is. Many engine developers invent their own concepts and force the users to learn and use them, but very often behind those concepts lie simple and elegant things. The more flexible way for doing stuff is to learn how they work on the low level. For example invest time to learn how per pixel lighting is calculated in a shader. It's some basic vector math, it's not rocket science after all.
This time will be the more well invested than to learn how to setup a bunch of parameters in a third party engine. At the end of the day you probably will not have a nice screenshot to show, but you you will know how lighting works, you will be free to go further independently.
Wow, kind of the opposite of what I expected. I read a few posts, i think even an article, on not writing your own engine. I thought using openGL or directX would be a target too high for a lone developer. I'll be done my degree in 2 years and in that time frame I'd like to get the bulk of the game done. I also figured using a low level api would consume all that time just trying to get rendering, collisions, sfx up and running. Ill definitly check into those assumptions now though, thank you guys.
. I thought using openGL or directX would be a target too high for a lone developer
[/Quote]
I owuld think so too. I think there is some disagreement here because your goal's seem to conflict, depending on how one interprets them.
So first, it sounds like you want to get into graphics programming, and have some achievement in that area so that you can show that off, and second you want to make a game.
A fully made game engine like Unity and Shiva is good for making a game because all of the graphics programming is essentially finished. You can make game much more quickly because you can focus on just the game logic, but you won't be able to take any credit for the graphics except maybe the art assets. Unity does allow you to write your own shaders, though.
If you want to actually do graphics programming, you need to start with the very rudimentary graphics APIs such as Direct 3D/ OpenGL because that is the only way to really control what really goes on during the rendering and craft your own methods. It will also give you insight into how computer graphics rendering generally works. This will be very time-consuming and will make it more difficult to make your own game.
So you kind-off have to weigh which is more important.
It's a complicated question. Graphics and game engines do a lot of things that people tend to take for granted, and even if you decide to get a bit lower level, they can take a lot of the pain away by doing some of the tedious things for you. Why re-invent the wheel?
Think about getting models and images into your game. Are you going to enjoy messing around with input streams and memory to write your own loaders for whatever file types you use, or would you rather just tell an engine to load a model and hey.. you have your image and vertex data sitting waiting to be used?
On the flipside, while engines can be useful, I always felt that those engines weren't doing things the way I liked. Their interpretation of an entity for example, was quite different from what I had in mind. Or what I'm not writing a game that uses traditional structures or rendering techniques...?
However the good thing thing is that just because you use some features of an engine doesn't mean you need to use all of them. Maybe like me you will find the place to be is using the best of both worlds?
As someone who spent a long time learning OpenGL first and then diving into both Irrlicht and Ogre, I found that the more I used them, the more I decided to implement many of their functions myself. For example, Irrlicht has a fairly good particle engine which is easy to use. However, it didn't do what I want, so I wrote my own in a couple of days. Not only does it do exactly what I want, it interfaces with my game better AND it turned out to be faster. That generally happens when you tailor things to a specific use rather than a one size fits all approach.
However, if I had to sit and write my own jpeg or png decoder and sit and work out the intricacies of the 3ds file format, I wouldn't have had the time to do this. So I still like to have an engine to take some grunt work away.
Currently I use Irrlicht as a big utility library, with some useful bits and pieces here and there. Everything else I do myself.
The best part was I could get stuff up and running quickly.. only when it didn't fit my exact needs did I have to do the hard work.
Definitely go with the open-source options (Irrlicht, Ogre, SDL, SFML).
If you're writing a 2D game, SDL and SFML are excellent and light-weight options.
If you're writing a 3D game, I don't have a ton of input... but from what I've seen of their respective documentations, Irrlicht is a little closer to SDL and SFML in API, which is a plus in my book (but maybe not in others').
