1. I would suggest that you start coding in whatever language is convient for you. C#, VB, CPP, Python, whatever. Keep your projects very small in scope with clearly defined goals. Also grab a lightweight 3d modeller (I suggest deled) and experiment. Explore and figure out what you enjoy and what you are good at. You'll need to know both skillsets in some capacity as a designer anyway.
2. You'll need the degree (piece of paper) to get a paying job. I would worry about that later though. I would focus on teaching yourself the skills first given your resources.
As to the 'why'...this is more a learning project than a practical one. I wrote some python code to parse three md3 files that form a complete player model, take a frame from each, transform them using a matrix derived from tag data in the md3 files and then output the whole thing to one obj file (player_out.obj). The reason for obj is simply to make sure I got everything right before writing my own rendering code.
To add to what they said...suggest you research and try blitz3d. I think it went free not long ago. Smooth learning curve and quick tangible results. Great if you have a narrow attention span. Just does not scale very well but you probably don't care about that now.
Cheating isn't a good word for it...more like standing on the shoulders of giants. Really though it comes down to your goals...are you more motivated to work at a higher level or a lower level? Are you satisfied by using an existing engine to get a game out and done or do you want to spend a lot of time and energy understanding (and fine tuning) how the pieces of game engines work. You can make games or you can support people who make games.
If after reading everything above you still want to keep people from tampering with your files I would suggest...
1. If you are using xml, use an xsd to validate it on reading that file.
2. Avoid using plain text files...convert them to binary. Not everyone knows how to use or what a hex editor is.
3. Hide data in plain sight. For example in the header of a Jpeg or even in a lossless PNG. A lot of people will miss that.
Someone who is smart or determined will get past the above but that is usually not the case.
I think the quake 3 engine computes a hash for their asset files and compares them to a value in the code as an integrity check. Not sure of mechanics of exactly how that works...idea seems sound though. You could make a hash of each file...if it does not match a previous value when reloaded then it is dirty.
I'm making the assumption that you are totally new to shaders and low level 3d...don't mean to be condescending, I'm still learning a lot myself. This is where I would start though if I could do it all over again...
Start with little...seemingly insignificant details. Rendering a point, a triangle, two triangles together (a quad), a cube, a sphere, then finally an arbitrary mesh from a parsed Wavefront OBJ. As you move to each new more complex piece of geometry focus on mastering it...for example, walk through these steps (not in any particular order) with a cube...
1. Can you put a different color on each face of the cube?
2. Can you map a texture to the cube?
3. Can you map/blend two textures onto the cube?
4. Can you rotate, translate, scale the cube and rotate it around both its axis' and another point in space?
5. Can you render the cube with either an orthographic or perspective projection? Can you switch back and forth on the fly?
6. Can you pick (or select) an individual face on the cube and turn that particular face to a black and white texture as opposed to a colored?
7. Can you put the same color on each face and still have them be distinguishable (as opposed to a blob) by using vertex normals and a directional or point light?
8. Can you switch between per vertex lighting and per fragment lighting?
9. Can you draw two, five, or twenty cubes with the same geometry but with different sets of shaders (swapping them in a single draw)?
Experiment. Above all, I would concentrate on writing your own shaders as you go...steal and loot other people's ideas once you understand them, but don't do an outright copy.
Even if you are doing indie games you will probably be on a (small) team. In a professional capacity you will be on the same team with artists developing a game...even if all you are doing is coding it always helps if you can better understand your co-workers jobs and needs. And obviously at some point you'll need to be able to get the art assets that 3d modellers make into the game itself...you'll have to code/support the tool chain that handles that. Making 3d models yourself and getting them into a working game engine is a good way to better understand that process. If nothing else you can make a few models and then write code to parse the files into vertex (position, normal, texture coords for example) and index buffers for OpenGL.
OpenGL ES2 has a reduced feature set targeted at lower end hardware. It it designed to run in a browser which means you have to pander to people with crappy hardware and all resources have to be loaded asynchronously (ex. textures, 3d models, shader files). It is not designed to compete with full OpenGL on performance or quality. However...it works on most peoples machines...portability is it's strength. Does that clear anything up for you?
I would recommend Blitz3d...like some of the others did. It's simple...it comes with it's own IDE and uses a bastardized form of BASIC. Has quick return on investment so I suppose it would be a good choice for those with short attention spans (kids). There is a good layer of abstraction between the underlying graphics API (old DirectX) and the language...so at the expense of flexibility you can still achieve some really cool effects and not have to dive into a shader language (HLSL in that case) or linear algebra. After a few simple games he'll realize that Blitz3d does not scale very well at all to more complex projects...and you can get him started on something more powerful like XNA4.
This all helped a great deal, i believe i will start learning c# and python
thank you guys for the help
on the languages note, are there any recommended books to pick up for c#/python?
For a grounding in C# the Deitel series is not bad. Although it may be like drinking water out of fire hose for a beginner. I would look at some online tutorials first. Once you know what you are looking for then maybe spend $50 on a book.
If you do choose c# as a first language and master some of the basics (and still want to pursue gamedev) I would recommend Learning XNA 4.0 by Aaron Reed (O'Rielly Series). Once you get further into the book it slowly introduces some basic concepts of object oriented programming and gives you practical reasons to use them with XNA...as opposed to just handing you raw theory. That said...the book's coverage of HLSL (and 3d as it applies to XNA) is a bit shallow, so you should not expect to be an expert on XNA or anything, but it will give a starting point.
The only thing that even comes close to "no programming" is Unity 3d. Per the website $1900(unity pro+android basic) or $3000(unity pro+android pro) is available. You'll still be scripting at a bare minimum...and if you don't want to program I doubt you'll get anywhere with scripting. Why are you here then?
Also, android game development isn't the best place to start. You don't even really have control over the life of the program...you just react. For example, if the user tilts the screen you have to drop everything you are doing, save the state before the OS kills your program, then you have to reload everything from state once it starts back up again.
Take some time and install VS2010 Express for c# and c++...all the tools that you need at this point are free. Make your goal drawing a single triangle in a window. First complete the task in c#, then in C++. Leverage the XNA (c#) and DirectX (c++) APIs/toolkits to do the drawing. Tutorials for this sort of thing are spammed all over the place. Just do some research with Google.
Get that far and you be able to ask much more specific, intelligent questions on which language and api/toolkit to learn more about.