CCX: extension lib for faster game development (no third-party dependencies)

– TL; DR; –

  • Possibly a cool lib lives here.
  • Would love to hear your thoughts.
  • Feel free to use and break in any way.
  • Sorry for the long post.


Hey all, big announcment for me personally. I’d like to share with the community my library that I’ve been using and constatly updating to fit my workflow when working with cocos2d-x. It’s 2+ years in the making (though not that big) and I finally feel it’s ready to be shared. It’s a great addition to basic cocos2d-x functionality that really improves speed and quality.

Main attractions:

  • Highly powerful and customizable button.
  • Easy to use and highly extendable scroll objects with collection and pages extension already inside.
  • Screen logger to actually see your logs when the console is bloated with SDK logs.
  • Multi resolution support implementation (will go in detail below).
  • Remote server time manager for those in-game chests and timers.
  • Spine animation cache (think CCTextureCache).
  • A secure data type to combat memory sniffing and value updating.
  • Custom encryption that’s very fast and scares 99% of save file “hackers” (pro tip: that 1% does not matter).
  • Definition based node (sprites, labes, buttons etc.) creation for those reusable UI positioning situations.
  • Key-Value store in JSON format with built in encryption (think CCUserData).
  • Unlockable item manager to easily manage in game content such as character skins and so on.
  • And many more general purpose functions for everyday game development tasks.

Fell free to use it and break however you want. Would love to hear you thoughts!

lib: here
Tests and examples: here

To use the lib, simply clone or add as a submodule to you project and that’s it. It doesn’t have any dependancies other than cocos2d-x itself.

If you get a compilation error try adding these lines to Size class in CCGeometry.h

float& w = width;
float& h = height;


Here I’ll go into a bit more detail about the multi resolution support solution that I’ve come up. Would love to hear the thoughts of cocos2d-x team and you @slackmoehrle.

Differently that what cocos2d-x provides out of the box my approach focuses on aspect ratio, rather then design resolution, even though I have that as well. What I mean by that is that I always have a specific aspect ratio node inside all of my scenes and layers that follow the design aspect ratio. It usually is 16:9.

Now the main takeaway from that is that every scene or layer inside my game essentially has two layers inside. One that covers the whole screen and one that follows the design. And using them together I can gain better results because in reality not all objects inside our games need to follow the design resolution.

Take the following examples from the test project above:

  • The WHITE area is the design aspect ratio.
  • The YELLOW and RED objects symbolize nodes that follow the deisgn. Imagine the YELLOW as a logo of some sort and the RED objects to be main game buttons.
  • The GREEN objects symbolize nodes that are usually coins or settings in many games.

In these 3 screens I’ve used these aspect ratios as examples: 4:3(iPad), 16:9(normal), 18:9(iPhoneX);

Notice that the YELLOW and RED objects always follow the WHITE area and are completely in sync in all of these screens. But the main take-away is that we can allow for objects such as GREEN ones to “leave” the design and be attached to corners where they look much better in mobile games rather then being stuck in arbitrary places bound by the design resolution.

It goes without saying that this example is very simplistic and it has more uses than just having coins in the top corner.

EDIT: Attaching some real world examples from one of my apps to better illustrate the point. The same aspect ratio resolutions were useed in these as well.

– Cheers


That’s really cool!

This seems awesome. I’d like to test this out.

@slackmoehrle Have a go at it and do let me know what you think! If you find any features not self-exmplanatory enough I can quickly add a test case for it to demonstrate.

On a side note I’ve just now realized that I posted this in the wrong category, so you can probably move it if it’s necessary.

And what would your idea against the letter boxing? If a game shows black bars (or other colors), the gamer could think, that the game isn’t professional. From my point of view I wouldn’t play a game, which has some form of letter boxing on none 16:9 devices.

PS: The idea of two layers is brilliant.

Edit: You should replace all \t (tab) with two, three or four spaces in your sources. It’s hard to read without your IDE setting.

My dislike of letter boxing or stretching of any kind is what made me come up with this idea for multi resolution support. Especially for mobile games.

I think UI has to be adaptable and by using this approach I usually have a world of some kind drawn below the container layer to fill the whole screen of any device and then drawing appropriate design elements in the container where they actually have to fit the design.

Sorry for the tab setting, I guess I can change it, but if you’re using a proper editor it should have options to switch the tab style without me doing anything on my end.

I’ve also updated the initial post with a real life example of this multi resolution support technique from one of my games.

The problem is, that everyone you uses your code, needs to setup the IDE in order to show the tabs as x spaces. That’s why most of the developers use spaces for it and not tabs.

Okay, now it’s much more visible how you use the layers. Nice.

Sorry, but we all have the same setup in the office to remove version control diffs from happening in whitespace. I can’t be turning it off and on again every time I work on the lib.

I have tried opening it in multiple editors like VS Code, Atom, and basic Text Edit on my mac and I don’t see any weird transformations. It must be something on your end. Again, sorry, but I can’t do that.

Also keep in mind that some of the tabulation inside the code is just my style of coding, like multiple align tabs before parameter brackets after function names. I won’t get into arguments about that though. :slight_smile:

Hopefully it doesn’t deduct from the value of the lib and you’ll still be able to use it.

– Cheers

Some phones now have aspect ratio 2.1

What are you trying to say?

My approach would still work as you would still have a 16:9 (or whatever else you choose as your design aspect ratio) container centered on that 2:1 screen.

A few warnings are popped up while compiling the library on Xcode, mainly implicit conversion issues and missing switch cases, if they are fixed it would be great

I’ve fixed those up a few days back. Just pull the latest commit in the submodule if you’re using it like that.

Definitely try this tonight when Im back from work :v:

Be sure to give feedback though :smiley: