InsaneHawk's Forum Posts

  • fantastic work

    Thank you!

    Looks amazing - nice work! If you're up for letting us know - did you use any plugins or anything for the UI or level editor, or did you just custom code it in JS? I can't imagine you'd use event sheets for it.

    Thanks! UI is entirely hand made (for the game) only using events, no plugins, as for the editor we're using vuejs (we made this as an external tool, connected to the game, when you press 'preview' it previews in the game, and for that we used JS)

  • UPDATE:

    Made some changes to the topic to reflect the content added with our last patch.

    Level Editor, new level & more have been added!

    Subscribe to Construct videos now

  • Update:

    We're now out in Early Access on Steam!

    You can check it out here: https://store.steampowered.com/app/1001970/Rhythmy/

  • Good luck with early access! I am really bad at the game, but I still really like it :) Style is so clean and great music.

    Thanks Mikal! Appreciate! :D (You'll become an expert, I'm sure of it!)

  • What a cool game! Did you really make all of this using Construct?

    Hi! Thanks for your comment! Yes it's all made using Construct3! :)

  • UPDATE:

    We updated the entire topic to reflect the game in its actual state, also we'll be releasing on Steam Early Access on March 24th!

    Feel free to spread the news and share it to your friends and families!

    Subscribe to Construct videos now

  • InsaneHawk yep it's all good. it's great you have that many testers! I hope they have been giving you good data.

    has there been tons of work since all the feedback? I haven't officially went through that step yet so I'm just wondering how it is. I'm sure you are in feedback overload. I hear also you have to read between the lines to figure out what is actually being said since the player (or non devs) don't know how it was made, they are only seeing the end result therefore the feedback is sometimes strange.

    I'm very thankful to have such a nice and positive community for now, and even if most of them don't know precisely how game making is working, their input as a player is very important, because there's such a large variety of players, that from one to another, the experience might be completely different, so every feedback is important.

    A lot of their feedback has been implemented since the alpha, and we'll keep going as they're going to play the game in the end, so it's our job to make sure they enjoy every single part of it as much as possible!

  • InsaneHawk yeah I applied, but never heard back, I assumed I wasn't a good candidate. no worries. best of luck.

    Well, I wish we could invite everyone. We're inviting a few people on every patch day, like this one that happened a few days ago, but we also try to follow the application order and as there's many applications, your being recent wasn't picked, but that's mean you'll have more chances for the next wave ;)

  • looks great, are you still looking for testers?

    Yes we're still accepting applications, you'll find all information on Discord!

    UPDATE: New patch recently kicked him, which result in the second chapter to make its entrance!

    Here's a preview of what's in this patch, took this opportunity to update the topic at the same time!

    Subscribe to Construct videos now

  • Is there anything actually wrong with just using instance variables? If not, given there's 10 years+ of other features on the suggestion platform, isn't our time better spent on something else? That's what I mean by opportunity cost.

    Well that's up to you to decide, my goal here was to make a talk on having this kind of variable type in functions, to have a better workflow, but you said it will require a major rewrite of the engine, so I guess there's no way this is going to happen. But the fact that, this workaround is to me, pretty much unknown is an issue, since this is a very important of regular coding, and there's no official plugin supporting it right now, which is hard for new user experience (if you get my point)

  • > kinda of like the journey of the function plugin, it was a separate plugin for a long time until it became a first class citizen of then engine.

    I'd really want to avoid going through that again. Replacing a major feature with a different and not entirely compatible one is a painful transition to go through for both us and many users. It also leaves us supporting both indefinitely, as there are always too many remaining projects using the old feature to justify removing it. It's much better to get it right first time wherever possible. The only reason we didn't with functions was it was designed in a hurry in the early years of C2 with many shortcuts deliberately taken, and the replacement was so much better (and so many people were asking for improvements) that it justified all the pain and awkwardness of going through a replacement.

    We all know this proposal about the global sprite with instance vars acting as an enum (by all I mean, people working with Construct for quite some time now) but as you mentioned it is a workaround. It works very fine, and sometimes is enough, but how about new user experience? This isn't something new users can get that easily, and when I first started Rhythmy over two years ago now (as an example) I had no idea this could be done and just assumed that enums/lists just weren't a thing (and in some way, they're not as this is a workaround

    if the work around is the preferred choice, it should be its own object type (not associated with sprite, which has has rendering/world properties etc)

    If my proposal would require too much work, maybe this could be a solution, because it makes no sense to make an empty global "sprite" to make a static enum? (and for new user experience, even less)

    But maybe looking forward to an official solution like this, that won't require a massive rewrite of the engine as you mentioned, because that definitely won't be possible with the current ressources you guys have, maybe this can be a solution that won't require an insane amount of work, and improve overall workflow.

    And that way, you won't be "erasing" or forcing replacement for people that were using the old workaround, because as it's a workaround, it would still be possible, but you're giving the opportunity to have it supported more "officially"

  • You are proposing enum type for functions because it will make them more organized, easier to use and refactor, and I agree with you. But there must be an option to use expressions with enum parameters. Are you saying that if I want to call my function with parameter choose(Linear,InElastic,InSinusoidal), I will not be able to do it, and will have to use string type parameter instead? This is a serious disadvantage and limitation.

    If you have a return type, what's stopping us from accessing the list directly from Function.EaseType.choice1 ?

    I mean, this isn't a disadvantage at all, why in the world would you want a custom input on something that is an enum? This makes no sense, enums are static, that's how it works.

    If you want a custom input, you just use a regular string like you would normaly, I don't see what's disturbing you here.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Ok, so lets say you have a function "RunMyTween" with enum parameter easing_function. When you call this function, in the dialog you can select the value for easing_function parameter from the list, like this, right?

    But my question still remains - if you need to use an expression instead of selecting the fixed item from the list, how do you do it?

    Yes, this is the example I used, but if you need an expression, I'm not sure why you're even asking this, as you mentioned you have the string var type.

  • > We're talking about a new parameter type, not integrating easing modes to functions???

    I'm not talking about it either. But since you used it as an example, you can have a function which is a wrapper for Tween behavior. It will expect easing mode as a parameter, and this parameter can be enum/list type.

    Oh then my bad. I mean like, there could be a million situations where this might be useful for someone. Tweens can be one of them, but this could be used in literally any situation possible. I don't count how much time I used List in C#, it just feels wrong that we still don't have this option on Construct, you just have to check how much addons use these lists (like the tween addon) or features, to realise how useful that'd be

  • Besides easing modes, what other lists do you want to have in function parameters, can you please give a few examples?

    What? I'm sorry but you clearly didn't read what I've been writing because this has literally nothing to do with the proposal.

    The image I linked about tweening is an example of how that'll look like integrated in the built-in functions, because the dialog you can see right there is literally the same one that we use when making a function call.

    What we're talking here is, like in the image above, a list/switch/enum type of definied choices you can set, in order to have a better workflow working with it, like in the image (for selecting the ease function in this case)

    This system will help a lot if somehow you have to refactor a lot of functions

    This system will also be useful if somehow, these lists could be linked to an enum type file, which then can be imported in that list from this function.

    I mean, it's all crystal clear to me, I'm not sure what you're not getting from it

    We're talking about a new parameter type, not integrating easing modes to functions???