Unity dev considering porting to Cocos2d-x

cocos2d-x
#1

Hello, everyone! Newcomer here =)

I’ve been an Unity junkie for the past… ehh… a while ago. I have a project underway, it’s a space shooter with a theme built around colors. It’s a nifty little idea which I care a lot about, and as such, I reached a few speed bumps while making it with Unity, mainly, depending on external stuff from the Asset Store which can be a lot expensive… So, I started considering other engines, and Cocos grabbed my attention. But before I settle down on anything, I needed to know if I’m not just trading one speed bump for another, while having a ton of extra work porting the project.

Anyhow, here’s a quick video of the game running an alpha dev build, so you can somewhat know what I’m talking about:

So, from WHAT I’VE SEEN, Cocos can do everything this game asks for, but I’m having a bit of doubts:

First, as you can see, the enemies follow a bezier line in sequence. In the Unity project, that’s done with a library who lets me position a bezier visually in scene view, and make the enemy sprites follow it. How would I achieve a similar effect in cocos? I’ve seen something about making sprites follow bezier lines on a random forum post, but didn’t really understand it

Second, the particle effects. The jetstream from the ship is a simple enough particle effect, but I rely a LOT on scripted particle effects. The blue laser shot is a scripted effect, so are the portals, the explosions, and the “level up” effect, those are all prefabs built with an asset (from the asset store) that allows me to not only script effects but to have COLLISION on the particles (for the shots). That part is kind of a make or break for me, and I really didn’t find any info on how to achieve a similar result on cocos. How could these effects be done in it?

Anyhow, sorry for the long post, hahah. The thing is that I’m SERIOUSLY considering porting my project, and as such I wanted to make sure I won’t have any nasty surprises along the way. Oh yeah, and also, if I need to change my mindset for any of the answers to my questions, that is really OK. I’ need a nudge in the right direction, tho, as to how to achieve similar results with other solutions.

Again, thanks a lot! looking forward to being a part of the community!

#2

We support this: http://cocos2d-x.org/programmersguide/4/

We support Particles/Collisions: http://cocos2d-x.org/programmersguide/7/index.html#particle-system

I’d like to help you move to Cocos2d-x. Let me know what I can do.

#3

One should first confirm with you why you want to port it? You’ll be losing potential platform targets that you can deploy to. The cocos2d-x particle system doesn’t have a great visual editor.

Cocos2d-x is great for what it is, but I’m not sure you have valid reasons for porting. The Unity assets are only one-time purchases, so if you already have them it’s not any cheaper with cocos2d-x. You’ll lose a ton of time because you will likely not be able to use anything you’ve already written.

Maybe you are very early in the game’s development in which case go ahead and port it if you want, but just note that your game won’t likely be much easier on cocos2d-x.

If you hit limitations of the engine or limitations where there’s lack of low-level control, that’s one thing, but if it’s just some assets being too expensive realize you’ll have to find a similar asset store, an open source version, or write your own with another engine.

#4

Hey, thanks a lot for the answer! Looking forward to it :smile: Now, about the particle effects, let me give you an example, this is the leveling up effect. It actually is a composite of 4 effects, which run at scripted times: the strands (which are a common circular particle stretched, with a circular emitter and having the particles running towards the center), the “glow”, the ball at the center which enlarges as the strands reach the center, the “ring” that grows outward, and the large jetstream. Those are not loops; it’s an effect that is put in the scene, it plays once and then it’s destroyed. Oh yeah, and needless to say, all those effects are anchored to objects and move together with them relatively, I think you can see this effect on the video) Does cocos have anything that supports that, or would I have to build such a system from scratch?

Anyhow, another question: how does cocos2d handle asynchronicity? I rely somewhat heavily in timed loops being ran in parallel to the main game loop (examples: the enemy factory spits enemies in timed intervals, and the auto shooting routine).

@stevetranby Actually what made me consider the porting is that I realized my design would depend heavily on particle effects collision. The asset which I’ve been using to build those has a pretty crappy collision system, and the collisions simply DON’T WORK on Android. There’s only one another asset which may OR MAY NOT work for me, and it is quite expensive ($250 per platform), with no trial version. So you can say I hit a somewhat major roadblock =\

#5

@AlexSkylark alright, so there is some reason you might port over. the only remaining question is how far along are you?

I would think writing the code to build the 2D particle collisions utilizing Unity’s box2d physics systems wouldn’t be as large a task as porting it to cocos2d-x, assuming you have 1/3 or more of the game developed.

cocos2d-x handles async game logic either through its set of actions (MoveBy, Animate, Sequence, Delay, etc) or by sort of managing this yourself with the update ( time delta ) method callback.

Actions are used if you know the start and end states and want the system to handle it. If you need more control at various points in an action’s lifetime then you might use the update callback and track elapsed time and state changes yourself. You can also do a hybrid and derive off one of the actions (or the base class) and create your own action.

cocos2d-x currently will be a different mode of thinking since Unity is an component-based architecture where as of now cocos2d is more of an inheritance-based architecture. These are the defaults. With cocos2d-x you can write anything yourself or find an open source project that gives you an entity-component-system, for example.

Spawning timers are pretty easy to write just as a counter + condition + spawning code it’s about 5 lines of code (not including the spawning code that you need in either engine). There is CCTimer and some other potentially useful helper methods you could use. Or you can use the lower-level scheduleUpdate(&method, interval_time)

Also cocos2d is c++ or javascript (coming from Unity you prob won’t look at Lua), so there’s a potential small learning curve there.

I’m just trying to help you find the shortest path to release by making sure that you don’t take porting or moving lightly :smiley:

1 Like
#6

Thanks a lot for the help

So, the point in development is a ltittle hard to measure. I’d say I’m 2/3 gone in PRE-PRODUCTION. The basic foundation blocks of the game are there, except a major one (bosses), which will take a bunch of work to build, and what’s built is just the basic game systems, using prototype assets and a few example components. Also, a lot of my code is kind of a mess right now and I’d probably take some time in the near future refactoring a lot of stuff for better ease of mantaining code. That being said, I’m well-versed in both Javascript and C#, so language is really not an issue. The biggest challenge in porting the game would probably be the change of mindset, as you pointed out, from a component-based model to an inheritance-based.

To continue using Unity, I’d probably have to write my own “effect system”, to comply to my necessities as stated in the other messages. What I’m weighing here is whether I’d have to do the same in cocos, or if it offers me a framework that allows me to just build those effects and trigger them as needed on the scene. Taking into account that I WILL need to refactor like 30-40% of my code even if I remain in Unity before I enter an actual production stage, plus what I just said, yeah, it’s a matter of finding out if Cocos (or another engine) does have a system in place that fills that particular need :smile:

EDIT: one thing that I noticed about the particles (at least using the online particle designer linked in the programming guide) is that the particles can’t be stretched or rotated to be oriented towards a point (say, the center of a radius emitter). Is that a limitation on that particular designer or on the engine?

#7

While c++11 has many more similar concepts as c# there are still a good number of differences so that while you can be up and running in a day it’ll take a month or longer working with it to hit the various bugs that aren’t valid in c#, for example. You’ll be fine and it’ll come easy, just saying that it’s not without effort.

I would argue that the Particle designer (2d and the new 3D Particle Universe) for cocos2d are really just sampling and prototyping tools. You’ll likely need to write a good chunk of code around them for spawning different effects at different times, etc. You can try CocoStudio which may allow some of these things to be done in a visual editor.

Most of the effects you’ll do will be done importing the PLIST files from a particle editor and then creating the particles in code. They recently improved performance a bit, but if you need tons of particles on screen at once you may want to chat with @Packora as he’s been in discussions on making a much more performant particle system, often by writing extra code to replace or add to the engine itself (one of cocos2d-x strong points is that you have the full source to work with)


Unity’s particle system is excellent and can be designed visually. You can spawn off other particle systems, multiple systems, at different points in the timeline, and change most every setting visually, etc. Then you just spawn a “bullet with trail and random sparks that spawns explosion system on contact” by ID from code.

In cocos2d-x you attach a physics body to a sprite, or at least store it in the class instance. In Unity you’ll probably attach it to the invisible node.

You have mostly just a prototype then (in a sense), so you’ll prob re-write everything by the time you release regardless of engine. In that sense no reason to not port if you want to.

Sounds like you’re interested so you might as well look at the Moon demo example and play around with it to see if you can get it working like you want for your game.
http://www.cocos2d-x.org/MoonWarriors/index.html

Hope some of that helps.

Feel free to ask more specific questions along the way.

(edited)

#8

Will do so, already have one =)

The “gather” effect I use in a bunch of effects is made by using a billboard mode for the particles named “billboard_self”. What this means is that the particle aligns its Y axis with the way it is moving, and also stretching (only one dimension) in relation to its distance from the emiter. Is that achievable with cocos without low-level editing?

#9

Most everything is achievable in cocos2d-x without modifying the engine, and essentially everything is achievable if you don’t mind editing the code in the engine. That is the best part of cocos2d-x in my opinion.

However, what you describe might be “low-level” work from your perspective. Or maybe not? I don’t think you’d have to write a lot of code, but I don’t believe there’s an easy one-button solution for that.

The particle systems in cocos2d are by default mostly based on radial (center out) and linear single trajectory movements.

If I wanted to implement a gatherer I would either derive from ParticleSystem and override the update method to add code that checks delta vector from current to last position and also distance to emitter. It’s writing code, but not modifying the engine. I don’t believe CocoStudio can do that kind of particle manipulation yet.

You could also look into using the physics system instead to handle all the movement and then just attach the sprites with a simple update heading logic each frame (or every x frames, or t seconds). I believe the physics system has attractors and detractors.

Maybe someone else knows a better way.

#10

Actually that involved similar work in Unity as well, since Shuriken (Unity’s out-of-the-box particle system) doesn’t support such things as well. I used a product from the Asset Store to achieve that result, which probably did exactly the work you described.

Anyhow, I’ll take a look at the Particle System class and see how it could be altered. One thing that I missed is the ability of changing particle attributes (like color, size and velocity) based on arbitrary curves, instead of having just a start and end point. Well, like they say, nothing is truly easy, hahaha :smiley:

1 Like
#11

Can you not just use “stretched billboard” as the rendermode? Even if they’re similar in that way the Unity particle system will be much easier to get working, from my experience. Granted we use 3D positional particle systems (z-axis is just for depth sorting the final 2D image).

And as you mention the curves are exactly the “visual editing capability” I was talking about. It makes designing and tweaking more efficient so you come to a final effect much more quickly.

At least in my experience.

I’ve thought about making an export from Unity and import into cocos2d-x with the new 3D Particle Universe classes, but always decide it wouldn’t be worth the effort sing Unity tries its best to not allow exporting and I’d have to write the timeline/curve-based animation system or merge it into the system that works with CocoStudio.

Honestly, it often comes down to the fact that 10-20% of the time is spent coding and building around the engine and the rest of the time is spent debugging, designing, testing, tweaking, and creating assets. So all in all whichever engine/language/framework/tools you prefer is the one you should use.

#12

I actually tried that, but wasn’t able to achieve the same result.
Perhaps I need to study it a bit, I didn’t understand how TRULY those values (speed, camera, length) work.

EDIT: took a look at it. Apparently it doesn’t work that well to make a gatherer. It takes into account a bunch of stuff in 3D space such as distance and angle relative to the camera… the only one who seemed it might be usable is the length one, but it can’t change the stretch ammount over distance, nor lifetime or anything like it. Meh.

#13

Meh. :smiley: