Yep. I think this get's requested every month.

Nope, no substitute that isn't ugly.

That's very unfortunate you had a development disaster. I've had them myself. All I can suggest is that you pass your experience on to others.

Assist starting devs by suggesting to start with simple projects to learn and reading blogs/tutorials that focus expectations. The number of people jumping into the deep end are staggering. Then when their mobile network games doesn't work it's the engines fault.

Back and version control is essential with any big project.(i've had my life saved a few times because we used bitbucket)

I think C3 threads do not need to be created. Nor does Ashley need to start a "What should be in a C3" thread. Instead Ashley, big plugin developers and developers who use other systems should be involved in a discussion. Not to talk about what features such as plugins, but instead discuss the lowest technical requirements to offer the most flexibility. That way by a good foundation all requests can be developed rather than waiting for C4.

There are a lowt of newish users in this thread. But as an FYI C1/CC was a school effort with a group of students. C2 however is a work done by Ashley as a company with a clear direction. C3 will maintain C2 same direction and thus build on top of how things work and the gritty core. Likely C2 projects will be loadable by C3. So no. It's not fair to say that Scirra will just cut C2. That shows a lack of knowledge about Scirra.

So let the C3 threads end for now as a lot of these will just confuse new users and muddle the waters

2014 was the last of any meaningful advancement of C2. At this point C2 can only improve the current set and offer a few new plugins. C2 is hitting the peak of of features. Once that peak is crested then all that's left is stagnation and then at the end of 2015 there will be a large number of complaints wonder where the meaningful changes are. If the entire Contstruct line is to continue to have effective growth, penetration and meaningful features, C3 is the way to go.

C3 is mostly an IDE overhaul not an engine overhaul. I think a lot of people are mistaking the move to C3 as CC to C2. That's not the case. C3 will still be running the C2 game engine. Will end up using the same C2 plugins. However with the new IDE, structure and so on. New meaninful features can be added. Such as way points, editable bounding boxes, custom windows for plugins, Timeline animation, prefabs, scenegraphs so on. Not saying all done by Ashley, but features can be done by others.

Who knows, maybe C3 will offer an update price as an early adoption from C2 to C3.

I've also had some similar thoughts about doing Object methods. However my thought is to create a behaviour that allows custom javascript, and then passing the core object into the script. I was originally thinking of using Eval, then found out Eval is super slow due to not ever recieving JIT run time compilation. So I'm thinking of looking into a way to get the code into the JIT sooner than later.

It's not the same your request. but good luck. I would like to see self inference object functions. What would be awesomer would also be Object Triggers linked to to Events... drool

And to be fair in optimization. He has made a new blog going into understanding some of the micro optimizations. Such as batching sprite images to single sprites based on layers and a few others. however they aren't in the blog post posted for "Don't waste your time".

Objects not on the screen may no be rendered, but that does not exclude them from logic processing. If you have logic happening on objects all the time, even off screen objects will still be handled in that process.

If you feel it's off screen objects. Then only handle objects when they are on the screen.

wow

how about grouping your events. That way you can get more of a break down than just the event sheets. There is no way to help without more information. Group group group. Not for just visual organization, but also profiling.

I can't help but think you have some kind of heavy recursive looped function call happening.

locohost

I requested object oriented methods 2 years ago. Ashley isn't convinced yet that doing so is worth while. Me I believe that object methods would improve coding efficiency and reduce poor event coding. Which is my main request why. However that's not enough.

And I also suggest the blog post should be taken with a grain of salt. I know of a game where the basic optimizations Ashley listed just didn't cut it. However when we went into micro optimization for mobile. The 5fps mobile game jumped up to 60 after a month of micro optimization. Then there was a discussion of why Spaceblaster runs descently on mobile where as newb game X does not. Ashley went on to list numerous micro optimizations based on knowing how canvas and webgl render. And yet there are claims to not to bother to micro optimize.

I see this form of request list come up a lot lately. and my part of the list is always the same. Many of the best requests are impossible under C2 IDE. If you want these fantastic requests ever see the light of day. The small requests need to stop coming in and everyone voice their desire for C3. So saying so. let me add my spin on a few of these.

ThunderZ

1. Can't happen. I love this feature two. however there are two parts holding this back.

a. The game engine doesn't support scene graphing which is more ideal to grouping animations to a time line. My suggestion. Container to be trashed and instead implement scene graphs and pre fabricated objects.

b. IDE is holding back any serously good custom new stuff. We need C3 to move on for your 1 request.

+1 for my vote

2. What your asking for is a SceneGraph. I've made an official request for this 2 years ago. and I bring in this request often with these request lists. Part of this limitation could be the IDE just lacks the ability to be a capable tool to allow for this kind of jointing of objects in the IDE tools. C3 has a better opportunity to see this even be remotly implemented.

+1 for my vote

3. Requested by me again maybe others too. Can't be done with the current IDE. need to wait for C3.

+1 for my vote

4. mostly Pass. 2016 should be the complete lack of requiring a native export. however if you need access to low level system functions. cordova opens that door. PhoneGap/Crosswalk/CJS all support cordova.

TiAm

1. That would be nice

+1

2. I wrote a pathing system. I wanted to advance the system by using bezier curves. When I moved my capx code to the plugin. I found that I couldn't create widgets. So While I could create a curve. these curves would need ot be imported or guess or tested at run time. For this tool to be properly requires widget and gizmo capabilities of the IDE tools. Which can't be done until C3.

+1

4. Paster/Canvas needs to some polishing up. I've seen a few wierd beahviours. but It does seem to be a basic concept plugin. There is at least R0j0 plugin.

5. I looked at chipmunk. Nice. It's my goto physics for c2 and js. Not good for bullets and no effective rest state, but even without a rest state I had about 1/3 performance improvement I'm like r0j0 work on chipmunk

6. I agree. physics should be improved. Poly collision is expensive. There should be circular and rectangle collision checks. In fact Rect/circle should be default.

+1

michael

i agree that C3 should be started. but C3 is still going to be a js engiine. So it's still going to be browser based. however part of the issues that people have is that the C2 developement architecture requires more discipline for mobile performance than traditional programming or other tools. c2 is the easiering and more natural development style results in terrible mobile performance. However with diligence mobile performance is excellent.

instead C3 should be started, but with re-designing the parts that c2 has problems with. otherwise I also agree that C2 due to it's limited IDE architecture is hitting the end of the road.

PSI

unfortunately all the big stuff, modularity, reloading plugin, IDe store, Scenegraphs, widgets and gizmos and all juicy goodness that all the other tools can do, are not doable in C2 and never will be.

Sorry, but the only life C2 will see is maintaining it's current flow of small improvements. Nothing big that will really push the tool to forward can be done.

As for my self.

Scenegraphs

Modularity

Edit Time access for input and behaviour drawing. That way we can make widget and gizmo's

Edit Time custom windows frame

Simpler Plugin/beahviour design that uses reflection

IDE access to the store

plugin development reloading(ie don't have to re-start c2)

Editime variable setting from widget settings

SDk that goes into guts of C2.

C2 Engine SDK(we have the plugin SDK). The engine SDK would go into features such as getting access to other plugins, behaviours and being able to use them. being able to influence the timer and stuff.

The only time I "hate" parts of C2 are when I hit engine design choices. Yeah some times I feel something is missing or should be handled differernly. Most of the time I just code around those issues.

however sometimes there is IDE design limitations or engine issues that I can't avoid.

Such as

No extensible IDE. I cannot draw gui widgets on the editor. Many other tools let you do this.

No image atlas. I personally believe that binding the imags to the sprite is the wrong design. Instead images should be atlas by the developer and sprites then reference images in the sheet/atlsas.

Cannot unload objects. Without this developers cannot create vast streaming worlds.

There is no modularity. it's annoying to pop in designed works. I need to duplicate the objects before copy/pasting an event sheet. currently I just have a master game frame work that does a lot of the gui work done.

Plugin Reload. Would be nice if plugins after editing the edit time version of a plugin. that the change can be reloaded without closing the entire system.

Can't draw from a behavior. I tried to making a behavior related to path finding. Thought I could draw a bezier curve line from behavior. but you can't draw from a behavior.

Plugin ACE design is bulky.

There is more, but no point going on.

The way I put it

Game Logic issues. No i have no problem. What C2 doesn't have I can do myself.

Engine related issues. Makes we want to just use Unity, UDk or Anarchy. I don't because C2 library of plugins is astounding for a 2d engine.

However because of these engine related issues and the development choices of locking developers out of the nitty gritty. I have never been able to convince my company that C2 is a viable engine for 2d games.

This problem is a result in relying on the browsers dt rather than lerping a dt value based on the system clock. Also you create variable dt or fixed variable dt to cope with these issues. C2 however only relies on the browser dt rather than handling it itself.

So there are fixes out there, but we don't have' the ability to set the time step dt.....

that would be nice actually. being able to have a dt script line where we write our own js snippet that sets the dt our own way. That would be a fantastic technical feature.

newt

The subject may get skewed to the lack of technical knowledge. However the focus is Unload Plugin Object. Remove every instance, remove the object from the pool, remove all memory associated. Such as all the variables, texture and audio files while only keeping constructors for future use.

This is not about unloading a single part of a of a texture sheet, but the entire texture sheet. Good memory management usually means that textures are packed into themes. Such as snow theme, grassy, roads, houses. If all the images of a theme are packed to a single Sprite plugin. Then once you leave the Arabian city far enough, just unload the sprites that store the Arabian city and various other Arabian city themes objects.

So if the developer is making a vast world where players can explore pole to pole each visual thematic area would be composed of a Sprite Object for each visual type of an area.

Area Vegetation

Area Animals

Area People

Area Buildings

Area City Stuff(fountains, benches, lamps, signs....)

Area Paths(roads, paths...)

Unloading a piece of a texture would serve no purpose. even if that happened the sheet itself would still be composed of X by Y size.

However the catch and I understand this from Ashley's point of of view. This requires more understanding and technical knowledge. And we know what happens when more technical aspects are implement. There is a big rush to use, only to find out that such a feature is for expert use and not beginner.

However I do feel that such features should be there to use, with warning that it's not for beginners. C2 is a fantastic community with an incredible amount of helpful people.