RANT: why is everything so bad?

cocos2d-x C++
1

So, I’ve been working with Cocos2d-x 3.x since mid last year. I write native code on both iOS ie Objective-C and Android ie Java/C++.

Cocos2d-x is productivity hell.

I really like how easy it was for me to get sprites and collisions up and running. But an excellent product needs other pieces before it can ship to and be part of a press release. In no order of priority:

  1. Z-ordering. What does this even mean? Applies to sprites but not to layers. Good f’ing luck if you figured it out in 1 hour or if it took you days then well, sucks to be you because documentations is hella lolz.

  2. UI. y’know you need a few dialog boxes for inventory or maybe in-app purchases. No two table view maybe sized and positioned the same way. Each case is a research project. Timeline estimates? what are those? Isn’t this fun? /s

  3. Sdkbox. Simple stuff like Google Analytics is a shit show. Forget in-app purchases or leaderboard integration. On top of missed functionality, it crashes, all the time. I had to rip out the damn thing and write all the layers myself for both platforms.

I don’t think I can professionally recommend cocos2d-x in it’s current state to any of my clients.

I don’t like to complain but I just can’t resist because now I’m too deep into the project timeline and I wish I knew better early on. Gentlemen, I sincerely hope you can do better.

2

probably a bug. z-ordering applies to all nodes AFAIK.

3

I’m sorry to hear this! Let us help get this sorted out with you.

You can surely z-order Layers. This might be a bug. What are you specifying when you execute addChild()?

http://cocos2d-x.org/docs/programmers-guide/2/index.html#scene-graph

We have UI widgets, however, you are right. We don’t have any pre-built widgets to handle some common game needs, like hero inventory, etc.

http://cocos2d-x.org/docs/programmers-guide/6/index.html

SDKBOX is under heavy development, however, it should be usable. If you are experiencing any issues, let me pair you up with @nite and @pabitrapadhy so they can help. Perhaps, make sure you are running the latest versions of the SDKBOX plugins. I know they release updates frequently.

Perhaps we can earn back your recommendation over time. We are here to help.

Please complain, this is how the products get better. However, let’s not drop the ‘F-bomb’ when doing so. We like to keep the community neutral to everyone.

We welcome pull-requests too! GitHub - cocos2d/cocos2d-x: Cocos2d-x is a suite of open-source, cross-platform, game-development tools utilized by millions of developers across the globe. Its core has evolved to serve as the foundation for Cocos Creator 1.x & 2.x.

Do you have any hair puling issues now that you still have not resolved? Let’s get you through them.

4

I don’t think there is any open issues with SDKBOX IAP as well as Google Analytics, if you integrated Google analytics it will not the exact definition of “Simple”. Have to deal with outdated documentations all the time :frowning:

5

Thanks @ricardo and @slackmoehrle – I’m sorry I’m just having a very trying day. 8+ hrs and no idea how to position a TableView :confused:

Layers and Sprites Z-Ordering. I’m using Node::setGlobalZOrder(). If Layer #1 has sprites and Layer #2 is sprites where Layer #2 is higher order than Layer #1 then I’m seeing that Layer #1 sprites are painted over Layer #2 contents such as ui::HBox. Even normalizing the layer order to one scale ie 1 to 100 and ensuring that all z-order indices are unique and in increasing order, I’m seeing the same results.

TableView

bool DialogBoxScene::init() {
if (!Layer::init()) {
    return false;
}

auto winSize = Director::getInstance()->getWinSize();
auto sprite = Sprite::create("hello.png");
Size spriteSize = sprite->getContentSize();

float scale = MIN(winSize.width/spriteSize.width, winSize.height/spriteSize.height);
sprite->setScale(scale);
sprite->setPosition(winSize/2);

this->addChild(sprite);

// table
Size tableSize = Size(winSize.width - 40, winSize.height - 120);

// debug
Rect r;
r.origin = winSize/2 - tableSize/2; // centered by hand because winSize/2 doesn't work for position
r.size = tableSize;

auto drawNode = DrawNode::create();
drawNode->drawSolidRect(r.origin, r.origin + r.size, Color4F(1.0f, 0.0f, 0.0f, 0.5f));
this->addChild(drawNode);

_rowSize = Size(tableSize.width, 40);
_tableView = TableView::create(this, tableSize);
_tableView->setPosition(winSize / 2);

 this->addChild(_tableView);

 return true;

}

The background sprite positions perfectly. I can’t use the same logic on the DrawNode to position but whatever. And the TableView appears in absolutely bizarre position. TableView has three rows and just take a look at the screenshot.

c9e4aba176d968d7.png1136×640

This is why I am flustered with the framework. If I trace the setPosition() in all the three classes it goes to Node::setPosition() so obviously the interpretation is in the transforms. So now I have to learn three different patterns for three different classes where all of them extend from Node. The framework should guarantee consistency in the scene tree.

6

the global z order is tricky. it was added mostly to support 3d objects. for pure 2d objects, I would avoid using it.
just use the regular z ordering. it works like this:

parentNode->addChild(child, localZOrder);

“localZOrder” is relative to the parent. Negative z-orders will be renderer before the parent. 0 >= z-orders will be renderer after the parent is renderer.

7

Thanks @ricardo! That piece of information was very useful. I nixed all global z-order usage and implemented my dialog boxes as layers on top that I can animate as pop ups!

I’ll try my hardest to release the dialog box code so others can benefit. Mired in scale9 buttons atm :wink: