CocosBuilder - New tool for visually creating Cocos2D scenes

cocos2d for iPhone » Programming » editors / tools

CocosBuilder - New tool for visually creating Cocos2D scenes

(120 posts) (34 voices)

Started 1 year ago by vik
Latest reply from kennychong

Tags:

12…4 Next »

vik
Member

I have been working the past couple of weekends on creating a visual editor for cocos2d. Now it is finally ready in some sort of very early alpha version. My plan with this release is to get some feedback, to figure out how to proceed with this project. If it is appreciated I will definitely continue working on it, otherwise I can probably find something more worthwhile to make of my free time. :)

You can get your copy from here: http://www.cocosbuilder.com (it's free)

CocosBuilder is mainly meant to be used for making menu screens etc. This version is very rough, it seems to work, but the interface isn't very polished. On thing I would like to add (apart from support for more node-types of course) is an editor for making actions. But I am not sure how to design the interface for it in the good way, so any ideas on this subject is greatly appreciated.

Anyways, I hope you enjoy the download, and let me know what you think!

Posted 1 year ago #
vik
Member

Oh, and here is a screenshot!

Posted 1 year ago #
spadict
Member

I'll start by saying this looks Uber-Awesome and thanks for sharing it for free! I will download and have a look, though I'm not sure if I'll have any feedback for a few weeks, most of what I need at the moment is already built. However, I do see this as being a handy reference tool for visualizing things whilst coding.

Does it work for building CCLayers as well?

Posted 1 year ago #
alexasha
Member

Downloading ;-)

Posted 1 year ago #
vik
Member

Yes, currently it has support for CCNode, CCLayer, CCSprite, CCMenu and CCMenuItemImage. However, right now you cannot set any custom classes for the objects (like you can in Interface Builder), but I will see if this is possible to do in future updates.

Also, I am planning on adding support for many more types of objects, sprite sheets etc.

For the interface, it's not very polished. For instance, there isn't support for multiple documents and there are no handy palettes or drag and drop. I'll try to fix those too eventually.

Posted 1 year ago #
cocojoe
Member

Looks good, I'm working on some menus just now so will try it out.

Although I'm using sprite sheets I still have the original assets for placement, at this stage my main interest is to quickly see the 'position' and enter manually in code.

However the idea of letting a designer create the menu layout and I can simply load a plist is most appealing :-)

Posted 1 year ago #
vik
Member

cocojoe, that is the main reason I wrote this program; the goal is that a designer should be able to use it. It can potentially save lots of time if they can layout the scenes themselves. Plus it's the most boring aspect of creating a game. :P

Posted 1 year ago #
spadict
Member

I messed around with the builder a little bit and had one thought:

You are generating ccb files that are then parsed into your project; Is this efficient during run time?
I think I was expecting something that would generate premade CCScene code for me to work with so that it would help me develop views more rapidly but if its all in the ccb file, I can't do much extra customization before running the app can I?

Posted 1 year ago #
jd
Member

Great idea. I messed around with it too. The interface is very confusing and without drag positioning it's not saving as much time as I anticipated - still faster than compiling. I think you can build off it though. It would be great to output a CCScene with CCLayers as spadict says or even the coordinates,etc into a plist.

Posted 1 year ago #
vik
Member

Performance-wise I guess it depends on what you are doing. I wouldn't recommend loading tons of ccb-files in every frame of your game. But for interfaces and menus they should be very quick to load. The main advantage of generating custom files (or they are plists, actually) is that you can edit them at any time to tweak the interface if you need to. If you generate code, then make changes it's very hard to use the tool again.

Currently, you can access all the nodes of a graph by using getChildByTag, and setting the tags in CocosBuilder. You can also make callbacks from MenuItems by setting the selector property. In future versions, I'll investigate if it is possible to load custom classes for the objects in the scene graph.

Posted 1 year ago #
vik
Member

jd, I know the interface really need some love. Drag-positioning would of course be the best, right now you can move objects by nudging them (cmd-arrows) or move them 10 pixels (cmd-shift-arrows).

The file that CocosBuilder creates is a plist, just open it with the Property List Editor. :)

Posted 1 year ago #
abitofcode
Moderator

I'd include a tutorial and example scene to load in with the demo to get people playing with it.

Just been playing with a couple of sprites and the blending/color options and (assuming these are being applied correctly) this could help reduce the confusion relating to blending. :)

Posted 1 year ago #
jd
Member

@vik - didn't realize it was plist and that I could use the shortcut keys for movement. I'll give it another shot. Thanks!

Posted 1 year ago #
Stepan Generalov
Moderator

OMGsh!!! THIS IS SO AWESOME!

I thought about the same thing, but i hoped to start developing it after releasing next update of my game, but only if it will give enough profit. And now i see that someone is developing this for me right now - this is soooo cooool...

I didn't plan my own editor in details, but i have some statements that i see clear.
1. Minimal functional, CCNode, CCSprite and CCLabelBMFont should be enough.
2. Maximum convience - pinch to scale, move by drag, drag n drop files from Finder to create new Sprites.
3. Based on Cocos2D to see how this exactly will look like.
4. NSCoding support for supported nodes in Cocos2D. This should be extension to existing Cocos2D in new files, no patches to existing Cocos2D code.

Using this principe i think it's possible to construct a Node with editor, save it, than load as a node and add it in another node, using properties of CCNode.

So editor will create files, that can be loaded automagically into CCNode.
Something like :
[CCNode nodeWithCoder: [CCBuilderSupport coderForNodeWithFile: @"somereadyNode.ccb"];

Or more manually like:
[CCSprite nodeWithCoder: [CCBuilderSupport coderForNodeWithName:@"spriteFoo" fromFile: @"nodeWithLotsOfSprites.ccb"];

I would like to see this project Open Source, IMHO it will have better quality then.
Also i would like to contribute to this project even if it will not be OpenSource.

When i was thinking about my own simillar editor, i planned it as Open Source only, cause i don't think i can raise good money with it, so making it's free will help the community, cocos2d and me of course, cause somebody always will do something instead of me ;)

I will download and install CCBuilder right now, and post after playing a bit...

Posted 1 year ago #
Stepan Generalov
Moderator

Tested it a little bit.

It's impossible to set fractional number in propertys now.
And right sidebar can be avoided. All propertys as Rotation, anchor point, position of course can be set via main window.
Some graphics editor like Gimp or Inkscape can be a good example for this. Of course right sidebard must exist for accuracy input, but i don't think that everybody will use it all the time.

I think CCBuilder should target a graphics designer, not a Cocos2D coder as main user. This principe will lead development to the right way.

One example: Zwoptex vs TexturePacker. Zwoptex is extra simple and very good designed, Texturepacker is not so good polished at design, but have a lot of features. I use Zwoptex for creating spriteSheets in PNG. After this i use TexturePacker commandLine to convert it to pvr.ccz, also i used it's command line for hq2x for easy retina resources creation.
Both programm rocks and their developers are great guys. Andreas fixed very fast few bugs in TexturePacker just for me. But TexturePacker is powerfull commandline utility, and Zwoptex is tiny and fast spritesheet creator.

So i think keeping in mind that CCBuilder is for designers, not programmers and trying to be more like Zwoptex, less like TexturePacker will make CCBuilder ultimate weapon ;)

BTW, when i was thinking about my editor, i created an Icon just for fun and give it a name ;)
CoCoNade, like Limonade (Cause Sprite is well known lemonade drink and i planned editor for CCSprites as main feature )
Here's how it looks like:

Posted 1 year ago #
cocos
Member

+1 CoCoNade looks great! :)

Posted 1 year ago #
abitofcode
Moderator

Particle designer and Glyph designer are great examples of polished editors, aim for this level and you're not going to go wrong. I agree with @Stepan get the tool to a level where artists can use it (but make the advanced features accessible for those who need them) and you're onto a winner.

If you can make the tool flexible to play with the existing tools out there even better.

edit: How about CocoShop ;)

Posted 1 year ago #
slipster216
Moderator

I use photoshop as my level editing tool right now. I simply spit out all the files as if they were full screen images, have zwoptex trim them, them place them at 0,0 with anchor point 0,0 and they end up right where they were in the photoshop file. That said, a layout tool is often preferable, especially when animation is involved. So here's some stuff off the top of my head:

For action editing, I'd suggest a tree view with properties on the side. Essentially, you could do something like:

Action: MyAction
- CCSequence
- MoveTo pos(0,0) duration:1
- FadeOut
- CallFunc self blah

Clicking on any one would bring up the options for that action item. These would be authored in the context of a given sprite, but would be able to be re-used by any sprite, for instance. You should be able to adjust the position of the moveTo action by selecting that node and re-positioning the sprite.

Storage should be in a plist or other ascii file format. An API should be available to automatically load this data for you, allowing you to do something like:

[mySprite runAction:[StageManager actionWithName:@"myAction"]];

CCSprite could also have a category added to it which allowed even shorter forms, such as:

[mySprite runAnim:@"myAction"];

It might be nice to be able to convert any MoveTo into a MoveBy with a simple node swap in the editor, since it should be easy to transform one into the other.

More wacky/longer term stuff:

- Use reflection so propertyActions are supported, allowing you to keyframe a property value on anything
- Use reflection to allow user-definable classes to show up in the tool, be animated, etc..

Posted 1 year ago #
vik
Member

abitofcode, there is a simple example included, but I obviously need to make that more clear! :)

Posted 1 year ago #
hm50
Member

Man, I am really thinking of taking time off work so I can go home and play with this! lol

PS. The CoCoNade icon is pretty cool!

Posted 1 year ago #
vik
Member

Slipster, regarding the actions. This was my initial idea, using a tree view (it's certainly the easiest thing to implement). However, I think something more graphical would be better. Building the animation with blocks on a timeline or something. Not sure how much work that would be to implement.

Perhaps I should start with the tree view, get it working, then improve it later. Ideas for this is very welcome!

Posted 1 year ago #
ralphus
Member

fiddlesticks. I got a 'not supported on this type of mac'. Is it only 64 bit.

Posted 1 year ago #
vik
Member

I'll make sure that I compile the next version of CocosBuilder for 32 bit too! Currently working on adding support for particle systems... lots of properties there! Phew!

Posted 1 year ago #
andrew
Member

I want to use this tool but I want to have all of the code for my objects hard coded into the game. Maybe you can make this an option - but for now I made a Python parser that will convert the ccb file to objective-c code. It's very rough, but here it is if anyone wants it

http://pastebin.com/2y8V2wU1

just run it like "python parser.py myscene.ccb"

it's incomplete right now and only parses the children. but it's still useful, I think

Posted 1 year ago #
vik
Member

andrew, very cool! If it's alright with you I will link to your script and possibly include it in the next release. :)

Posted 1 year ago #
andrew
Member

I don't mind at all, but you might want to test it out first - I made a few errors, like [CCLayer layer] instead of [CCLayer node].

Posted 1 year ago #
vik
Member

I am happy to announce that CocosBuilder has reached version 0.2!

These are the most notable new features:

- Mouse positioning, scaling and rotation of any object. Selected objects are highlighted in the editor.
- Support for CCParticleSystem (CocosBuilder can be used as a free alternative to ParticleDesigner).
- Code connections. Assign custom classes and instance variables (similar to Interface Builder).
- New icon & various bug fixes.

Download the update for free from http://www.cocosbuilder.com

Posted 1 year ago #
riq
Key Master

Hey,

Great tool. A few ideas:
- Somewhere in the near/mid future I want to add marshaling support into cocos2d ( http://www.cocos2d-iphone.org/wiki/doku.php/roadmap )
- So, it would be great that your tool supports this too.
- Since NSCoding is iOS only, an alternative is too use a custom format (perhaps your .ccb format) and also support it in cocos2d-x.

Posted 1 year ago #
robertsze
Member
Looks really cool.

We made a similar tool for internal use:

The GameEngine which gets linked to all of our games automatically parses and handles such menus,
for instance, for the menu layer you see in the screenshot above a simple layer like this is enough.
```
#import "GameEngine.h"
#import "LrMenu.h"

@implementation LrMenu

-(id) init
{
	self = [self initFromDict:@"menu" layerName:@"LrMenu"];

	return self;
}

-(void)btnNewGameClicked:(GameEngineImageButton*)mib
{
    [gameEngineSceneController switchToScene:@"GameScene"];
}

@end
```
This will handle the more games screen, tutorial, leaderboards, online modes, etc.. automatically.

The GameEditor buttons are automatically linked to functions in your layer. For instance, if you press the button named "btnNewGame" the method "btnNewGameClicked" gets called. (if you implemented such a method only of course).

What you should really have is a framework which loads and eventually handles the menu and things like leaderboards, more games, tutorials, etc. This makes things so easy. (Maybe you have this already....). Anyway, just my two cents, great work!
Posted 1 year ago #
vik
Member

Riq, interesting! Right now I made my a class for serializing the objects by examining their properties. Some properties I needed to keep track of in a separate dictionary, because I wanted to modify the cocos2d source as little as possible (to be able to update it in the future). By adding some more getter/setter methods these wouldn't be needed. For instance in CCSprite there is no way of getting the name of the file the sprite is created from.

I'd be happy to contribute code for serialization. The ccb-format is just a plist-file with a different extension, so it should be easy to port to other platforms as well.

Posted 1 year ago #

RSS feed for this topic

12…4 Next »

Reply »

You must log in to post.