Scoremonger's Forum Posts

  • You're welcome. You could also set them at runtime with "set position to another object" actions on the start of the layout, if you want it to be more precise and automatic.

  • OK, I see the problem - looks like the image points you're using as your joint locations don't actually line up with the centers of the wheels. Set the wheels' opacity to 50% so you can see the body of the car behind the wheels, and then line the centers of the wheels up carefully with the black dots on the body.

  • I have tried to make this project as the example but why my car can not run smoothly.

    Is there anyone can tell me what is wrong about my project?

    this is my project: https://www.4shared.com/s/fb8epJzuJca

    I'd take a look, but do you have a Dropbox or Google Drive link instead?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    >

    >

    > Frankly your snarky attitude and manner of speaking makes it obvious that you aren't really a professional,.......

    >

    > So, if you're serious about being a "real dev" yourself, the first thing I'd suggest is to stop assuming you somehow know everything despite having never done any serious work in this field. Stop assuming people who disagree with you are fools. Stop wasting your time picking fights in forums. It might make you feel good to lash out and insult people, but you're not doing yourself any favors. Spend your time mastering a tool of your choosing - pick one and stick with it even when you encounter frustrating problems (which you will, usually in no time flat). Use it every single day anyway. Ask for feedback on your work and consider it carefully, and be respectful towards the people kind enough to give it to you even when you don't like what you're hearing. Read up on your craft (Gamasutra and the GDC vault are great resources). And don't give up. This stuff is difficult, and even with some of the great engines we now have access to, it takes a long, long time to get good at it or to finish anything worth finishing.

    >

    > Good luck.

    >

    You seem like a young 'un. This is a tough industry son. I'd drop the Construct and focus on true code, and don't mention Construct during an interview process. Trust me on that one.

    But thank you for your insight into my lack of experience. I had no idea how inexperienced I actually was.

    Haha, young I am not, sadly. Not really. I wish that it were so. Not totally old yet either, though.

    Anyway, I'm happy to talk over PM and we can have the battle of the resumes there. I'm not looking to trade insults. Now you have me genuinely curious as to your background. I just can't imagine any of the people I've worked with in games hopping onto a forum like this to berate beginners for their choice of tools.

    As for mentioning Construct during interviews, what sorts of interviews do you mean? Programming? Design? As I said, I'm a designer, so I'm not greeted with any particular elitism with regards to which game engines I've used. Maybe programmers are more judgmental about such things, although I can't see why mentioning it would HURT, assuming you can otherwise show that you know what you're doing and would be a good fit for the team. Using Construct admittedly doesn't prepare one to be a programmer, although many of the basic concepts are similar.

    For everyone else, if you're going to interview for a game design position, don't be afraid to mention things you've done using Construct. Things like that don't count against you - why should they, unless that's your only experience and the job requires engine-specific knowledge? In game design it's more about what did you actually MAKE, not necessarily the tools you used. When I've interviewed candidates, I'm always favorably impressed when they built games on their own initiative. We hired one kid based on his positive attitude and a simple game he'd built using an engine very similar to Construct. Another junior designer I know was hired partly because of his experience making maps for Left 4 Dead. Passion and determination counts for quite a bit.

    >

    > >

    > >

    > > See you there bud. Bring your copy of Construct with you, we will all be fascinated. You could do a demo - wear one of those headset/mic thingies.

    > >

    >

    > I'm totally serious, actually. Shoot me which talks you're going to via PM and we can talk the realities of game development face to face. My company is having us share passes, so I won't be there every day, but I'm sure we can make it work. I'm generally interested in the design track stuff since that's my day job, but whatever, the place isn't that big.

    >

    Well, look at you. A "serious" game designer, with all the bells and whistles, and using Construct - what are the chances? As much as I'd love to chat "shop" with a total stranger, 'face to face', from a forum, I will decline your offer.

    And before you suggest it, you're right - I'm declining your invite because I've never worked at any major software company and have never written a line of code. You win my friend!

    Frankly your snarky attitude and manner of speaking makes it obvious that you aren't really a professional, despite your mockery of people who consider themselves developers but don't share your opinions on tools. Real developers don't speak to one another the way you're speaking to all of us. We generally support and respect each other. We keep things civil even when we disagree. We don't mock people trying to get started in making games no matter what tools they choose. Making games is difficult enough without this kind of petty, childish sniping, and if you bring this kind of attitude to a job in this industry, you won't last long.

    I don't use Construct in my day job - I use it for smaller side projects. But that doesn't make "worse" than what I do use on the job (which is Unreal Engine 4 - I've also used Unity and various proprietary engines in my career). Construct is simply a different tool for a different job. It's better suited to smaller, 2D games. "Smaller" doesn't preclude the possibility of a game being very fun or very successful. Construct is much easier to learn than Unreal or Unity, and certainly FAR easier than rolling your own solutions with code, from scratch. Construct is also a helluva lot of fun to use. A person can absolutely be a serious developer and use Construct. It has some technical and workflow issues (just like every engine I've ever used) but fewer than many of them. For example, Unreal crashes for me more often than Construct does. There are no silver bullets out there, "dev level" or otherwise.

    So, if you're serious about being a "real dev" yourself, the first thing I'd suggest is to stop assuming you somehow know everything despite having never done any serious work in this field. Stop assuming people who disagree with you are fools. Stop wasting your time picking fights in forums. It might make you feel good to lash out and insult people, but you're not doing yourself any favors. Spend your time mastering a tool of your choosing - pick one and stick with it even when you encounter frustrating problems (which you will, usually in no time flat). Use it every single day anyway. Ask for feedback on your work and consider it carefully, and be respectful towards the people kind enough to give it to you even when you don't like what you're hearing. Read up on your craft (Gamasutra and the GDC vault are great resources). And don't give up. This stuff is difficult, and even with some of the great engines we now have access to, it takes a long, long time to get good at it or to finish anything worth finishing.

    Good luck.

    See you there bud. Bring your copy of Construct with you, we will all be fascinated. You could do a demo - wear one of those headset/mic thingies.

    I'm totally serious, actually. Shoot me which talks you're going to via PM and we can talk the realities of game development face to face. My company is having us share passes, so I won't be there every day, but I'm sure we can make it work. I'm generally interested in the design track stuff since that's my day job, but whatever, the place isn't that big.

    > If you don't want to read the documentation, I guess it doesn't matter how well it's written!

    >

    I have read many C2 docs over the years and they were in general at an amateur level. My suggestion is that if you are charging "big boy" per annum prices, that you hire a trained tech writer; at least one - and stop relying on user provided tutorials (unless they are getting part of that per annum charge?). At $99, C2 was "lifetime" and I could overlook the bugs, the lack of documentation, outdated documentation, and the lack of fixes. The new pricing structure demands a higher level of support.

    Also, let's not get too carried away with what Construct can and can't do. If you guys are creating Pong via a drag-and-drop application and thinking you're 'devs', think again. What you are doing is locking yourself into an eco-system that demands that you pay yearly or your projects are useless to you. And if monetizing, with the amount of times Construct apps generate violations on Google Play / AdMob - you will be paying for years to support those apps, else you cant update/fix the Google Play violations.

    I'd recommend people move over to Visual Studio, an IDE that can export to Windows/iOs/ Android. It is DEV LEVEL and its FREE. As I said earlier, Scirra is charging "big boy" prices now and with beta plugins for monetization, missing plugins for monetization, or plug-ins/bugs that sit unfixed for months, non-action isn't going to cut it.

    If you have no interest in monetization, and you just want to pay $99 PER YEAR to show Granny you're a 'dev' and made a game of Pong, knock yourself out.

    Cool man, let us know how that works out for you! Good luck! I'll see you at GDC this year, I'm sure!

    Whoops - I got tempted after reading of export to APK. Went to purchase and the price is PER ANNUM -

    hohohoho

    No thanks, Scirra you are far from being stable enough to charge per year, like Adobe. My initial post was correct - a money grab.

    It's a different business model than you're used to, not a "money grab". "Money grab" suggests that what they're doing is cynical and dishonest somehow - the steady stream of improvements to C3 suggests otherwise.

    As to their stability, they seem pretty stable to me... they deliver upgrades consistently, they generally respond to bug reports promptly, and they're active on the forums. I think they are working hard in good faith, and have integrity. If this new business model allows them to be even more stable and more productive still, I'm happy to use it.

  • All I know is that he had a considerable amount of work, and helped make C2 what it is to day.

    And his absence will taken some effort to recover from.

    Oh. OK. I thought you had a reason for bringing him up that related to this discussion.

  • I'm assuming its also one of the reasons Rex left.

    I don't want to get too off-topic, but what reason do you mean? Did he ever actually say why he doesn't want to port any more C2 plugins?

  • I'll admit that whilst I can see the need for fledgling devs to see how the sausage is made, I'm with newt in hoping that the new runtime more closely marries the SDK to the event sheet system - it's one of the few ways I can see modular events being possible.

    I agree, yeah - I would love for my list of gripes to be rendered moot as a result of event sheet-based plugins or something similar. I can't think of anything I've tried to do with a custom behavior that couldn't be done with event sheets, but event sheet logic+families is a pain to port from project to project, and if you make updates in one project you have to manually revise the other(s) too, etc. I have absolutely no real desire to look under the hood (er, bonnet) of C3 - I would much rather stick to event sheet-style logic for everything.

  • I'm sure this is frustrating for you at Scirra who have already put a tremendous amount of work into the docs, the editor, the runtime, and the website and often seem to be greeted with complaints (valid and otherwise) for your trouble. So thank you for all your efforts and the fantastic tools. Now it's time for some complaining!

    I noticed on the original thread on the Addon Exchange announcement you are requesting suggestions for specific things that are missing. I can't dispute that what's there is enough for a seasoned javascript developer, but like the vast majority of Construct users I'm not one of those. So here are some things I think would help beginners, or things I looked for and couldn't find. This isn't meant to be exhaustive. Just some things that tripped me up as I was learning.

    • I was unable to find anything in the docs on how to spawn objects at runtime (a search for "createinstance" takes me to the Theme Addon page for some reason). In fact it seems there really isn't much mention of the runtime API in these C3 SDK docs at all. I may have overlooked something really embarrassingly obvious, but it seems the only resource for finding such things is old C2 plugin source code and user forum posts. If that's correct, then this must be the single biggest missing category of information in these docs. I would love to be wrong about this! Bring on the humiliation.
    • A suggested javascript/html curriculum for those who aren't already skilled in it would be helpful. Javascript is a pretty huge topic that could be overwhelming for beginners scouring the web for tutorials, books and classes. A summary of the js/html5 knowledge required to effectively write plugins for Construct would be useful, and direct links to relevant resources would be great as well. Obviously you can't be responsible for teaching your user base all this stuff, but the more you can push us in the right direction, the less you'll have to deal with threads like this one. That will free you up to deal with threads endlessly moaning about your business model.
    • Inside the template, one instance I kept getting confused about the difference between a behavior's name and id, because the name is "My custom behavior" and the id is... "MyCustomBehavior". In the docs you say of the id, [quote:1nttuteg]"To ensure it is unique, it is recommended to use a vendor-addon format, e.g. mycompany-superaddon." You should definitely be sticking to such recommendations in the template.
    • Similarly, the description for "name" in the docs could be elaborated on a little (this goes for quite a few entries, I'd guess). It currently describes the name as "The name of the addon, in English." That's clear enough, but some mention of where this name is actually used by the addon would be helpful to further differentiate it from the id. It might seem obvious, but to someone trying to figure out 100 different bits of syntax at once it might not be.
    • BEHAVIOR_CATEGORY is another example of slightly insufficient description. Regarding the categories themselves it says, [quote:1nttuteg]"This must be one of "attributes", "general", "movements", "other"." But beyond that there is nothing - it's left to the user to try to reason out what the difference between "general" and "other" is. "Movements" is the only category name that's 100% idiot-proof imo. Not a big problem, but yet one more small unnecessary one. I'll stop with listing these, but I hope you see my point - I'd rather you err on the side of providing too much information in the descriptions to minimize the amount of trial and error and head scratching I have to do.
    • Finally, some more examples (particularly with regards to runtime API calls) and even full tutorials on building some simple plugins from scratch would be very helpful. I realize such things are time-consuming to make and the runtime is in flux, but the more you can do along those lines the better.

    Thanks.

  • I won't argue to allow everyone free access to the source code for plugins, but as a user who's written a number of simple plugins for my own use I can say that having access to the existing ones was the only way I was able to fully understand what was going on. Yes, I rtfm, but there are almost no examples in there for basic functionality.

    Compare this with Unity, for which there are almost too many resources available on how to write components, etc. There's still a steep-ish learning curve (at least if you want to program things properly), and it's an apples and oranges comparison on some level, because in Unity you really have no choice but to program components if you want to do anything, and Construct's event system eliminates the need for such things. But it's impossible not to make this comparison when you're struggling with sparse documentation.

    The template is a good start, but it doesn't really DO anything, so it's tough for those of us who aren't very experienced with js to extrapolate how to get more complicated functionality going. If one searches long enough it's possible to find examples scattered throughout various forums, but this is hit and miss, and often the people who're good at coding 3rd party plugins are perhaps not the best at explaining things to idiots like myself. So yes please, more include more examples and more elaboration in the official docs. Some well-written tutorials on how to write plugins for absolute beginners would be welcome, too. There is almost nothing available now.

  • > I don't think this is the place, but I dislike and am not interested in C3 because of the choice to make it only work in the browser instead of stand alone desktop application. Is that how it will remain or is there any plan to make a desktop version?

    >

    i dont understand the hangups with the browser app.

    I fully admit i was a bit skeptical at first and yes there are still a few bugs / issues to iron out and im still a bit uncomfortable with the saving methods....but....

    .... overall, it works real nice, and compared to C2 , it looks better, feels better, scales better from screen to screen, is more responsive, quicker to load, ui is cleaner, you can go full screen and have events sheet really top to bottom of screen, ........it works offline , will always be up to date on line, i can access it from pretty much any reasonably modern device from anywhere in the world ..... it also seamlessly transfers to a mobile touch interface to work beautifully on my android mobile phone wtf !!!!.....

    all of a sudden, downloading and installing an exe onto a windows OS feels archaic

    +1 to all this. C3 is a blast to use and I can't imagine going back to C2 at this point.

    I was pretty annoyed when I first read C3 would be browser-based, because I'd had bad experiences with browser apps in the past. But having used the full beta version of C3 for the better part of a year I really like it. Not having to install anything is nice, and if you're using Chrome you can easily create a desktop shortcut so C3 runs in its own window, which does away with all the "browsery" stuff like toolbars and the browser menus. In terms of look and feel it's then behaving just like a standalone app. The only severe problem I've had with it is if a website script crashes Chrome, it'll take down C3 with it, but this happened exactly once in the entire time I've been using it.

    As has been mentioned they are eventually planning a desktop version which hopefully makes people drop this concern, but at this point I'm not sure if I'd even bother with it. I'd suggest just trying the free version, and setting it to launch from your desktop. After you open C3 in Chrome, click the line of vertical dots in the upper-right corner (Customize and control Google Chrome), choose "More tools", then "Add to desktop", and leave "Open as window" checked. Launch that sucker from your desktop and see what you think!

  • Hi all,

    Disabled events stand out visually and make it harder to read event sheets. So, I made a very simple theme that turns disabled text in event sheets light grey. It keeps the strike-through, and is otherwise the same as the default theme (AKA "no theme").

    Download the addon file here: https://www.dropbox.com/s/yh06bi61r0hbx5a/crc-lighter-disabled-events.c3addon?dl=0.

    If this link ever breaks, the entire theme defined in the .css file is this:

    /* Set commented-out events to a light grey. */
*[disabledevent]{
	text-decoration: line-through;
	color: #BFCCE0;
}[/code:2cmoeqhf]

Please PM me if there are any problems downloading, etc.

I'd like to be able to make the icons in disabled events look more faded too (the system "gear", etc.), but my CSS knowledge is pretty nonexistent, so if anyone knows a way to adjust them please let me know and I'll add that to this theme too.

I'm not planning to do versions of this for the light and dark themes, but perhaps the fine folks at Scirra would incorporate this type of styling into the official themes if enough people request it.

Enjoy!