jayderyu's Forum Posts

  • Same way you would check use any SOL. Do a condition check first to compare info that builds a 1 object SOL.

    https://www.scirra.com/manual/29/object-type

    Often I find for comparing players. Is to just create an instance variable in the player objects. and then object.playerName == [playerName]

    If you deciding to use different Objects such as duplicated rather than Copy/Paste instances. Then put them both into a family, and make the comparison in the family.

  • I'm not a big fan of Spine, but I want to say this as encouragement to the Plugin developer.

    Your implementation though still short on features comparably. Is a far better implementation model than Spriter. Spriter import sucks. Each object entity require it's own Sprite object. Where as Spine plugin does it the right way. Just one texture sheet. Also this means that the Spine object is only 1 object. It's just so much better. I think with a few more features for image swapping, I will convert to Spine. The plugin is just far better in design.

    Kudo's.

  • Rather than starting yet another thread on this request. I'm just going to post this request again in the same thread.

    I'm working on a game with a group of people. We are using Spriter for our character animation. Our character has about 20 objects. Now in disgusting method that Spriter characters are imported. This leads to 20 sprites being created just for this character. ok moving to the next important step.

    We have enviromental and object sprites. These are Sprites(not spriter objects). Our game require sort by Y/zindex. Now the easiest method to sort the objects we want to sort is to

    FamilyZSort is On Screen

    -- For Each FamilyZSort ordered by FamilyZSort.Y ascending

    ---- FamilyZSort Move To bottom of Layer

    so now all our sprites sort each other no problem..... except there is a problem. Spriter can't be put into the FamilyZSort because of the lack of mixed families. So our Spriter Character cannot be sorted as part of the algorithm. Ok, what if I put my Spriter Sprites into the family... Well besides the disgusting amount of Sprites on how Spriter imports, and the fact that there are enemies, bots and other Spriter Objects that will blow up to a few hundred distinct sprites.. This method unfrotunaly messes up Spriters layering now. So it's not a solution.

    There are two solutions.

    1. Allow Mixed families

    2. Add a new action. Object.SetZIndex( int )

    I love C2 so much, but some times I come across these brain smashing issues that can't be fixed effectively from the developer side.

  • Yes I've heard of it. No. It's the same issue as always.

    It's not that C2 JS can't be ported to other languages.

    It's that C2 JS relies on too much Browser specification API's. As long as C2 relies on the Browser APi, then C2 is depended on Browser. So for some one to make a Xamarin port, would require that person to port the Browser api's to Xamarin.

    If C2 JS used it's own API layer, then a it would be easier to make shims to other platforms.

    Really, lack of floating dual analog touch controls. My work has Unity licenses($70/month) and Unity has a buy price of $1500. There are no built in touch dual analog touch controls. I'm done with this thread.

    C2 is not a Toy, however I often feel straight jacketed. I often feel how C2 was put together was an after thought. I've spent hours digging through C2runtime.js to figure out how things work(and I only know a little bit). I can honestly say that the basic design scope at a root level is not as good as it can be. And the way C2 is designed there is just no way that "Toy" to Tool can be accomplished without breaking huge amounts of work.

    Just four examples of design factors that A drive me nuts, and B drive down productivity.

    1. World Objects are Plugins. This is wrong in a good design. There should only be 1 WorldObject.

    2. World Objects should naturally be scene graphed.

    3. Behaviours should be everything. Image drawer, animation controller, TextFonts... so on etc.

    4. The SDK is bulky and straight jacketed. It's not really a very stream lined Plugin system. I've never worked with a Plugin system that was so heavy.

    Those are HUGE development downers, and they drive me nuts. Because they require MORE work to do in the basics of C2 than say Unity, Anarchy, Unreal, jMonkey..... I can't speak for Styncil, GameSalad.

    And then there is the implementations that just don't quit make the par. When I joined C2 collision was ONLY brute force.... huh? really?. Eventually we got collision cells, however there has been and was a call for quadtree collision. But spactial partition tree wasn't developed, it was just a brute force system, but worked in a grid area. There signs of these half measures all over the place.

    Of course do your own Plugin/Behaviour. But let's take a look at collision. Let's say I make a Collision system based on QuadTree. Great. However Sprite, Solid... everything already uses the internal Collision system. So I need to turn that off in the options. Ok. So let's add Plaformer. Platformer is creme de la creme of Plugins. However guess what. Platformer can't work with my QuadTree. So now that iv'e turned off internal collision. Platformer is useless. So now I have write an entirely new Platformer behaviour. Now you kind of see where this is going.

    If a core feature isn't done efficiently or flexible, then you notice it big time. It starts working against development. Then there is Pin vs a SceneGraph... so on etc. Function isn't part of the core engine, it's also a Plugin... wtf? There are a lot of features that we use, but just feel short of being a full tool.

    However even though I have parts that drive me nuts, and I do work with Unity(at work). Most of my personal game projects are still C2. It's faster, there are less errors, the game api is the best I have ever seen(even flawed). It's the cheapest game tool ever for what it provides, and is still fantastic.

    My only suggestion would be that for Ashley get the community involved in any new feature. Not just a call for a feature to exist. but a break down on how developers want to interact with the feature. What they want the feature to be flexible enough to do. A well structured feature that has community involvement, rather than the tool developer making the call how it works, and it's limitations.

    As for storage. I've said this again and again. Do storage like any professional does it. It's easy, solves problems.

    Use Local Storage and a Dictionary

    saving data

    1. store values in dictionary

    2. save dictionary JSON to local storage

    loading data

    1. load json stored string from local storage

    2. put json string into dictionary

    using data

    store and use data in the dictionary.

    this is how professional development uses data. Takes advantage of asynchronous save/load, but the immediate benefit of using data. This isn't rocket science people.

  • I've tried to push this for a few years, but have been able to convince Ashley the benefit of self inferred object design. I know that this design would improve good development practices. Reduce terrible performance overhead. Also would remove elements of the SOL system and just plain make development easier. But I just haven't put forth a compelling argument over the function( object ) of the C style programming. Not even C++, but C.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • DogexOff, MadSpy is correct. So I won't go on more detail on his work.

    I will however mention that it's poor design that your checking every tick for Lives==0. You should check if Lives == 0 only when you lose the life in the first place.

    I suggest

    On ObjectFoo Collides with character

    -- character.life subtract 1

    -- If character.life == 0

    ---- character.setVisible(invisible)

    ---- wait x

    ---- character.setVisible(visible)

  • This game looks fairly simple in C2 for the parts that are C2. The game is mostly a standard browser data driven game. With only a part that has anykind of interaction. I don't think this has much of any heavy weight in design. The "hardest" part is communicating between the CSS/DOM objects and the C2 engine. Again fairly simple with a custom plugin, maybe one already exists in the 3rd party area.

    However 2/3 of this game is DOM driven and not Canvas driven. C2 is a Canvas engine. So you will be doing a lot of work on the non c2 side.

  • If you need a new feature in C2. Make or use a plugin. Do not use the event sheet to handle that. Try to only use the ES as interaction events between Plugins.

  • LIke many others I will express similar positive sentiments. — the line you reference isn't "won't program" it's, "not write a line of code". Your still programming. Your stilling learning logic flow of programming. You still will program. However since you have access to a nice visual level system, nice method of visual programming. You will find learning to program for games much easier. I had a workshop to teach youth how to create a game. C2 was fantastic for this. They learned about game programming, and were able to put together a game in apx 8hrs of free time over a week.

  • I say go for it. I was checking out the source code for iosrtc, and comparing c2mp-peer.js use of WebRTC function calls, and it does look like a number of them already exist. I didn't find any missing functions, but I didn't go over everything with a fine tooth comb either. I say give it a try and find a way to constantly check for errors. Send out a lot of console logs and watch xcode's debugging. See if and where it fails. But I think iosrtc looks viable.

  • CocoonJS does not support many features that the entire C2 relies on. CJS does support a lot of the core game elements. Unfortunatly WebRTC and advanced WebAudio are not in that list. Though CJS does support audio their own audio system to at least have good sound to an extent.

    The best way to get WebRTC is to find the closest to the WebRTC api standard. there are a few, but I think this one might be the closest.

    https://github.com/eface2face/cordova-plugin-iosrtc

    Create a plugin that shims( https://en.wikipedia.org/wiki/Shim_(computing) ) C2 use of the webrtc of a browser, to the cordova plugin. The shim puts all the missing functions and references and makes links to the cordova plugin. If the plugin and shim supports all the same functions as what C2 uses. Then you should have WebRTC on IOS.

    It's not impossible. It's not even extremely hard. Shims are easy to create. But it is a level of technical knowledge required to use Cordova, some swift, C2 Plugin SDK, and javascript. So it's not a drop and use feature with IOS right now. <img src="{SMILIES_PATH}/icon_e_sad.gif" alt=":(" title="Sad">

  • That's not a bad idea. However the large appeal for C2 isn't just the CAPX, or the IDE. It's that the C2 has a very robust Game Library. In fact the C2Lib for games far exceeds what you get with Unity. Realistically i could sit down and take the XML files and use that build scenes/packages/objects in Unity. I could also translate the EventSheet into it's own classes. But again where we leave off is the library. Platform, Solid, Physics...

    If I were to address C2 Plugins. Should I go and translate Sprite to SpriteRenderer? Do I move the Animations to Mecanim? Do I instead try to shim HTML5 JS into C# or do we just shim the basic controls. Done by manually mapping functions over the Unity. Once in Unity the project loses the benefit of the Event Sheet and the link to C2. So any changes done in Unity can't go back to C2.

    If you can find an elegant solution to C2 library with 100% support of C2 vanilla library. I would certainly look into paying.

    To be honest in all of this. I think relying on HTML5 JS reference was a bad design plan. An engine like C2 would have been better off using their own abstract class. That way there is minimum reliance on the Browser technologies. And that's where this will ends up. C2 is chained to the browser for full features.

    However I offer good luck.... and my money if you succeed

  • It's going to be more complicated to get the MP plugin working on IOS than Android.

    There is a Cordova/PhoneGap plugin for WebRTC that should be just WebRTC. You will need that plugin for either CocoonJS or PhoneGap. This is not a C2 plugin, so you will be working out side of the C2 environment. Also I'm not sure if any extra tinkering if any is going to be needed.

    So the plugin may work out of the box, or the plugin may no. If it does great, it works, not to much of a problem. If the plugin doesn't some one will need to find out what's not working and fix it.