I have been using cocos2d for a loong time. My first game was made in version 0.95 I have spent last 3 years making my living by developing games in cocos2d v2.

So here go my 2c, consider me an old guard voice

1) SpriteBuilder should not be forced to launch a project

I think SB is a great tool, but it seems it's getting a lot of bad PR lately. In a way, you are hurting it by force feeding it to devs. I should be able to decide if want it or not. Open source game engine with such a hassle at the beginning is a bad move IMO.

2) Cocos2D-swift is a bad name. We all know it, I won't be all over that again. The problem is that Cocos2D-SpriteBuilder is just as bad.

You shouln't tie yourself to any specific language (-swift), tool (-spritebuilder) or device (-iphone). @birkemose, what if for some reason you decide to stop SpriteBuilder development? Will you change the name again?

I understand the need to diffrentiate from other cocos2d versions, but stay agnostic.

My proposition is:

Cocos2d-Original with prefix CO or CCO

That way the message is super clear - a game engine called cocos2d. Original, because it's the starter framework. We were here first! Who cares what language? Or what IDE?

Hello,
I have used Cocos2D since the 0.9x days. We launched our first Cocos2d game when V1.0 was official. Currently we are building on top of Cocos2d 2.1. So I am accustomed to changes in the API's and port efforts. However we have not gone to V3.x because the once again changes in the API. It gets old and for those of us that are full time game developers it gets really old to constantly have to port apps because of API changes. So we heavily modified our 2.1 version of Cocos to support the 6/6+ and addressed the 64 bit issues as well.

So when I read the threads about V4 and a name change and class prefix change you can understand that we were not happy. In fact we are not happy with the pairing with Sprite Builder and no available templates for old school builds. That first game we wrote was a chart topper and still supports the studio. Not going to convert it to the Sprite Builder work flow and still have to port V2.1 to V3.x cocos API. Frankly that is unreasonable for a tool developer to expect.

So here are my thoughts on a name change and how to fix some of the issue with it and how to make people happy to some degree.

* Focus on the Sprite Builder part of the new combo for the name. Change the combo name to Sprite Builder and use the SBGE class prefix to identify the old cocos part of it as "Sprite Builder Game Engine".

* If you are going to depart you need to depart in a big way. Since Apportable is paying the bill and there seems to be a real interest in build for iOS/OSX/Android from the combined product then you need to focus efforts going forward on Sprite Builder and not on the game engine.

* Build a SpriteBuilderGameEngine.framework package that can be properly added to a project to support the old school style of building games. This is really important to keep people happy. It tells the iOS / OSX only group that you support them with ease of use. For those that need cross platform support with Android they have to use Sprite Builder and that part is a feature of Sprite Builder not the game engine. So market the feature correctly and that is a non issue.

* Using SB for prefix is headed for trouble and name collisions. While I am still looking for the exact package that uses it as it has been two years or so since I saw it I have come across a tool that had SBNode as a class name. Just saying SB is may not be a super safe prefix.

* The key here is that you need to appeal to those of us still on 2.1/2.2 and still move the platform forward. As a company we have a ready to run base game to start all development from. It has place holder art, all the screens, GameCenter, iAP, and so on already integrated into it in a pluggable modular design. This starting point runs and can be navigated. It allows a prototype game to be built very fast that is of a completion level we can ship it to limited tester for evaluation very quickly. The company is heavily invested in this approach and our tool chains are designed to support it. Consider your audience when make this move and remember if the migration is going to be substantial a smart company will look at other options like Unity as one example. If you make the move a no brainer then they tend to not look at other options.

So while I dread a huge porting effort, I would support a .framework package that allowed us to keep our current work flow. Even if it means changing the class prefixes everywhere. With a .framework package available I would also then be supportive of the Sprite Builder work flow being the marketed focus going forward. Just remember to keep the .framework package updated.

The final piece is if I have to use the Sprite Builder work-flow to create new projects and all I am getting is Android in addition to iOS/OSX I will take the company to Unity because there I get Steam/PC, Linux, iOS, OSX and Android. Basically I am going after the biggest bang for my buck and that is Unity.

Does the Tiled editor support tile offsets? I remember seeing references to them in the code, but I'm not sure if they do what you are describing. I'm not really an expert on that part of the code. The Tiled editor itself has changed so much since it was written originally by Riq, and it hasn't gotten a lot of love in v3.

Templates, oof. The short version of that is that Xcode templates are awful The only documentation on how to make them is reverse engineered. You can't use subprojects in them, so they make really brittle projects that are really hard to upgrade without a lot of manual effort. Every time we added/removed/renamed a .m or .h file, we would have to edit the templates by hand in 3 or 4 different places. It was incredibly tedious and error prone. Continuing to support Xcode's template system is basically not an option.

So. I've talked on several occasions about making a Git based template. I figured I should finally follow through on that so I made this: https://github.com/slembcke/UnofficialCocos2DTemplate It works exactly like the SpriteBuilder templates, but does not require SpriteBulider to be installed, and it configures FileUtils in the "classic" Cocos2D manner using suffixes instead of directories to locate files. Also, it's a fully configured Git repository with a submodule for Cocos2D which should make it relatively easy to upgrade Cocos2D versions (within 3.x anyway). Is this more what you were looking for? This should become easier to maintain when v4 is released. Maybe we can turn it into a more official solution then.

I really am trying to improve the separation between SB and Cocos in v4 since there has been a lot of negative feedback about that. The biggest problem is the FileUtils setup that SB uses. In v4, we absolutely had to fix FileUtils by moving to something more generic instead of hardcoding support for every new iOS device into the API. At the same time I used the opportunity to work with the SB developers to agree on the same default setup. To be clear, changes were designed to make Cocos2D more powerful and easier even without SB. I spent a lot of time in discussions trying to find a solution that everybody was happy with. The driving ideal this time is to improve Cocos2D to improve SpriteBuilder instead of improving SpriteBuilder at the expense of Cocos2D.

Another thing to keep in mind is that without SpriteBuilder, there might not have been a v3 at all. If we stopped developing alongside SpriteBuilder there probably won't be a Cocos2D future either. I get that people get suspicious when money is involved, but ultimately we can't afford to work on Cocos2D without being able to pay the rent. The teams have been getting better at working together, and I'm really optimistic that we can avoid a lot of the problems that happened with v3.

The class prefix idea has been completely dropped. In the larger Cocos2D scene, our branch has a small identity crisis. That's part of what it was trying to fix, but it wasn't a good solution.

I'm not trying to be snarky at all by asking, but is using SpriteBuilder to generate a template really a problem if you never have to use it again after that? Is the Git templates I posted above better? I could go on for a good hour about how bad Xcode templates are. There are so many problems with them. One thing that I actually kind of like about SpriteBuilder is that you can use it as much or as little as you want. Unity makes it very difficult to do a lot of simple tasks from code. I've often found myself doing repetetive monkey tasks in the GUI as a workaround for some of the poorer APIs. Since Cocos2D was a code-first framework, the APIs are usually much better.

Not sure I understand the .framework part. It sounds like it's solving the same problems that the newer templates do by using a subproject for Cocos2D. Unless it's changed recently, I don't think you can build proper frameworks for iOS. In the past, you could could make frameworks with a static library in them for iOS, but it was sort of a hack due to the way the linker worked. AFAIK, Apple has never supported that on purpose.

Using Cocos2D as a sub-project means that we can add/remove/rename files and change compile settings within the Cocos2D project without breaking every existing project. This is part of the reason why the Xcode templates are so awful. They force a brittle project structure like that. With submodules, a project is basically just a dozen lines of code for each platform in a main.m file and an app delegate. We are trying to decouple that even more in v4, and have already made good progress on it. The new SpriteBuilderAndroid plugin has made this a lot simpler as well.

In v3 we broke backwards compatibility in a huge way. Looking back, this was a big mistake. It caused a lot more work for people upgrading than we had intended. There will be a few big changes that can't be avoided in v4 like how files are handled, but overall I'm trying to make sure that everything still has a deprecated implementation. This should make it much easier to get a project to a workable, running state before worrying about cleaning up deprecation warnings.

Make sure you aren't throwing out the baby with the bathwater if you do switch to something else. Cocos2D's file suffixes might be sort of broken, but they do allow you to save a lot of memory by avoiding loading oversized assets. This isn't something that other engines generally do (Unity does not). If we can make good on our promise to fix the problems with suffixes in v4, it should be a huge improvement over other engines.

Now about using Sprite Builder to set up the template and never using SB again. Point was that we would have to use sprite builder and pull apart the project it created to get to something that we can modify to take our modular system. With the upgrade from 1.x to 2.x we did a side by side of our starting point and the 2.x template. Took about 10 minutes to update the required areas. Maybe the issue with 2.x to 3.x is just the huge amount of changes versus the Sprite Builder issue. Sprite Builder is just another cog and it kind just adds to the mess of migrating.

About the framework. I really don't understand why Cocos2d-Swift is not released as one. We get several of our other tools from 3rd parties as frameworks. Being that way makes them very modular and we just drag the framework into the project in XCode and start coding. Being able to replace cocos2d version by simply swapping out a framework would be very user friendly. Again we are doing this with other 3rd party tools that are provided this way and it really made our development flow easy.

As for the naming and class extension part. Glad to hear that they will not be changing.

Will watch for what V4 offers but reality is that V3 is a big effort that we as a studio will not be taking on when faced with known changes coming for V3 to V4 migration. I personally believe that such effort will be saved for a pure V2 to V4 migration and maybe by then you will have the template issues worked out.

Thanks for responding and looking forward to see where Cocos goes from here. I do want the option of having Cocos on a dev machine and not every having need to install Sprite Builder. I think that is critical to the success/failure of V4.

Like @slembcke said, we could have done a better job at easing developers from 2.x into 3.x.You live and you learn.We have put a lot of effort into how we can make the v3 -> v4 transition a much better experience.

Apart from that, I do not agree that using SpriteBuilder, has made the daily life of any Cocos2D developer harder. Yes, it is a slightly different approach, but other that that, it is pretty much same-same for any experienced developer.

However, for any new developer it has become much easier if you use SpriteBuilder. The ability to update Cocos2D with a single click, is a major feature alone.
And there is nothing here "written in small print"

You can continue to use Cocos2D 100.0% stand alone, and on top of that, you can use SpriteBuilder to aid you in anything from a simple menu, to managing all your assets and your entire game layout.

@simengie Could you list a few of these frameworks you mentioned? Preferably publicly available, with a free version. I like to understand how they do it. Like Scott said, my impression (still) is that frameworks for iOS are a total hack - you can somehow get them to work but only with severe drawbacks. But maybe that has changed because most of this framework-building process is essentially based on Xcode 4.

One thing that's definitely going to be an issue with a framework is that the code needs to be prebuilt (unless it's actually possible to share source code within a framework). Meaning you lose the ability to step into cocos2d's code, and that makes debugging more difficult than it needs to be. The Internet is full of devs complaining that framework XYZ crashes on them and they have no way of telling whether it's a bug on their end and the framework simply doesn't provide a good error message (ie "file not found") or whether the framework itself has a bug.

@gaminghorror So went to see which of our frameworks are open source and I think I understand why they are frameworks and not source code. The answer being they are not open source and publicly available. So the .framework is serving to protect their IP from what I can guess. Now that being said there is one that most game dev's will be familiar with and that is Chartboost. Since version 5 of their SDK it has been available as a .framework build. They have moved from providing source to providing a compiled package and I am sure it was to protect their IP more than it being easier for the users.

Sorry I could not be of more help on with info an open source frameworks. The very idea of open source negates the need to deliver a compiled framework to protect your IP because you are openly sharing that IP by providing the source code. Sort of why bother with the extra work when I am giving them the code anyways situation.

You are correct that the code needs to be pre-built for use in a proper framework. I am on the fence with the ability to explore the code. It is nice and allowed us to heavily modify our v2.1 branch to support iphone6/6+, 64bit and fix several of the issues that V2.1 had as well as add functionality. Likewise a good compiled framework should not have issues that require code walking to solve.

Not going to continue the .framework discussion as it is pretty clear that cocos2d will continue as a source release. That is fine with me. I am more concerned with whatever they do stabilizing the API and giving us better file handling and easier device resolution support.

Not really no. I can't tell you if there is something new in that part of the code, I stopped searching for a solution inside the framework and started developing my own integration of isometric tile world. I also tested Tiled a few days ago and couldn't find any function how to set some offset for a specific tile. I wished there would be some good integration with SB but I'm fine solving that problem by myself.

Update: You probably should remove this part of the docs at CCTiledMap - "A tile is converted to CCSprite when you call [layer tileAt:] - doing so on every tile will greatly increase memory consumption!
If a tile became a sprite it can be rotated / moved / scaled / tinted / fade out"

Long time developer of Cocos2 (since 0.81) and I just thought I would toss in my 2 cents:

1) As for name, why not something simple like Cocos2d-iAM
As in "I think, therefore I am..."
...or "iOS, Android and Mac" for those looking for a less "deep" meaning

2) SpriteBuilder may very well be a great tool, but a standalone template should (IMHO) never have been abandoned in the first place. The best part of Cocos2d is the ability to build (and more importantly tweak) the code to fix bugs and customize the FULL source code. Having an IDE is great (esp. for beginners) but a template/barebones build has it's place as well.

3) It is great that Apportable is "paying the bills" (whatever that means exactly), but that should not be a guiding factor for the name (nor should it be a factor for the direction of the product).Cocos2d was never called Cocos2d-Zynga (thank goodness). Heck, if we are going to consider credit when naming a product, then the name should really be changed to Cocos2d-RQ

4) Backward compatibility should ALWAYS have been a priority. There will always be changes that must be made, but when backward compatibility was tossed to the wayside, I believe that that was a major factor in the eventual decline of the user base.Even now, many people are still using Cocos2d 2.x for that very reason... Granted, Cocos2d may never be able to be backward compatible with Cocos2d 2.x, but from here forward, backward compatibility should forever remain a top priority, because (IMHO) losing it was a big mistake.

2) SpriteBuilder may very well be a great tool, but a standalone template should (IMHO) never have been abandoned in the first place. The best part of Cocos2d is the ability to build (and more importantly tweak) the code to fix bugs and customize the FULL source code. Having an IDE is great (esp. for beginners) but a template/barebones build has it's place as well.

I feel like there are some weird misconceptions about using SpriteBuilder to generate project templates. Other than opening SpriteBuilder to generate a project, you never have to open it ever again. It's a scene editor and asset manager that you can choose never to open again if it's not useful to you. It has also never added any layers between the developer and the Cocos2D source. The only change in that regard was to make Cocos2D a subproject instead of directly importing the source into a single project/target. That's a huge part of what made older Cocos project so brittle and hard to upgrade. I cannot reiterate enough how awful Xcode templates are.

The things the SpriteBulider templates did change in a negative way was:

You needed to download a 50MB program to generate project templates that you may never use again.

It changed some of the Cocos configuration to be different from what people expected.

It added extra files to your project templates that you might not want.

questor:

but from here forward, backward compatibility should forever remain a top priority, because (IMHO) losing it was a big mistake.

No argument here. There will be more deprecations, but relatively few outright removals of functionality. So your project might build with a bunch of warnings at first, but we are trying to make sure it's at least easy to get a project running right away after updating.

Cocos2D has been my go-to game development toolset/framework for the past 2 years. So not as long as some. I have a game in the App Store using it.

One perspective I can offer is that for 4 years I was a member, then team lead of developers working on an Open GL rendering framework for Qt, called Qt3D. I know how difficult it is to make decisions about the direction of the project, based on guesswork about where the technology is going, keeping existing customers/developers happy who are using old versions, while still adding new features and keeping up with changes in the field. Its damnably hard thing to do.

Regarding the name: I think the history was that Ric Quesada named it Cocos2D-iPhone after following the API of Cocos2D (a python framework). So with the other projects like Cocos2D-X and Javascript, Cocos2D has actually become a flag-name which indicates that the XXNode and 2D scene-graph approach, with sprites and such is being used. I actually like Cocos2D-Swift. If you'd tried to canvas for name change suggestions you'd still be stuck with Cocos2D-iPhone months from now. Making the leap was good. The Swift language is something I'm pretty excited about, and it is definitely the future of coding for Mac and iOS - and perhaps for Android too.

If it gets changed to Cocos2D-SpriteBuilder, that is not bad because I guess it makes the connection between the two projects, and it elides the language issue, I guess. But I think a year from now, Objective-C is going to be seen as pretty old school, it will be going the way of Carbon and plain C, and as Apple's own engineers are developing more and more of their own internal stuff using Swift - dog-fooding so to speak - we'll see it get better in leaps and bounds. I think the fact that yes you can code for Cocos2D in other languages than Swift - you can use C, C++, even Java or Lua with some integration and bridging, is not so relevant. I think a year from now Swift will be looking pretty good as a name. It will be a good signal to new and current developers that the project is about using a Cocos2D API on environments that support swift.

Regarding the issue of making Cocos2D projects without SpriteBuilder: having a tool create the base project is very important for newbie to intermediate developers getting started with a project. I think its totally reasonable that the Cocos2D team should be able to expect that folks are working from a properly configured baseline, and that is very hard to do if Cocos2D is being pulled in as a framework, or CocoaPod, or drag-n-dropped in. Its very frustrating trying to deal with a request for help when you find that some -Dswitch is missing and you have just wasted hours trying to support some new starter who got their project set up wrongly.

Back in 2012/13 I was working with Cocos2D and used the Xcode templates to create my own template project, that I then saved off as a base for future games. The problem with a project base that I saved off was keeping it up to date when Cocos2D moved ahead with bug fixes and new features I wanted. You can get pretty much the same thing by using SpriteBuilder to generate a base project for you, and it has the benefit that you can update the base library.

I understand that for power users conceptually it seems like OK, I have to get this SpriteBuilder app to create a new project, and then never use it again? I understand that thinking. Also if you've been using Cocos2D from 3-4 years ago when everything was a template, and when there was a CocoaPod, the new tight coupling with SpriteBuilder might seem like some new painful thing that's imposed.

But its a free app, is it really such a big deal? I don't think its really a problem.

I'm not sure that its really such a pain to use SpriteBuilder to do this. I can think of plenty of examples where a tool is used to generate code, either to start a project or as part of one. I've bought the Receigen app to generate my IAP code. Also it is like if I wanted a Rails project I'd type "rails new my_game". There's plenty of precedents for having an application that generates new projects.

Also I don't agree that really big games cannot use SpriteBuilder. SpaceBotAlpha is not that big at 20,000 lines and around 150 CCB files, but its big enough and I find it easy to use SpriteBuilder to include sprites and so on into the project.

The one gripe I have is that the project winds up with a large tree of Coco2D code that I have to lug around when checking in and cloning and so on. There's also a lot of tests and other cruft that I don't want in every game project's repo.

I like @slembcke's project, where you have Cocos2D as a git submodule, and then your way to update to get new features is to update the submodule. I actually have my game SpaceBotAlpha set up with my fork of Cocos2D as a submodule, and its much nicer - although I have to be a bit more aware of what I'm doing with git. I can imagine newbies might get themselves in a knot if they're not used to using git from the command line.

Maybe if Cocos2D-Swift had supported tags for minor dot point releases and a script provided to generated projects to run to update the submodule to those tags that would be good, e.g.:

Developers are in some respect like paranoid light-sensitive rabbits, and I understand why, because there are many companies out there, just trying to get your credit card number, and force stuff down your throat.

Cocos2D will never be that way, so if we officially make SpriteBuilder the way you create new projects, it is because we honestly and truly believe it is the best option. Maintaining xcode templates, is like trying to sterilise ants wearing boxing gloves, and SpriteBuilder makes that whole process so much easier and streamlined.

That does not mean we can not improve, or that we do not listen to the complaints. We realised, that because the file systems of SpriteBuilder and plain vanilla Cocos2D were different, we had to change that. Towards plain vanilla of course, not to sacrifice those who work that way, and as a bonus, @slembcke made a temporary project template to aid it all.

I do not think, that these pebbles on the road, changes the fact, that with a little TLC and finetuning, using SpriteBuilder to create new projects, will be a wast improvement.

For the first time you think that you are forced to use SpriteBuilder and it all starts with the fact that would just create a template. I was of the same opinion and did not want to use the SB.

But now, when I realized how quickly and easily you can create UI, I can not imagine what I have to set all positions of buttons, text, etc. in the code manually. This is much longer than just put a button and put it auto position to any screen and device using SB. Moreover immediately see how it looks and change anything if required.

However, I found some of the limitations and errors at the moment. And they really annoying to me, but I found a solution for some of them, are particularly critical.

Squares: Puzzle Game

Volodymyr Klymenko

Simple mechanics, intuitive interface and puzzles that will make you scratch your head, but won't leave you disappointed!How to play: - tap on a square to move it - put the square on a circle, so that their colors match- think ahea...

Free

But this was not so easy as I think, because of these bugs or problems:

I'm using 1.4.9 SB. I just started my project. I trying to port from v2 to v3 my game - http://forum.cocos2d-swift.org/t/draw-a-car-beta-testers-requested/17001 I have a lot of resources in my game: 100Mb of pure png files and will be more... [image] So, I just publish all resources and run on iOS, all ok, then close SB editor. Then after some changes in the code, I opened SB again just for editing MainScreen.ccb and I changed in it only position of the CCButton. After that I just press C...

I did: git clone https://github.com/apportable/SpriteBuilder cd SpriteBuilder git submodule update --init --recursive cd scripts ./build_distribution.py --version 1.4.9 -tests false Then open Xcode project - checked debug was by default already, so I just build project and just run(I did no changes at all) and then I was able to pack pvr.ccz. Thank you. UPD: one thing that I removed it's .spritebuilder Document type. Because it's bad when I open my root project folder - it just opens SB p...

Have a look at CCFileUtils.m approx line 231, if you have a look it will show you the asset prioritisation for each device family. So for iPad you can see that it will fallback to iPhone HD assets as long as _enableiPhoneResourcesOniPad is Yes however I'm sure it is by default. You can test on iPad device or iPad Simulator.

I don't know exactly if it's bug or no. But anyway this is strange behavior as for me.. Here is my setup: [image] But when I tap on the button I see this(image opacity changed): [image] And here is the normal state of the button: [image] Why it's in opacity when tapped? Also, I tried to change opacity for CCLabel for state - selected. Changing of the color for selected or highlighted state not working. It's just doesn't set any color or opacity. Also, how to disable shadow ...

Oh. I don't know after update to 1.4.9 or before I just setup my 10 languages. But when I set iPhone language to Russian - I see this: [image] So, there is not default language like ENG. NSArray* preferredLangs = [NSLocale preferredLanguages]; Gives me: ru As result no translations loaded, because I don't have ru lang in my localisation. Thats issue in latest cocos 3.4.9. I fix it, by just add coupe of lines, that enable "en" by default. But this should be fixed anyway.

Hello, I already done porting one of my games from v2 to v3. It's was not really simple... no, problem not in the my code of the game, but in SpriteBuilder bugs mostly and a bit cocos2d.. About bugs I reported, on SB forum. So, currently I'm looking for porting my game http://forum.cocos2d-swift.org/t/draw-a-car-beta-testers-requested/17001 from v2 to v3. In general I see no problems to do this. However I see a like difficulty for CCButton. Yes, it's easy and fast to create a simple scene w...

And this is not completely all, you can check my profile activity on SB forum and you can see some other thoughts.
_
So, be ready face with some of this, however I hope all this will be fixed in near future.
But I will found more bugs in the uture too

Sort of. The actual scaling is very fast, and takes less time than creating a full sized texture. An iPad 2 should be able to load a scaled texture faster than an iPad 3 can load a retina sized one. It won't be as fast as loading a natively scaled texture on an iPad 2. You can still provide images with explicit scales, so you can make the choice if you want to trade (a lot of) disk space for (a small amount of) loading performance.

kamikaze:

Will it scale the images every time the app launches / the image is used?

We might add caching later, but it's not simple since there are options for loading images. If you are really worried about image loading performance, you should be using PVR files.

kamikaze:

Is this limited by the max texture size? Ie can images greater than 2048x2048 pixels be autoscaled on devices that support max 2048x2048 textures?

The maximum texture size is a GPU limitation, and the full size texture is never loaded into a hardware texture.