TackerTacker's Forum Posts

  • First let me say that I love the Instance Bar feature, and even if nothing changed it would already be a big help. That said, here are some things that would IMO help to improve it further.

    I like all the functionality but the UI/UX needs to be improved IMO. The view feels pretty cluttered with lots of repetitious information, and I think the switching between different "show more info modes" is unnecessary.

    Why write "Showing more information for: Something" at the bottom when that space could be used to actually show more information.

    Putting a general infobox at the bottom similar to how it already works in the Properties Bar would free up the clutter a lot. It's important to easily get to info quickly, but that doesn't mean it has to be everywhere all the time.

    Here is a mockup of my improved UI/UX suggestion:

    Every menu item is made up of 3 sections, furthest left are the layer icons ( Locked / Hidden / Global ), in the middle is the actual object with the icon and its name, and on the right are all the extra icons ( Hierarchy / Template / Timeline / Plugin / Mesh ). The extra icons on the right are always visible if they apply, so if the object is in a hierarchy the hierarchy icon is always visible, no switching between "info modes" needed, if there is a mesh on the object the mesh icon is visible (forgot to add the Mesh icon in the mockup), etc. All the other text for more info will be shown in the bottom infobox when an object is selected

    In addition to that icons are clickable too. It really speeds things up having the most used functionality just one double click away instead of having to right click and search through a long list of options (which is also great for more fine control).

    Double clicking on these icons would do:

    • Hierarchy icon = Select all children.
    • Template icon = Apply changes to all replicas ( Maybe a bit too dangerous? ).
    • Replica icon = Sync this replica with template.
    • Timeline icon = Open timeline.
    • Plugin icon = The same should happen as if you double click that object in the Project Bar.
    • Mesh icon = Toggle between edit/stop edit mesh.
    • Object name = Rename object.

    I'm sure I forgot something, but I think it gets the idea across.

    Show all relevant icons at the same time,

    split the icons between left and right side of the object,

    double click on icons has functionality,

    additional info text goes in the bottom infobox.

    I feel like the LTS versions address a lot of my concerns and are a good compromise, together with the ~1 year transition period to SDK v2 it should be enough time to reduce the damage to a minimum. 1 year is also a long time for Scirra to keep up their promise, if they take the time to add some of the addons officially

    the next release includes a 'Reset' action for event variables, so that it is no longer necessary to use an addon to do that.

    and add missing SDK features to fix others,

    Part of the project of the Addon SDK v2 is to increase the existing API surface to make sure it's more capable

    then I'm hopeful for a smooth transition.

    The only thing left that I feel is not addressed and where no compromise is found yet is that the addon devs will lose a lot of potential to deal with issues the community has, they lose a lot of access and power.

    I wish a compromise could be found for this too.

    I know Scirra wants to "increase the existing API surface", but that's obviously an ongoing process that is already happening for as long as C3 has an API. Which wasn't enough, and is the reason why addon devs had to use undocumented features in the first place.

    Just trying to lock them out doesn't seem like a great solution to me, especially when I already read that people seem to have a lock pick for it already.

    Maybe there is a way to still allow addon devs access to internals for them to tinker with, but they can't publish those addons for normal C3, instead it's a way for them to then ask Scirra to expose the needed functionality in SDK v2.

    This way the SDK could naturally grow in a way that is most useful to addon devs and at the same time reduces the load on Scirra because they don't have to just expose everything for SDK v2 to make it useful and addon devs wont have a reason to use the lock pick, because if that happens we are back to square one.

    In my opinion that could be a good starting point for the API. On paper, I should be able to entirely re-build a build-in addon from scratch, only using the documented API. If something is missing, then it should be added.

    Wait? Shouldn't that be the minimum? How are you suppose to extend C3 in any meaningful way with an API that isn't even flexible enough to create its own existing features?

    I thought these discussions are about things like Skymen hacking in the ability to have different sampling modes on different layers. Things that currently aren't possible.

    github.com/Scirra/Construct-bugs/issues/7965

    OhhBaby This is my bug report and I actually think the answer is okay, it's honest and straight to the point. I agree that the suggested solution is not a great look though.

    I posted the solution R0J0hound came up with in the comments of the same bug report to keep it all in one place, the bug report was already closed though so I was aware that Scirra might miss it. My plan was to wait one update cycle and then open a new issue with the suggested fix while linking to the original report, I have not done that yet though.

    We have been through this process before, with all addons needing upgrading for moving from C2 to C3

    And by we ...you mean the addon devs, or did you port all the Rexrainbow addons?

    I'm not an addon dev so I can't speak on a technical level, but I still see something odd here...

    Ashley you've put so much work and effort into making C3 extensible, but then you completely disrespect addon devs time or concerns. Like... I do not understand who all this work you are doing is for?

    It can't be for the addon devs, because everyone that's still left is in this thread complaining about it, and not wanting this to happen.

    Thank you. I also disagree that it would necessarily reduce Scirra's profits, obviously this is all just theory, but a monetization model that is fair would bring more customers IMO, and more than they would lose from people who might skip an entire year worth of updates.

    Affinity got popular because of their monetization model.

    Scirra would just need to do it right, they would have to do some market research prior to it to see if that theory is correct, if they would reach more customers with this ( I think they would, but I'm just a single person ), and if the market research is positive, switch to that model and make a bunch of noise about it, not just silently switch over.

    But even if they simply switched silently from one day to the next, I do not think they would lose much money, but gain a lot more acceptance. I agree that if they would make it monthly that a bunch of people would buy 1 month and then stay on that version for a while, but if it stays yearly ...why wouldn't you pay for it the next year if you plan on using it?

    Your only option to save some money is to stay on the old version for an entire year, if you buy it any later you still pay the same price but didn't get any updates for a while, so why not pay straight away?

    But for the user it's much better this way because they know they will never lose access to their work and what they paid for.

    No, that's not what I'm suggesting?! Did you read my entire post or just the responses?

    IMO there are multiple ways in which Scirra could improve their monetization model to make it more fair for their customers. Yes, one of the things I mentioned is the model Affinity is using, a YEARLY one-off payment. Which isn't like C2, C2 was a one-off payment ...Period. Scirra is basically already doing the Affinity model, charging 1 entire year upfront, but with Affinity products you still own the thing afterwards, while with Scirra products you don't own anything.

    I also made other suggestions to at least improve the subscription model if they don't want to let us own the software. I can't know what Scirra does or doesn't do, and neither can you. I just make suggestions and hope Scirra considers some of it.

    I only care about game development and game developers, and that is what I'm advocating for. I have a hard time figuring out who you are advocating for, is this an Ashley or Tom incognito account?

    I say please let us freaking own the things we pay for ...and you go "Naaahh dude, that's crazy talk", why would you suggest that? xD

    Like I said, Affinity charges for an entire year (which Scirra basically does too) and you pay for the updates of that year but afterwards you keep the product you paid for. So if someone paid for a year, and the updates don't add anything of significant value to them, why SHOULD they have to keep paying after that?

    Why is Scirra (or any software sub) forever entitled to a recurring payment from someone just to keep access to their own work?

    If, as you say, people HAPPILY stay on the current version forever... what the heck are we paying for? If the updates are really this worthless to you why do you defend paying for them? Sorry, but I really do not understand the point you are trying to make.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    The frequent updates benefit Scirra at least as much as they benefit the users.

    They get free QA through community beta testing and don't have to test as thoroughly.

    If you take out those beta releases the update frequency is already at roughly every 3 month, I don't think they would go lower than 4 updates per year.

    There is a reason why people hate the subscription model. It's the worst monetization from a consumers point of view, especially in the way Scirra has implemented it. Usually you at least only have to pay a small fee monthly so it gets spread out more, but with C3 you have to pay for a whole year upfront. I know there is a monthly option, but it is not actually an option since it's over double the price. If Scirra at least gave the option to sub for a year but pay monthly, but they don't even do that.

    Then they also lock people into their subscriptions by making them lose their legacy subscription price if they want to pause their sub.

    Those things are on top of the problems that every subscription based model has, like the fact that you don't own anything.

    I will always be able to open, edit and export my old C2 projects, but not with C3, with C3 I lose all my work as soon as my subscription ends.

    Yea maybe not literally, because I can still open it. But effectively, since I can't do anything with it, can't edit, can't export, nothing. Also if Scirra would ever stop existing for any kind of reason, you can't even pay for the privilege to get your work back.

    And it's not like there aren't other options, you have to pay for Affinity products yearly too, but you own that software plus 1 year worth of updates. It's the same as the sub model, but at the end you own the version you paid for forever, you will always be able to open and edit the work you did with this version of the software.

    This monetization model aligns much better with customers as well, if the new version doesn't have features customers are interested in then they might stick to the old version for a while or even skip a year.

    It's not just the price, it's a bunch of issues that work great for Scirra but really suck for customers, and there are plenty of options of which each would make it less lopsided.

    - Make it possible to have access to the versions you paid for even after a sub ran out. ( Give ownership over the things people paid for )

    - Make yearly subscriptions payable monthly. ( Only having to pay a small fee every month is literally the only good thing about a sub and Scirra doesn't even allow that )

    - Make the monthly option more expensive but not by over 2x ( Give people the option to pay when they need the tool and not waste money on something they don't use )

    - Stop hiking the price only to lock people into their subs and to stop complains ( A dark pattern to make price hiking easy because it only affects future users, the people already paying stay on the same price and wont complain [ also makes it impossible for people to take a break from the sub in fear of losing their legacy pricing ] )

    By switching from a sub based monetization to one-off payments that renew every year (like Affinity), Scirra could turn its monetization from the #1 reason why people don't recommend Construct, into the #1 reason why people buy it.

    All while still basically charging the same money.

    The difference is that it's a fairer model, with ownership and agency for customers.

    very basic IAPs and Admob.

    dop2000 What do you mean by that? Personally I hate ads and wouldn't add them in my games, but looking at the IAP plugin, if this plugin would be working on web, and not just mobile, I would already be very happy. Or am I missing something?

    What features are you missing when you say it is basic?

    Do you mean that it doesn't have this entire list of Ad networks? IMO it is unrealistic for Scirra to implement and keep up to date every existing Ad network, I think if they have a solid implementation for one that's fair.

    But web currently has none, no authentication service, no IAP or any payment integration.

    Chadori is great and the 3rd party addon creator that I would trust most with monetization addons, but IMO 3rd parties should be a complementary alternative to the available official solution and not the only available option for something this crucial. Not to mention the issue of trust with something security related.

    Maybe Scirra could at least add a seal of approval in the C3 store for monetization (or other security relevant) plugins, where they check if those plugins are handling things properly and are risk free for Construct users.

    TBF Scirra did just create the pipeline for people to at least create their own Steam integrations with the C++ extension SDK, but it's only for WebView2 so windows only, I personally don't care about macOS, but no Linux / Steam Deck is very bad. And who knows what kind of macOS based gaming things takes off in the future, making Mac more important again too.

    So it's again Steam support* with a big fat asterisk. I know Scirra doesn't have control over it, they can't force Microsoft to add Linux support. But for us it stays the same, a game engine with minimal and problematic Steam support.

    Was it not possible to make this C++ extension SDK for NW.js? I literally don't care at all about the "advantages" of WebView2, I don't care much if a game is 300MB or 1GB bigger and I certainly don't want WebView2 to auto update the browser version my game relies on without my involvement.

    But let's say it's currently literally impossible to create a fully functional Steam plugin for HTML5/Web games that works on all platforms, then play to the strength of C3 and give us some kind of web monetization plugin for browser games, or work on the Scirra arcade some more to integrate easy monetization into that, talk to devs and ask what they would like to see and what would be useful to them. How about a plugin for itch.io? Again a big indie platform that's especially liked by C3 devs where Construct is the 2nd most used game engine.

    There are a bunch of monetization plugins on the Store, but I don't trust them at all.

    Some show in screenshots that you need to copy paste the secret key into the plugin itself, Idk much about this stuff but even I know that's not good. Every documentation I've read about this says that you shouldn't store the secret key client side, It's not a save way to do it. Again I wish some kind of service would come from Scirra directly, how am I suppose to know which 3rd party addon I can trust and is save to use? It's one thing with some plugin for the game, either it works or it doesn't, but these types of plugins are about security. Another way could be Scirra getting in contact with 3rd parties asking if they would be interested in providing addons for their services on their own, if it is officially from the actual service provider then it would also be more trustworthy.

    The only fully working, relatively easy monetization option in C3 afaik is mobile. I personally don't care about mobile and never really looked into it, so I just assume it works, because I didn't hear much complains about it.

    ...besides the usual iOS pain.

    Ruskul I'm not saying it isn't possible, clearly it is since there are a bunch of Construct games on Steam. I'm saying it is low priority for Scirra.

    To prove my point I invite you to open a project, right click in the layout and click "+ insert new object", scroll down until you get to the category "Platform Specific" and insert the Steam plugin.

    ...problem is, there is no default Steam plugin (unless you already installed an extension from the addon exchange).

    As long as I can remember there was always some kind of problem if you wanted your game to work on Steam with overlays and everything.

    The Steam overly not showing up, you always needed very specific NW.js + Greenworks version combinations to get it kind of working ...but maybe streamers or youtubers couldn't record your game anymore or only with weird workarounds.

    Now the official Steam addon that works with NW.js has this warning

    NOTE: this plugin is no longer actively maintained, and where possible we recommend using the Steamworks for WebView2 plugin instead.

    So we are expected to use the WebView2 version, which doesn't support Mac or Linux and therefore also no Steam Deck.

    And all this to get the absolute bare minimum of Steam API features. Basically just achievements and some basic use info stuff.

    No Steam Input API, nothing to help with Steam workshop integration, nothing to help with remote play together, etc.

    But I get it, other engines have entire teams dedicated just to platform specific things, and for Construct just 2 engineers have to do this stuff on the side.

    But then you get updates that add a BBC micro:bit plugin that reminds you that Scirra's priorities and goals doesn't necessarily always align with your goals.

    One thing is for sure, Scirra's priorities and goals would be much more in line with those of game developers who want to make a living with their games if they would have chosen a "free" monetization model with revenue share.

    How C3 users are able to monetize their games wouldn't be an afterthought like it fells now, it would be the #1 priority.

    The Steam support would be rock solid with support for the entire Steam API, there would be options for monetizing web games and/or official integration plugins for payment providers, increased efforts for console exports, an interest in collaborating with fitting 3rd party platforms and potential partners, etc.

    Also Unity was perfectly profitable for most of the time, it only went downhill once the previous owners wanted to cash out by going public. They hired a CEO that knows how to pump a stock and that's what he did, by overspending on irrelevant company acquisitions to create a narrative that's enticing for investors who have no idea about game development. They had all pulled out their money by the time it all collapsed, and the CEO got a big fat severance pay before leaving.