TheRealDannyyy's Forum Posts

  • Hi there, I have a question about relative placement of sprites using the anchor behavior.

    I think that there are 2 ways to relatively align objects to the viewport of a game:

    1. The Anchor Behavior

    2. Manually placing the sprites X & Y positions by using the Viewport Expressions. [eg. ViewportLeft("Layer") + ViewportRight("Layer")) / 2 , to center X]

    However, if we for example plan to create a simple game menu with a sprite in the center and use the anchor behavior to do that, wouldn't that be inefficient

    compared to manually placing the sprites X position with the viewport expressions at the start of a layout?

    I mean when using the 2nd method you essentially just trigger it once with only one impact on performance on the start of the layout.

    Just to make it clear, I think that the anchor behavior is always setting the position of a sprite.

    Meaning after the sprite had been placed in the correct position in the first time, would it still run and try to set the sprites position even if it has the same value as before?

    For example if we would try to place the relative X position of a sprite, would the behavior work like the following:

    IF: Sprite.X is still at the same place ~> DO: Nothing (No further performance impact.)
ELSE DO: Set the new position and relatively place Sprite.X[/code:8jwxgv2g] OR does the behavior work like this:
[code:8jwxgv2g]ALWAYS [Every Tick]: Determine the new position and relatively place Sprite.X (Constant impact on performance.)[/code:8jwxgv2g]
I know that this might be confusing but it is really difficult for me to explain this process
because I don't know/understand what goes on behind the scenes, in the actual JS code.
([i]I guess this question is for people with experience in coding with JS?[/i])

  • #2. When you debug the layout, is the game supposed to run slow? I was running the first game in the Level 0 book-Bubble Pop Madness- and when debugging, the game chugged, like 5-9 FPS. (Using Google Chrome, btw.)

    Running it normally doesn't cause any issues.

    I'm not sure if it is just on my end but I usually separate the debug ribbon from the game canvas while debugging and everything runs fine then.

    There is a small button to do that, you should try it out yourself, it might help you out. (Note: you have to manually do that every time when you want to debug.)

    Well 7 page of this topic named "Construct 3 any news?", "What we do is discuss and compare engines because that is what this topic is about" is actually off topic.

    People asked infos about C3, infos were released.

    Why compare with other engines ?...

    Yeah it started differently but got twisted around so that is kinda our "current" topic since Ashley said everything about C3 he could say for the moment.

    I also never threatened anyone, I just wanted to gather some more information about C3 (maybe not in the most polite way) but in the end you can see the results.

    It's not easy to talk about something with so less information about it, that is why we do speculations + comparisons and let the people decide if they would like it or not (sometimes it might be a bit more critical than expected).

    I think this can only benefit Scirra because it shows what your audience is all about for future products without them doing a "market research" or something like that.

    This is really not a topic about liking or hating C2/C3, just wanted to make that clear for future responses.

    I think it's, frankly, quite rude, tasteless and disrespectful to be hyping a competing game engine on these forums and suggesting it's somehow superior to C2 when the thing isn't even out yet. Yes Spark is intriguing, I'm signed up for Beta myself, but enough is enough. Seems some people are almost trying to extort information/release of C3 from Ashley at this point by desperately threatening to switch over to another (unproven) competing engine. More annoyingly, valuable C3 development time is potentially being lost here by Ashley having to respond to silly messages and ultimatums, so all this seems a bit counter-productive to me. I'm not saying we can't mention other engines here or anything, but there are surely better places for extended hypetalk and marketing jargon regarding a competing product than these forums, no?

    We don't advertise for other engines nor do we want to spread the hate for C2/C3.

    What we do is discuss and compare engines because that is what this topic is about and quiet frankly the only thing we can do at the time with the amount of information given.

    We might drift away on certain points in the discussion but that happens all the time on several other topics too which were published here in the "General" section of the forums.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    glerikud By looks of the latest

    Subscribe to Construct videos now
    (uploaded today) it seems to look like everything has been working fine with the development so far.

    The event system looks similar to C2's system but with a more modern touch and the overall structure with scenes and such seem to be working fine to.

    I don't want to "sugarcoat" anything about Spark yet but it seems like they get things done quick.

    Here is a demo video I found on their forums.

    Youtube Link

    What do you guys think?

    We are basically working full-time on C3 and it's been our focus for over a year now. It is certainly not going to be cancelled or anything like that. We are just not ready to share any information yet for a few reasons:

    - C2 is still a great product and actively maintained, and we think it's best for users to keep focusing on C2 instead of sitting around waiting for C3 (especially since we still don't know when it will be ready)

    - we don't want to say something and then end up delaying, modifying or ultimately removing any particular feature we talked about - right now everything is still subject to change

    - public information about the state of C3 could affect our competitive edge, especially since we're doing some pretty interesting stuff

    - we don't want to ruin the surprise!

    Rest assured we are working daily to get C3 ready as soon as possible, and we will share more information when we're ready.

    At first thank you very much, for the information and the great support towards the current engine Ashley !

    This really helps me out the least and explains why we heard nothing from C3 for the past time.

    Even if you think that information like this is vague and not necessary to be shared with the community,

    I can assure you that every bit of information like this is appreciated and helps us to get a point of view for the current state of C3.

    Feel free to post any "not blogpost worthy" information regarding C3 in the forums instead of keeping

    it secret in future too and thanks again for all the work you do on the forums daily for the Construct community.

    It would be a huge project for any programming tool to add non-programming support anywhere near as sophisticated as C2's - there is an absolute ton of features in there ranging from top-level features like functions and loops down to unique internal optimisations to make it run fast enough, all built up and tuned over a period of years. I would be super surprised if anyone could get anything remotely comparable even after say a year, if they are starting from scratch, and they'd have to have a 100% focus on it the whole time.

    Ashley you are right on that for sure but it is a bit different on their end.

    The Godot team is not doing everything by themselves, they also seem to "outsource" a lot of their work kinda like C2 does with plugins.

    I don't mean to say that C2/C3 should be open source and free for any kind of community modding, what I mean to say is that they have more people actively working on their engine, which obviously results in less time of development for whatever feature they are looking forward to add to their engine.

    Besides from all that, I think what the community would like to see is some more information about C3.

    I fully understand if you don't want to share explicit information about features you work on

    because of the risk that people could steal those and make their own thing out of it.

    The thing we would like to see is for example some sort of monthly progress report like you already do all the time about awesome new technology and updates, perhaps is there a reason for the lack of information for the last couple of months?

    Are you not allowed to share further information? Is C3 already in a state were it's about to get cancelled?

    Even though I started with C2, I can clearly see that the development of C1/C2 really got pushed by the help from the community.

    When you plan to take out the help of the community from C3's development (I highly doubt that you would plan to do so), then what is the point of waiting for C3 for the next years in first place when others offer something equally good with more community integration?

    This is why I think that any kind of information regarding the current state of C3 would be nice and well appreciated by the community.

    Construct will never be outmatched by Godot, because it's a different thing and because of the incredible speed, usability and flow you have in C2. This means everything to me, because I like when I am having flow while working. Godot has no flow what so ever. All this cool features, that godot has means nothing, cause it's not really...

    if Godot really stands to their promises...

    That is basically what I meant before.

    C2 currently has all those neat features and a good workflow, but obviously Godot gets a lot of attention with monthly updates (not just bugfixes) and by the looks of those it seems like it could outmatch C2/C3 if they stick to their promises and really add those new features.

  • I'm not 100% sure about this but I think it is some "C" based language with JS and Jquery for web based features.

    It's years away.. Really?

    I thought that it's using the same core - so Ashley would only need to port the GUI of the editor.

    If its years away, then it would be worth for me to learn Godot and use that instead in the meantime...

    Don't rush the Scirra Team on making Construct 3. If they rush, many unexpected events will happen or it may get incomplete...

    (Please note that the following statement is based on facts and my personal opinion!)

    I know that rushing is almost never the right way to do something but in this case it really seems like it would only benefit Scirra and their future product.

    I don't question their actions nor am I in a position to tell them what they should do but Godot is not something that can just be ignored.

    Take it from this point, what could C3 have that Godot doesn't already have or will have?

    • Intuitive & Easy Interface (Scene/Layout based): C2/C3 = YES | Godot = YES
    • Easy Event Based Editor: C2/C3 = YES | Godot = NO (Promised feature in near, future updates)
    • Engine Based Features (Examples): C2/C3 = Basic animation/image editor; "1 click" art and audio import; Web based plugins (Customizable); Runs on Windows (OS X + Linux with C3); Multiple languages (Yes with C3); 2D game development (limited to web standards & changes) and many more features that both engines mostly have in common... Godot = Advanced image & animation editors; "1 click" art and audio import; Native + web based plugins (Promised feature in near, future updates); Runs on Windows + OS X + Linux + FreeBSD + OpenBSD + Haiku; Multiple languages (Yes with future updates); 2D + 3D game development (Native or web based limitations) and many more features that both engines mostly have in common...
    • Exporting Options: C2/C3 = Universal (HTML5 + Wrappers) | Godot = Universal (Mostly Native, "1 click deployment")
    • Helpful Community & Custom Content: C2/C3 = YES | Godot = YES

    To wrap it all up, I think if Godot continues to grow with future updates, C3 won't get a single chance to compete with Godot in terms of uniqueness and features.

    As harsh as it sound, about ~20% of Godots current content is already capable of doing the things that C2/C3 are capable of doing.

    To go back to C3 itself, how long is C3 already in development 1-2 years, anyway since the last big announcement a lot of time has passed but what does that mean?

    For a firstly expected "copy/pasted" engine with a few new features that is a lot of time! I think by now we should be expecting the new "big thing" with cutting-edge features (e.g. improved exporting and other suggested features by the community) because a simple "copy/pasting" process of existing features cannot take this long in my opinion.

    As much as I enjoy working with C2 and it's limitations, I'm slowly starting to think about jumping over to other products because of the lack of information and support towards community based feature suggestions.

    I know that the most of us here fully support Scirra and their future products but honestly, why would you buy a product when there is another 100% free product which is capable of doing the exact same things but with even more features and helpful tools included?

    I mean it is us (the community) that buys and uses the product, without us there wouldn't be C3 and if Godot really stands to their promises... I guess that could mean the end for future products from Scirra.

    At last, we can only hope that we get at least a short statement about the current state of C3's development to compensate some of the concerns from the community.

  • @Tom this is nothing with high priority and can be done whenever you find the time for it.

    I would like to suggest a direct link to the Nw.js download page with the latest version below in the download section.

    If you find some free time I would really appreciate it, if you would invest just a few minutes to add this suggestion.

    Something like this:

    Again, I would really appreciate it and I guess a lot of other forum users would like to have that too.

  • You may have more luck with using the chipmunk physics behavior instead. It provides more control over adding joints. The built in physics behavior only attaches joints to the origin or image points of objects.

    So as I understand it, the basic Idea would be:

    1. give the physics (or chipmunk) behavior to all the bones, and have it disabled at the start.

    2. when you want to ragdoll, enable the physics and add joints between the bones at the pivot points (like the knee for example).

    Adding the joints is the only tedious part. Here's the capx you posted with the chipmunk behavior used. Press space to ragdoll (or mostly just scuttle) the player. I quickly added imagepoints on the objects to define where the joint should be, and attached the head all the way to one foot. It's not perfect, but this was mainly just for a proof of concept so I didn't fine tune it. However if you put the time in you can get it fully working.

    https://dl.dropboxusercontent.com/u/542 ... uttle.capx

    Amazing, thanks R0J0hound!

    I get what you did there and I should be able to work with it. It'll take some time and tests to figure it out but I'm glad that I finally got a way to achieve ragdols.

    I've got one question about that though, how is the performance impact? I will have a couple of enemies using this,

    so do I have to use the old fashioned "despawning" dead bodies (destroy by fade-out) way or can I keep them safely flopping around on the layout?

  • Thanks for your quick informative responses, I think I will run with it.

    I understand relative design with the scaling methods well but even a small minigame like Freaking Letters

    took me so long to design because of that.

    Thank you again, if anybody else would like to share their thoughts feel free to share them below!

  • This question is mainly for those who have already released their game on steam or equally popular gaming platforms

    for desktop with "Letterbox Scaling" enabled. (Windows/Mac/linux releases only!)

    Do people actually care if there are black bars while they're playing your game? (Did you receive any negative reviews or discussions about that?)

    I mean from a developers side letterbox scaling is the easiest and quickest way to work on your game because

    you basically don't have to care about supporting multiple screen sizes.