When a person asks for more documentation, especially when there is a decent amount of it (including demos), they actually mean to ask one thing:
“Where is the step by step guide to help me write MY game?”
The answer to that is: It does not exist.
Cocos2d-x is a game engine, and it’s no different than any other game engine. Think of it as both a toolbox and a set of building blocks. How you use it is completely up to you, and the current documentation, along with the demo application, are there to show you what is possible with this game engine; they are not there to guide you step-by-step in writing your game.
Think about this example for a second: How many different ways does one need to document the creation and movement of a sprite? Once you see how it’s done, what else do you need? How you use this knowledge is really up to you.
The current documentation may not be comprehensive, but there are plenty of demos and related source code (cpp-tests for example) that demonstrate the majority of the core parts of Cocos2d-x. Nothing about these demos is hidden from you; the source code is right there for you to browse through, and it’s quite easy to understand (assuming you know the C++ language, and if you don’t, that’s no fault of Cocos2d-x).
Now, I know that many new developers tend to go through the same motions when working on any kind of application (not just games). What happens is that they aren’t quite sure where to start, being a little overwhelmed by the different aspects of their project. Their focus tends to be on everything… literally everything… which IDE should they use, which framework, which platform etc etc. Sometimes it’s because they really don’t know, but more often than not it’s because these things already exist, so not much thought has to go into it. It becomes about wasting time choosing something, for example, engine X vs Y vs Z, and discussing the finer points of X, Y, Z engine, than to have to think about the design of their game or application.
It’s easy to lose yourself on what is irrelevant (at least in my opinion). If you take a step back and really think about it, you may come to the conclusion that none of those things really matter (note, they do, but not for the point I’m trying to make here).
When you design a game, you are creating the structure and flow of the game, and that should not be tied to a specific programming language, framework or engine; how your game is supposed to play has nothing to do with rendering, audio, platforms, or whatever other technical aspect that is used to implement the game.
So, start planning out your game by work out the game design. Once you have this, break it down into manageable pieces, and repeat this process until you get to the most basic functionality. For instance, does your game have a player character that can move around and hop over things? Great, let’s break that movement down: left, right, forward, back, etc etc… and let’s not forget jump. Assuming you did break down the movement into the most basic functionality, this is where you should end up:
player.jump();
Once all of this is worked out, guess what? Now we get to the other fun (?) part, how do we implement this “jump” in the game engine we have chosen to use? You know what you’re looking for, so you can check the documentation and demos to see if there’s an example of this functionality, and there most likely will be. If for some reason you can’t work it out, then guess what, you know exactly what question to ask to enable someone to help direct you to the answer.
Documentation, while it’s great when it’s there, is not really going to help you write your game.
