jayderyu's Forum Posts

  • 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.

  • Wait( 0 ) is good to use as an Event Sheet LateUpdate. An update that occurs after everything else in EventSheet and Plugins, yet also triggers before the next tick. It's actually very helpful in a few instances as it's one of the few techniques that allows some measure of finite control. However it is a problem due to how it works. Personally the only time to use wait are for automated sequences. if at any point there is a possibility of interuption or reset, then wait will hurt. It's best to use Timer.

    I'm not sure about the top level reference either. Are we talking about UI or are we talking about how all programming is in C2 is Functional and not say Object Orientated, which would be I suppose downward up.

    -------------------------

    Replied before I sents.

    Wait doesn't hold the program. Wait encapsulates the current set of information and starts a JS Timer to execute after the given period of time. However once doing so obliviously moves that piece of code out of our control.

  • Yeah. other systems support object property ScaleX AND ScaleY. Rather that just offer a ScaleBoth function. this would be a very good feature to have.

  • > uScript is a nice VPL component linking software of apis. however you will end up needing code yourself for features that don't exist. I would suggest PlayMaker which is meant to be more a programming replacement.

    >

    > So UScript is about linking api's

    > Playmaker is similar to EventSheet programming( in a an abstract purpose sense)

    >

    playmaker is good but uscript is more like c2 event sheet and more powerfull and no need for coding at all !

    it even use reflection to get all unity things ! (functions,properties,...)

    and you can make new features with graphs and use all of that as one graph !

    c2 have little programing like expressions but uscript is just graphs

    Well I haven't used uScript for about 2 years. last I used it. uScript relied Reflection of existing code, and couldn't do much with out . So if you needed specific movement, you still needed to code that motion.

  • Button is a DOM object, and you can't be guaranteed the appearance between browser's. Some browsers may have different CSS objectives for their visual look.

    Sprite as a Button is traditional game programming and will always be the same among all browsers.

    If your doing the UI for a game. Use Sprite. If your doing an APP use DOM/Button. You should use DOM objects sparingly in a game if you do. If your doing some kind of web game where canvas is segregated from game play. then you could do a UI borders and embed them in a div.

    Also DOM is another layer. So every DOM object requires a DOM/DIV layer rendered in between canvas renderings. On Some browsers this can slow your games performance.

  • uScript is a nice VPL component linking software of apis. however you will end up needing code yourself for features that don't exist. I would suggest PlayMaker which is meant to be more a programming replacement.

    So UScript is about linking api's

    Playmaker is similar to EventSheet programming( in a an abstract purpose sense)

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I agree some kind of icon would be best. My method of division is that my LAYOUT are all in capitals and my eventsheets are in lower case. I tried cAmel case too. but didn't feel as satisfying. What ever you choose in the meant time, it should be distinct.

    ePlayer

    lMainMenu