Ruskul's Forum Posts

  • > C3 is not FREE. That is the only "problem".

    >

    > No amount of clever marketing, learning material or whatever you can think about can get around that.

    Honestly, I don't get why the trial version of C3 is as limited as it is. There's a ton of great features that you can't even access from the trial version and the tiny limit on events doesn't make sense from my POV.

    Yeah, imo this is a poor decision. 50 events is stupid small. 2 layers is stupid small. No families is basically broken. Canʻt even try javacript... As you said, limits on everything.

  • Can anyone think of a single other subscription based engine that doesn't have a fully featured free version?

    Nope. I happily bought c2. I would have happily bought c3. But I will not happily shell out money on a monthly basis for a tool, especially when I donʻt use it every month.

  • Its for kids because that is the priority scirra has taken with their product.

    Scalability issues and failure to add features for fear beginners would find it complicated... these are major barriers in my mind to any serious look at construct.

    Construct is great, so long as you are either making something simple or a prototype. But if you want to practice SOLID, you canʻt. If you code, you know, if you donʻt, you probably wonʻt.

    But anybody coming from unity to c2 is probably lacking a skill. Or they have the skills and want a speedier work environment for 2d, but then... enter point #1. If you canʻt scale, slapping down a lot of progress on day one is useless if you are having growing pains already on day 5.

    Every dev cycle I come back to construct, It has a nice IDE, and making games in it is fun... but each time I leave to finish in unity, frustrated with lack of event reusability, better abstract coding, efficient functions, etc...

    The moment you find yourself creating a tool to edit project files so you can more efficiently delete or copy variables... well...

    Also, and most importantly, if you are visual, but want to write good events, you need to use families... families all have the same icon in the event sheet, so now, that whole visual nature of events goes out the window..

  • To append to my previous statement, I have plenty of experience working within construct 2, less so c3. I used Tiled to create levels in c2 and Unity.

  • If you are still looking, what is your time frame and scope? I have 2 more websites to build in the near future but after that I have availability. The bulk of my experience is as an artist, but I've done my fair share of level decoration.

    If you are okay working with an experienced programmer/artist, but a minimally experienced level decorator, let me know.

  • There's a C3 version in that link; I've been using it for a few months and it's been great!

    Check out page 10 in the thread for the most recent version

    SOWEET. Thanks, i missed it. Gonna give it a go!

  • try making your own pathfinding with events !! You'll gain lots of experience and improve your skills !

    I mean... I can already tell you it will probably perform very poorly built on top of the event system (unless maps are really small or agents limited), will be a headache to scale, will be hard to move to other projects, etc...

    Code is fast, flexible, and elegant. Construct events are... well... nice for easy tie things together, but not searching a graph tree.

    Don't get me wrong, I like events, there is a good reason why I always try to circle back to construct every so often... but I learned along time ago that if the tools out of the box don't have what you need, you are much better off spending your time in an environment focused on the code (Unity, Unreal, Mono, Phaser, take your pick).

    It would be a good challenge for someone not familiar with events/coding or pathfinding algorithms, or just someone wanting to say they did... But none of those apply to me and would take longer than just coding it. I'm looking for easy here, not because I lack skills but because I lack time. Which is why, like I said I always come back to construct. It has the allure of promised fast prototyping, a more simple workflow, better asset pipeline for 2d... I use construct when it can do the job more easily than other tools.

  • There is an addon for pathfinding on a tilemap called EasyStarJS. Not only it's much faster, it has tons of features and allows to mark specific tiles as obstacles, change their cost etc.

    This is for c2 yeah? I remember using it. There isn't one for c3 is there? I already switched back over to unity for the project so its semi moot at this point though.

    I needed oneway, modifiable pathcosts per unit, etc... Creating a whole behavior in c3 when I can do faster in unity just made it a no brainer.

  • Okay, I wasn't using this right either. I find bugs as soon as I moved the 3d camera. I've searched around for other answers and found one from newt that said to simply use mouse.x and mouse.y position. That also seems to not work. I'm using the ghost racer example and spawning a flash object where my mouse position is, just that it only works when the camera isn't moved and left at default.

  • You have to use mouse position to calculate cavas to layer. The layer you select needs to be the one where you want the selection to take place on. If that layer has a different z level than what you are looking to click, if won't seem right.

    I'm going to jump in a project so I can share the details

  • So yes designing your own plugs is a bit convoluted, especially since behaviors that work with other behaviors... cough solid, are basically black boxes.

    Still so salty about that. Consequently had to make my own collision system in c2 to handle the things that Ashley just doesn't see the need for. At the time that included collision point angle and raycasting and collision filtering. And still I see warnings about how "efficient" and "complex" the platforming behavior or collision engine is and how you really shouldn't create your own because it won't be as good... >.>

    Making games in construct is pretty nice... but coding in construct sucks compared to other frameworks. If the solution in construct is to code almost everything you need, the reasons for using construct quickly go out the window.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • They were public originally, but they decided to do this for C3.

    Its because people were editing the official plugs just to add a few nuts and bolts.

    That's not maintainable.

    I don't understand, do you mean they were simply editing them then releasing these as their own?? Some of those nuts and bolts aren't just "nice to have" though. In many cases they are so desperately needed that they literally make or break a game. In all fairness, construct is already terrible when it comes to scale and maintainability on larger projects anyway, that if I had a choice between a behavior that needs to be maintained, and a bunch of tack on events duplicating behaviors that should be in the behavior and I'll want in other projects (angle of collision point for example), thats just an obvious reason to bail developing in construct and once again moving to other engines/frameworks.

  • Many old behaviors and plugins remained mostly unchanged since Construct 2. You can install C2 and find their source code in \Exporters\html5 folder.

    Yeah, thanks for the suggestion, I already have alot of those ported over that I had changed originally!

  • They aren’t available. You can see the runtime portions of them with the browser console when previewing, but the edittime part is obfuscated with the rest of the editor.

    Shucks, thats super frustrating. Do we know why or is it just "the way things are"?

    If I can scoop the runtime, I wonder what is the point of not allowing users to download them? As it stands, many of the more "complex" behaviors were always lacking in key features (Box2d :( :( :(, pathfinding, platforming, etc...). I always bridged this gap by adding what I wanted...

    Adding on a few features and then copying those features to future updates to behaviors is also easier from a maintainability standpoint. Lacking any inheritance or ways of extending behaviors means this is always a mess, but rewriting a whole behavior just to add a few nuts and bolts...