When you have a team of seperate artists/programmers it is important that one understands the limits of other. Let me tell you my current problem from a programmers viewpoint.
We are making a isometric game (Graphics is 2d it just uses tricks). I create the placeholder art for the actual game world and our artist started on item art that will be in the inventory. Our inventory system is very similar to the dungeon siege games and the like so items can be different sizes. He can create great art. But he creates it BIG. I mean high resolution artistic goodness. Or he does it in 3d and takes screenshots. The problem is that it will have to be resized for the game. A lot of quality is lost. And i mean a lot more that if he just started doing it the size it was supposed to be. For 2d games more so for tiled/isometric games at least some some form of pixel art must be used if not all. Most artists are not pixel artists. They don't get it that a 54x54 tile is not so hard to make pixel by pixel. Hell i even made some. They feel it looks bad or just have a hard time looking at it as making art. When in fact no matter how good they make their big art it almost always looks worse when resized. And they blame the programmer for that, and the programmer blames the artist and so on so forth. It is important for a game artist to know how games work with art. They should know what the limitations are from the beginning and not try to make art AND then worry about that.
Work close to the programmer. Listen what he says. He will not judge your art but rather your skill to make it useful in a game. And limitations will be set by your game. Work within it's confines! Or you will be set for failure.
For 3d texture/model art this is a bit different story and i have no experience with it.
You know what i agree. I never started big either. I tried learning C++ and fell to just C. Then mastered it and suddenly C++ and Java was a breeze. Yes the standard library is really really bad. If anything you cant really make games with it. I tend to avoid it completely. I only use C library for File input/output and that's it.
But i do not understand why would you bash C. Yes it is outdated. Yes it is not really object oriented (C++ also isn't really). But it is very easy, very well supported,very useful and it makes learning C++,C#,Java much much easier later. Where almost everything that you learned will be used with almost the exact same synthax in these languages.
Functions become methods,Structures become Classes,Bit operators remain,...
The only problem i see is that some people get too much into C and start programming Java as they would C. They will make bad OO decisions and so forth. But most people that i know are very flexible and is easy to them to change the design of their code and approach to problems.
First off, learning C is not a great starter language, and learning C to learn C++ is like learning Dutch to learn German. Sure, it may help your understanding, but what a terrible waste of time and resources. C is a very domain specific language these days and for most people is of little relevance. For new C++ programmers, they should be encouraged to stay the hell away from C and instead learn idiomatic C++.
Second, C++ is a horrible first language, period. Don't believe me, read this scenario and be completely honest with yourself, "could you have found the problem?". That's because C++ is rife with this kind of crap and you will be dealing with it from day 1! People say it's stuff like memory management that make C++ difficult, but it's not, not really... it's stuff like this. The horrible linker, the lets support every single bloody edge case even if nobody is ever going to use them mindset, the piss poor standard libraries, the fact its actually 4 languages smashed together, the weight of a thousand legacy mistakes. All of those negatives may eventually be a positive ( except the linker, which just sucks ), but to someone starting out they all work together to make C++ a terrible terrible starting language.
I told him not to bother with a graphics library until he learns the language. And for that almost all IDE's that are out there thay are all set for the go to do such stuff. No linking problems, no library incompatibilities, no stupid stuff like that. By the time he learns the language. He should be reasnoably competent to understand what a library is ,what is a dll, what do the warnings mean. And most importantly he should know HOW to ask the right questions on the internet to solve his problems. There is nothing wrong with that. A person that doesn't know this basic stuff SHOULD not dive in to use third party libraries or yes i do agree hes in a world of pain. So yes C++ CAN be a begginers language. But C++ with a third party library is definetly not.
Well all open source games put their entire code on the internet. So you can start there. Also while it is good to learn from web tutorials (there are a lot of good ones) there is nothing like a good book that you can put on your desk and read from while you learn. You can chose from basic C++ stuff books, to game design , graphics library books, game physics books,... Start small. Really small. Like a simple text console question game. Then move to 2d static graphics simple games,then 2d animated games,...3D can be hard really hard.
For C++ there are some nice libraries for games:
SDL - Simple elegant easy to learn has some books on it, a lot of tutorials , a lot of games use it,..
SFML - Simple well designed powerful easy to learn.
GLUT/OpenGL - Ranging from very simple to extremely comlex. Good start to 3d programming. Easier than DirectX and very cross platform. (Very good books/tutorials)
DirectX - Only for Xbox and windows. Great game library in general. Has all you need for sound,3d graphics,networking,... (Very good books/tutorials)
As for engines i can't really say. Since i usually only use libraries (write simple engines from scratch).
You have a major problem with this. No matter what you do the file system will work against you. No matter how small you make this already small files they will be at least 2/4 KB on the disk. The only way to make something happen is if you have a whole bunch of them and store them in a single compressed file only than does this seem reasonable.
Also i may help with that one byte audio file.
It is only one second long. and as you know a byte can store 256 different values.
Human hearing is in the 20-20000 Hz range.
Simple math would be that you can store 256 different frequencies in the single byte.
But what would they be. For example (20000-20)/256 ~78HZ. So you can make something like this.
A value 3 would be a 254Hz sine sound.
a value 60 would be 4700 Hz sound and so on so fort.
To calculate it would be something like [value*78 + 20] so it is betwen 20 and 20000. I hope i helped.