Cocos2d HTML5 V4

cocos2d-x JavaScript
#1

Hi guys,

this is Ibon.

We are currently writing the Cocos2d HTML5 V4 codebase. We are very excited with the upcoming alpha version of this release, but we need your help. If you were king:

What features would like to have added to V4 ?.
What is a must to keep ‘as-is’ from all the code not belonging to the core ?
How would like to see the engine evolve ?

This version will make an strong focus on a cleaner more javascript-y syntax, less inheritance burden, super fast graphics and module decoupling and V3 compatibility. It features:

  • backwards compatibility with V3 where it makes sense. All the core functionality like Node, Sprite, Actions, Easing, Scheduler, etc. are there.
  • complete decoupled renderer. Renders on WebGL and Canvas and allows Nodes to do arbitrary drawing with a consistent cross-browser drawing API, specify shader per quad, etc.
  • a reduced object hierarchy for javascript.
  • sound filtering and convolution. Master volume, pitch, etc. (Only WebAudio)
  • advanced layout mechanism and orientation change notification.
  • retina display enabled.
  • pixel-unit independence and multi resolution support.
  • SpriteFonts. Load fonts from Atlas, GLyphDesigner, Glyphite.com, or any .fnt file.
  • On-the-fly sprite system fonts. Useful to keep full performance with localized content.
  • Build in-game texture packs.
  • Advanced path capabilities.
  • etc.

Thanks.

6 Likes
#2

Is this really official?

If so, please pin this topic! (I’ll throw in actual feedback later).

And also, @Ibon, care to introduce yourself since this is your first post? :stuck_out_tongue:

#5

cocos2d-html5 or cocos2d-js ?

#8

cocos2d html5.

#9

Yeah!

@ZippoLag Yes, this is official.

I’ll introduce @Ibon to the community:

Ibon is an excellent (top-notch) developer, he has been working on game engines, renderers since a long time.
A few months ago Ibon joined Chukong with the goal to create a new cocos2d-HTML5 version.
As Ibon mentioned on this post, the goal was have a super user-friendly JS engine, tailored for JS developers: no c++ patterns, no objective-c patterns… only JS best practices for JS developers.

He already has a prototype and the plan is to release the prototype next week so you guys can test it and give us feedback. I’ve played with it a bit and I can tell you that the new API to render objects is great: super JS oriented, super powerful, and super easy to master.

This API is so good, that we plan to port it to cocos2d-x v4.0.

Also, Ibon is a friend of mine.

(I’m pinning this topic again… please don’t unpin it!)

3 Likes
#10
#11

Awesome! :smiley:

Then I’ll wait and see the prototype and give feedback upon it directly ^^

#12

Looking forward to it :smile:

#13

First and foremost, please fix the JSB <-> native object lifetime bug present in the current native versions of cocos2d-html5.

#14

Is 3D planned in v4.X ?

#15

We’ll forward this topic internally and try to offer a good solution.
Do you think we should open a forum topic on this issue ?
I am totally new in the forums, so excuse me if there’s already one.

Thanks.

#16

Sure it is,
but since it is a full rewrite form scratch, it won’t be available any time soon.
I believe we should make a public statement about the project roadmap. This is pre-alpha code, and still have to focus in some basic engine capabilities.
3D is still in development for Cocos2d-x, but definitely, a stable html5 V4 version should be 3d enabled.

what’d you expect from v4 ?

#17

I’d personally would think that feature parity with cocos2d-x at a high-level makes sense? I don’t think I’d develop anything more than a prototype or micro games (e.g. for jams) if it’s limited to web browsers, but I may be in the minority. If you’re looking for priority of features then maybe asking for games published using cocos2d-js on the web and figure out what features were used most. As you mention the core features (Scene,Node,Sprite,Actions,Animation,Input,Audio) should probably be mostly working in the first release?

So a roadmap would be excellent to know where things stand, what’s actually functional now, estimated delivery, how you plan to support native platforms, if at all (webview wrapper, JSB, etc).

Also are you planning to develop this in public (ie: with associated fork/branch/separate github repo)? Are you pulling ideas from other web engines like Phaser, Construct2, or BabylonJS? I guess I am curious about your target requirements? Is Canvas still supported, or will WebGL can be required? What mobile/tablet/desktop browsers and versions are supported?

1 Like
#18

What is the difference between cocos2d-js and cocos2d-html5? I use cocos2d-js for cross platform development. If cocos2d-html5 only supports web version, I don’t see the point to use it. If it will support native platforms, then it will be conflict with cocos2d-js? why not focus on cocos2d-js instead?

#19

cocos2d-js = cocos2d-html5 + cocos2d-x

1 Like
#20

Oh, I see…

Well, I surely hope that porting from v3.x to v4 is not a big pain. Porting v2.x to v3.x had some minor hiccups, but it was entirely possible, since the API hadn’t really changed that much (aside from the event manager).

But I wonder now: when you say “full rewrite”, do you mean re-implementation of the code or you are also changing the API completely?

I don’t know if things like this are what you are asking about, but if I may drop my dreamed-of feature list (trying to keep it short) it would look something like:

  • An .svg and a powerfull and flexible line-drawing API that’d let us both use vectorial files as assets (rather than having to have multiple .pngs for different resolutions) with good performance.
  • A high-level physics abstraction system that’d let us handle objects independently of how they are shown and what engine (box2d or chipmunk) is used below would be nice. A tool for defining collision areas for said objects would be nice too (althought this’d be more of a CocoStudio feature I guess).
  • Access to the interpolation functions that animations/actions use so that we can use them for animating any kind of values and not just limited to the available functions. Some use cases would be, adjusting volume smoothly, use moveTo-like behaviours on sprites that are currently managed by the physics engine, adjusting some global parameters of gameplay as time proggresses, etc.
  • A simple method (with good performance) to find out wheter a point in a sprite is transparent or not (for use with mouse clicks/hovers).
  • Adding a 4th state to buttons (they currently support active, disabled and pressed) to handled a “selected/hovered” state. It’s not required for touchscreen apps, but if you want to support keyboards/gamepads and/or mouse, they add a lot to the look and feel of menues.

All of this things are doable with the current engine, but they are bit cumbersome and it’d be nice if the engine took care of them without burdening the game developer.

Thanks a bunch!

PS: do let us know when there’s a repo that we can look at! :smiley:

#21

Well, I surely hope that porting from v3.x to v4 is not a big pain. Porting v2.x to v3.x had some minor hiccups, but it was entirely possible, since the API hadn’t really changed that much (aside from the event manager).

But I wonder now: when you say “full rewrite”, do you mean re-implementation of the code or you are also changing the API completely?

Nope, full rewrite means new code for the same features. Some the V3 features won’t make it to V4 in their current state, like the widgets, for example LabelTTF which currently is a bit of a mess. Will there be LabelTTF support ?
there already is actually, but with some changes that could leverage its usage.
This is an open source project, and we expect this forum and the community to be the feature driver into V4.

An .svg and a powerfull and flexible line-drawing API that’d let us both use vectorial files as assets (rather than having to have multiple .pngs for different resolutions) with good performance.

There’s no easy solution to this. Spriting vectors on-the-fly can be a pain. but definitely worth paying attention to.

  • A high-level physics abstraction system that’d let us handle objects independently of how they are shown and what engine (box2d or chipmunk) is used below would be nice. A tool for defining collision areas for said objects would be nice too (althought this’d be more of a CocoStudio feature I guess).

Abstraction is the idea behind V4. Still not into this kind of stuff but they are very high in the required feature set.

  • Access to the interpolation functions that animations/actions use so that we can use them for animating any kind of values and not just limited to the available functions. Some use cases would be, adjusting volume smoothly, use moveTo-like behaviours on sprites that are currently managed by the physics engine, adjusting some global parameters of gameplay as time proggresses, etc.

This is already done. V4 actions act on whatever the object you’d like to. There’s a PropertyAction which does exactly this: https://github.com/hyperandroid/Cocos2d-html5/wiki/Actions#propertyaction

  • A simple method (with good performance) to find out wheter a point in a sprite is transparent or not (for use with mouse clicks/hovers).

This is actually very straightforward. The engines V3 and V4 already can give you a screen point translated into local space coordinates. if you have the mask in an array, a lookup should be trivial. We could add some utility methods, not to the Node implementation, but as a helper to check for this.

  • Adding a 4th state to buttons (they currently support active, disabled and pressed) to handled a “selected/hovered” state. It’s not required for touchscreen apps, but if you want to support keyboards/gamepads and/or mouse, they add a lot to the look and feel of menues.

Already available. And there’s also 9patch support for buttons: https://github.com/hyperandroid/Cocos2d-html5/blob/develop/src/widget/Button.ts#L85

PS: do let us know when there’s a repo that we can look at! :smiley:

have a look at this: early pre-alpha code, currently writing wiki and pushing examples to github pages.

1 Like
#22

The Cocos2d-html5 V4 project, in its current state, is only web targeted, or targeted natively using native standalone wrappers like X-Walk, CocoonJS or Phonegap to name a few.
It is much like the Cocos2d-htm5 lite in V3.
Some features from this V4 project, will make it to the Cocos2d-x project, like the advanced layout capabilities for example.
We expect to have this V4 (as the rest of the Cocos2d suite) community driven so would love to get all the feedback possible in this early stages.

Hope this sheds some light on why V4 as is.

1 Like
#23

I’d personally would think that feature parity with cocos2d-x at a high-level makes sense? I don’t think I’d develop anything more than a prototype or micro games (e.g. for jams) if it’s limited to web browsers, but I may be in the minority. If you’re looking for priority of features then maybe asking for games published using cocos2d-js on the web and figure out what features were used most. As you mention the core features (Scene,Node,Sprite,Actions,Animation,Input,Audio) should probably be mostly working in the first release?

These features, and few more are already available in current V4 project. Where it makes sense, we’ll go with full backwards compatibility as well as introducing new features or API where suitable.
For example, the v4 actions are a full rewrite, but also 100% compatible with V3 (and V2) actions by using a thin compatibility layer on top of v4 code. this is transparent for the v3 user, and the v4 will benefit from a more robust syntax and serialization capabilities for example.

So a roadmap would be excellent to know where things stand, what’s actually functional now, estimated delivery, how you plan to support native platforms, if at all (webview wrapper, JSB, etc).

As is answered to @emmyc, the current V4 is much like V3 lite, which focuses only on web development. It does not mean we are not considering native wrapping, but now we have a different approach. While JSB constrains the web API to that of Cocos2d-x, we plan to introduce advanced features currently not present in cocos2d-x. Native wrappers like cocoonJS, X-Walk or phonegap could bring in all the expected performance.
Some html5 v4 features will make it to cocos2d-x too, so they could be used in V3.
but the current idea behind v4 is freedom, and we can evolve v4 rendering and features much faster than if we have to stick 100% to the cocos2d-x contract.
So currently, V4 is for web, but we expect not in the medium term.

Also are you planning to develop this in public (ie: with associated fork/branch/separate github repo)? Are you pulling ideas from other web engines like Phaser, Construct2, or BabylonJS? I guess I am curious about your target requirements? Is Canvas still supported, or will WebGL can be required? What mobile/tablet/desktop browsers and versions are supported?

Absolutely. This project is open source as all the others. And we expect the community to take active part on it defining the product feature set and why not, the roadmap.
We are currently working on the core functionality, and after GDC we’ll start adding game-engine features, so all requirements other engines already implement are welcome proposals.
About rendering, the idea is to have a plug-able rendering system. Canvas, WebGL and DOM (where makes sense) enabled. By plugable i mean that all the rendering code is decoupled from the nodes, and interfaced to a very high level canvas-and-webgl-shared API.
We are not currently targeting any special requirements, just working in making it super fast if webgl is available ( i consider the bunnymark meaningless though: http://labs.hyperandroid.com/less-bunnymarks-more-features ) . fast does not only mean pushing 50k sprites, but aiding developers in creating new type of nodes by offering a high-level yet powerful drawing API.

The project in its current form can be located here: https://github.com/hyperandroid/Cocos2d-html5

all types of feedback are welcome.

2 Likes
#24

Nice! Can I dream about having rich-type formatted text of some form? :smiley: (hypertext, markdown, anything along those lines would be awesome, even if only for bold and italics).

I know there are a few libraries that do svg to canvas rendering. What I thought that would be “simplest and most performant” for our case is that maybe we could have a kind of sprite with an image buffer, we draw the svg once there, and use it around as a raster image with approppiate resolution.

:smiley:

I love you (platonically).

Hm, the only method I’ve found is quite cumbersome and time consuming, it’s discussed in this thread: How to get single pixel of Sprite with cocos2dJS and CocosBuilder?

Awesome.

I’ll keep my eyes on it! I’m most lacking free time lately, but I’ll be sure to contribute if I can :smile:

Thanks a lot! Keep us posted!

Edit/Extra:

  • The readme says “Typescript The engine is originally written in Typescript, and later transpiled into JavaScript.”, is there any advantage in particular behind this? The end users of the engine (game developers) will just download the JS source, right? I’m guessing the TS source will also be available in case one would like to use that instead?
  • You talked about rendering methods in another comment, is the idea that all graphic features will work independently of the rendering used? (there are currently a couple of things that only work in webGL mode, but canvas has much better performance wherever I’ve tested it, so that’s bothersome).
  • I’ve seen many people struggling with handling screen rotation, we currently have to choose wheter we want our game to be portrait or landscape, but it’d be nice if there was a way to easily make a switch so that the game could be played with the UI adjusting properly whenever you rotate the screen (not sure if this isn’t simplified already in v3, though, I haven’t checked in a while, sorry).