OpenGL ES Startup

Question

I done a 1:1 copy of the iOS App "MohrenJass" to Android. -> Austria Cardgame.. Good training example :) Good introduction to Activity, Views, Canvas, Preference, APIs, and more Now i done the OpenGL ES Sample from the Developer page. I read about OpenGL but i have a Question about it. There are realy some points in it who give me some hard times. Matrix, vertex, shader, fragment, projection, camera,... Its not that i not understand it, but only to know "do this when that" is not enough for searching errors in code...

I think about trying the ReplicaIsland code next, but should i start with OpenGL first?

I found this fro OpenGL -> Prefer it because its german http://wiki.delphigl.com/index.php/Hauptseite (Dont know if its possible with my stand of knowledge)

Also found this http://www.learnopengles.com/android-lesson-one-getting-started/

Or skip this and go into ReplicaIsland? Learning by doing was always a good way, but sometimes its a punch in my face...

I wont to try next a simple 2D Application. A Square to go left/ right, jump above a other Square or somthing. Only for learning to reach someday my target of realy create a App :)

I also read something about Unity, but i think its not the way i should start that. Possible if i know what i am doing it will get with it easy... Well.. I hope you have any tipps for me!

Answer 1

As for libraries such as Unity or Cocos 2D and such you will be able to start with your application quicker but they usually limit your capabilities as a developer at one point or another. If this is for a purpose of creating a simple game then you should go for it. If the goal is to get as much knowledge as possible I suggest you try the openGL. It is not easy and it does not get easier over time but it is worth it. And if you later turn to some library everything will be as clear as day.

So about the tutorials and examples there is a fact that they are in most cases misleading. They will explain to you how something is done but the code structure will be completely unmaintainable. If you want a good code that will help you over time you should begin with creating a simple "debug" scene to which you can then add components you later expect to need. For instance you should create a class that can contain an openGL context which should later be extended to include caches such as textures, shaders... Then you should have a class containing the view you draw to, the frame buffer and the render buffers you use on it. It should contain all the necessary tools to initialize with view, enable depth buffers, stencil buffers, presenting the content... All of these and more can be more or less pasted from examples and tutorials, all you need to do is restructure them. This would be your base construct as you will be able to create all components to draw and present but can not draw with it. To test it all you can do is try to clear the buffer to some value and see if you get the expected result.

After this the fun part begins: Creating the classes to handle and compile shaders, classes to create textures from images, matrix stacks, VBOs... Again all of these can be pasted from web but need restructuring.

So when you have all this necessary tools you can actually start working on the game itself. At this point most people take the wrong turn. Try to create objects that contain all the data you need to present a certain element in your game. For instance you have a character which is defined with a location, speed and an image (texture). This object can then have a draw method and a move method. The draw method will use the location to translate the matrix, will generate or reuse some vertex data, bind the appropriate texture and simply draw itself. The move in this case will only use the speed to change the location. As you go deeper more components are usually added and the situation can get complicated. But imagine only having what I wrote above you can create 3 images: character, enemy, bullet; then create as many objects as you need at any time with this images, move them around as you please, create crash detecting (which is very simple with this data) and you have a simple game which can become very advanced very quickly only by adding a few tricks.