C2 has never 'let' local access to C2 games. Though there are ways around that it's not an 'anymore' thing. C2 has always been designed that you run the game from some for hosting app. So NW.js for exe based operations. Otherwise you can use FireFox I believe that's lenient. Or back to running from a webhost as gumshoe2029 mentions.

Programming = Placing instructional set's in order to achieve desired results

Coding = Typing with text editor to do programming.

Also. yeah. I agree. C2 should be tought in schools. I ended up giving a one week 3/hr a day course at our central Vancouver Public Library. Was pretty awesome. The young teens picked up C2 very well. I'm not sure if my company ever posted the games though. https://vpl.bibliocommons.com/events/55 ... 00500010e8

So yes there is programming, but it's near as simple as I can imagine

It's best not to rely on on performance being better than export. Do an export and then test out the game. Don't rely on browser preview on a device if that's not your games model for distribution. I have heard a number of cases where performance is improved, but relying on that chance is very risky.

1. Scenegraph design would be far better than image points. So I agree. If we can't have scene graph then IP sub folders would be helpful.

3. Is this for types of objects? or how objects are structured in a scene?

a) If it's for types of objects then it's already handled.

b) If it's scene structure. If the system was just already a scenegraph design this would also be handled. Since we don't have that. Then yeah I can see this be helpful.

c) from your sample image, your shooting your self in the foot in regards to C2 sprite management. You should pack your images in to related and/or layer elements of sprites. Then cycle through the animation and/or the index. Each individual Sprite Object becomes it's own texture. Each texture needs swapping in and out of the GPU texture memory. This can increase your drawcalls by massive amounts by making every image type it's own Sprite Object.

4. I don't understand your question? Flexible data type?

It's always better to use casted data types rather than mutable data types. numbers should always be numbers. However what I would LOVE would be to embed more complicated data objects onto a object. As an example

Current variables for objects

[Number, Text, Bool]

Wanted variables for objects

[Number, Text, Bool, Dictionary, Hash List, Array, Custom]

This would be far better than making a container of an objects and linking a Dictionary/Array into the Container.

Try listening for keyboard key ESCAPE. This may or may not work. But I know the keyboard equivalent is that key.

jobel

Many of us long term developers do indeed use a dummy layout. Only primary level objects are ever kept on the layout of use. If there is any possibility an object is NOT going to be used on every layout. Then just use a dummy. This tip always comes up whenever a "Best Practices" thread comes up.

jsj

Since your just testing. May I suggest just overwriting the validity check for is supported. I wouldn't do this in the long run. I would also suggest just console.log() each of the checks in the return line. Just to see which one is failing the whole line.

But for starters just force

C2Multiplayer_IsSupported

{

console.log("RTC Peer: " + RTCPeerConnection );

console.log("ArrayBuffer: " + ArrayBuffer !== "undefined" );

console.log("DataView is defined:" + typeof DataView !== "undefined" );

// return RTCPeerConnection && ArrayBugger !== "undefined" && typeof DataView !== "undefined";

return true;

}

ArrayBuffer does exist

https://developer.mozilla.org/en-US/doc ... rrayBuffer

DataView seems to exist too

https://developer.mozilla.org/en-US/doc ... s/DataView

My Guess is the RTCPeer library isn't accessible when it's wanted.

I would treat blue prints similar to how I would treat the EventSheet in C2. Use the BP as the model of interacting with different objects, not to use BP as new features. If the program needs some heavy duty processing get a Plugin or write the feature in C++. Try to keep BP as logic triggers and not heavy data processing.

I'm sharing the same sentiment as others. I love C2, but for me the workflow tools are falling behind standards. And often I can't "sell" C2 as a viable project tool because of solitary design concept that runs C2(I know C2 works with CVS, but no where near the level Unity, Unreal, Havok...) and exports.

I still prototype in C2 and make games in C2, but anything more complex than the basics is done elsewhere. And I agree with Shinkan here. Unreal has a heavier IDE to learn, but once you do it is the most similar to C2(abstractly). Except you get a SceneGraph hierarchy of objects and that makes a world of difference.

tgeorgemihai

Go for it. I don't think you will regret it. Though Unreal is also pretty good and although a larger hurdle than C2 and Unity reflects C2 a little more.

Set sails to new shores and exciting adventures. And welcome to the Unity developers ship maybe I will see you on the Unity developers forum.

part12studios

Personally I think the idea is good, and I have suggested that Cordova export be directly integrated into C2. The shot down reasoning is that this would require the developer(us) to download the JDK, ADK and I believe the NDK. In C2 we would then need to reference these folders for the build process.

My take is that this build process could be easier than working through Intel XDK. Also doing Cordova directly would open up development options in C2/3 and just overall make mobile app development easier. Yes developers would need to download 2/3 different sdks, but I think the trade off is worth it. It's also not uncommon in the mid level and high level tools. If C2 handles the settings options well the process would be very simple.

Always try to minimize the number of object types. Do not create different bullet objects.

So go with A

1 Bullet Object and adjust properties.

It's interesting the number of threads that turn into exporters because of performance X reason. Personally I think the big weakness is that C2 isn't friendly for complicated game development. Object structures, team asset management, lack of modularity, lack of Object>Sheets so on etc are so problematic. Personally and this is just an opinion if these problems were fixed

Object Structure = Scene Hierarchy with Object Pattern(ie part of scene graph of objects are saved as it's own object, similar to container, but more flexible)

Team Asset Management = art, audio files should automatically sync when updated with the requirement of manual updating to associated links.

Modularity = better re-use of code chunks.

OOP = More logistical design for creating a game that offers better more friendly development patterns to non experienced programmers. There is a reason why OOP is more common than Imperative programming. It's easier to understand, read, write and control in development software.

Better Plugin control = Moduals and plugins should be per project and stored in the project folder. So that when working in a team the plugins and modules are already ready to go.

Sprite Object replaced with SpriteBehavior that uses controlled texture atlas. This would increase performance, reduce memory, and solve poorly made projects. This also means that SpriteAnimator should also be a beahviour so that SpriteRendering and Sprite Animations are not linked.

If these problems and I did say problems were dealt with. I don't think there would be such a cry for native exporters. I feel confident that the average performance of games would significantly increase. But this is all speculation.

Lack of performance is a symptom, not the cause.