Just wanted to chime in on a couple of these to put them in perspective; and not so much to refute them.

Like others said, a simple Crappy Fird clone takes 30MB and uses 20~40% CPU and still has some frame drops... Angry Bots (default demo of Unity) takes 38MB, uses around the same % of CPU, no frame drops.

Unity has a 10mb over at the core. Which is about 7mb less than Crosswalk. Unfortunately there does seem to be some unwanted overheard on the browser aspects. I keep on saying it. But I truly believe Scirra should take Chrome xyz. And customize a version of that. Remove the DOM as a priority.

Eli0s's Fancy Benchmark runs at 6~9 fps CPU 25~40% in Chrome, 8~9fps CPU 70~90% in FireFox on my Samsung Galaxy S4 while Epic Citadel runs at constant 60fps on default and 30~55fps at Ultra High Quality (rendered at 1080p), and Angry Bots mentioned above...

So yeah, "HTML5 has close to native performance" / sarcasm

Fancy benchmark is nice. But in refer to my comment above. Scirra should just use a stripped verion of Chrome. that would solve a lot of the overhead issues.

Epic Citadel is gorgeous. However please note that 99% of Epic Citadel is

• static environments,
• quadtree collision detection,
• binary spacial tree drawing determination.

in comparison

• C2 poor performances demos are batches of moving objects. Check out Goo Create for a proper 3D static environment comparison
• C2 uses Cell collision detection. however don't let the name fool you. It's still brute force collision detection with in the cells.
• C2 probably uses the Cell's to determine drawing or does brute force.

This all comes down to NOT HTML5 or the browser, but just not well optimized critical performance pipeline of C2 engine. Which I have been requesting overhauls for 3 years now. It's why I requested focus on core malleable World Object with dynamic attached behaviours rather than C2 rigid Plugin system. This would allow for more flexibility to overhaull the choking points in C2.

Maybe the CPU part is close to native, but the graphics part is not even close. I've stressed my device to test Epic Citadel and Angry Bots at a lower framerate, and guess what, at 15~20fps they still look more fluid, with no stutter then C2 at 45~50fps

I have a Unity game on mobile where the start runs at 15 to 20fps to start on 2 year old devices. Unfortunately that's unoptimized due to time constraints. The game is very flappy birds like. 1 character moving to a tap. Though we 3 more animations on the screen.

I helped one of the forum members get his 5fps game that would crash on mobile. To 60fps and memory effecient on the same mobile fps under CrossWalk. Use the info however you want.

eh. I'll expland

Scirra promotes a no need to optimize and no need to micro optimize. This however is untrue. Not only should you mirco optimize, you should also be wary of C2 own Plugins. Some of C2 plugins will in fact hit your performance hard in ways you wouldn't think so. However if you take up good game design on your efforts, micro optimize, careful use of plugins, replace plugins in some cases. You can get descent running games on mobile.

1. Sort you images into types and layers.

You need to take advantage of C2 quircky texture packing to maximize the WebGL renderer. You won't notice this an issue with small games. You will on bigger ones.

• All ui images are in one sprite.
• all platform images are in one sprite.

so on etc.

2. Each Sprite Object is it's own texture pack

Right from the get go this relates to 1. Each Sprite object will pack have it's own images packed into it's own sprite sheet. So if you repeat images in 2 different sprites. Then those images will be repeated in more than 1 sprite sheet. So do number 1 is mandatory.

3. Behaviours carry performance weight.

Don't attach plugins willy nilly like theirs no tomorrow. A simple Plugin such as Pin. Has curve based performance reduction. It's strange to think that Pin which figures an XY value hits performances. but it does. A few objects with pin is fine. a few hundred objects with Pin, and then you will start to notice.

4. Some behaviours are just slow.

I will use this one as an example. I wanted a rotating background in my game. So I made a 2048 by 2048 image. The game currently ran at 60fps with the background not rotating. As soon as I added Rotate Behaviour the performance dropped to 8fps. whoaawhh

I switched to rotation in the EventSheet and that jumped performance to 30fps.

I then rotated in the EventSheet every other tick(ie updating the image rotation at 30fps) and the game ran at a buttery smooth 60fps. And there was no visual difference.

Lesson. Don't use Rotate Behaviour. I don't know why. I looked at the code. Doesn't seem like anything would hit performance. But eh.

oh the game was running on a 6 year old Tegra 2a Tablet. So we are talking pretty old in comparison theses days.

I had a link to a C2 game. The developer was showing a video of his main menu. Which was an orbital space system. Where clicking on an area woudl scroll the rotating systems to another set of rotating systems. The planets, moons and start acted as the button interface. This ran at 60fps on a 1core chip with 512 mb. Was buttery smooth, supported 3 level deep parallax layering.

However I will be brutally honest. Due to Scirra not having a lot of value in micro optimization. this put's far more responsibility on the C2 developers. And new C2 developers just can't cope with the heavy rigid performance design. Most just come in and start making a game. Then use C2 in the most intuitive manner possible, because it's so easy. Then find doing so causes extremely bad performance. The few who I have encouraged rigid discipline and listed tend not to have much in the way of performance issues.

ROFL

I'm with newt. I feel C2 would benefit with everything being a Behaviour. With each Behaviour being individually attached to any WorldObject .

Then use some kind of CreateCopy( UID ) as the method for creating new ones.

Tokinsom is talking the object 0. When you use SpawnObject or Create object. C2 creates the object based off of a template version of the object. However as I understand(this could be off) the creation process. Is that the first object defined in the first Layout of that object becomes the template object.

The first solution is that anything you use create on. Should only be on some form of Assets Layout. However there is a problem.

Let's give an example.

1. I have a Assets layout where I create the first ever version of the object. We call this Object[0].

2. However I end up using Object[1] in the main menu, but I end up doing some customizations

3. I create Object[.....] during game play

from a development point of view. Object[0] is my template Object that set's the standard for the create and forget. However there is a problem. Because Object[1] is custom and is the first create one through used alyouts. My game layouts will use Object[1] even though I want Object[0] as my default.

Tokinsom is suggesting that there be a toggle field as part of the info where they can be just set as a Default. So that the confusion of Create precedence is not an issue.

My suggestion is to copy Unit's Prefab system. Where Objects are popped into a Prefab dedicated folder. This way Prefabs are always default. Another suggestion would be to create instead a Prefab Layout. So that Any objects on this Layout take precedence of creation settings.

Honestly. I see similar threads in the Unity forums.

Platform X is missing B

Platform Y is too slow

Platform Z bleah

I just participate in these ones

This would require a larger team. This is one of those matters where the benefits have to out weigh the negatives. For a 1 developer team. Not going to happen. However if Scirra was a 20 developer team, and the cost benefits to develop an abstraction layer, then a per platform player. Then Scirra would revist the idea. However at this time. it's not practical for such a small team.

Want to see this happen. Release some massive games that are bringing in millions of dollars. This would bring the larger and dedicated companies With such a flow of developers and income flow. Then we would see the possibility of a player. until then. not happening.

Exports are based on technoligical allowences of the platform.

PS4, Sony has shown as far as I know any interest yet in Borwser Apps with a robust enough browser base(I could be wrong)

XBOne, MS has interest in a universal app. This seems that at some point Construct games will go to XBoxOne platform.

Ouya,you can use CocoonJS or Intel XDK. I think even down the road there might be support for webapps. But more proof of webapps on the Ouya will help convince them to implement Lolipop webapps.

Just as an observation. The image in the post of the NX is likely a photo shop speculation drawing. More than likely it's reference to the GameCube(Dolphin) prototype. Check out the tech specs, they are in line with the GameCube. The image was used probably just for the purpose showing Nintendo working on their next gen rather than actual development.

I don't know, but based on performance results I'm leaning towards calculated every time.

C3 isn't C2+, C3 is the IDE built from scratch and redesigning a lot of the core interaction for how development is handled. I wouldn't expect anything in any form of news for another 5 months. Then we will start hearing about some of the concepts.

Ashley mentioned that C3 was going to be in silence for some time, and C2 features and updates will slow down. After seeing C2 r200, I certainly believe that moving to C3 now was a good choice.

If C3 core design is handled right and flexible at the core. Then C4, C5 won't have long silent points. It's just that the C2 IDE which was built by another party is just very limiting.

locohost

Construct is about the visual event sheets. Construct will never support text development on any serious level as part of main development. If your looking for text coding development I think Unity, UDK, Havok are much better choices.

The term programmer is not definitive as writing lines of text coding. Programming comes in many forms including visual programming such as PLC ladder logic. Unfortunately many programmers tend to think programming as soley the domain of text coding. Which is not the case.

Yes you are a programming and the only language you know is Construct 2 Visual Programming Language or C2ESVPL or I like C2ES.

As others have said though. Game developer would would serve you as a better term when talking about it with most other programmers.