skymen's Forum Posts

  • This doesn't have to be something completely open in the public if there is a fear of discussing features that might never actually arrive, but maybe specific people like R0J0hound, Overboy, skymen, Mikal, etc. could be involved in giving their thoughts and early feedback before production even starts (If they would be willing to spend some of their time on this).

    I would be very down for this to be honest. I know other engines have a similar thing with an insiders program, where handpicked ppl have a communication channel under NDA.

  • I understand where you're coming from Ruskul but I don't necessarily agree. I don't think it's fair to try to strictly apply code architecture principles to Construct's Event sheet system as they have been written with typical coding languages in mind, and not event sheets.

    Instead I think it's far more sensible to apply a set of new coding principles that are designed around the event sheet and Construct's addon architecture instead.

    The idea that because you might outgrow an addon then you should absolutely avoid it doesn't make sense to me. If you truly have a good reason not to use built in features, I think writing a new behavior is a far better idea than trying to handle everything using events.

    I have seen projects scale just fine within Construct's features, but it implies that you need to design your architecture around what's there, not around arbitrary coding style made for other software development environments.

    However, if you would rather stick to paradigms you are already familiar with, then I would agree that maybe construct events aren't the best choice.

    About scripting, while I agree that it's lacking in some aspects, there are many ways to extend it and break free from many of its limitations. In this aspect, since it's all JS, the sky is the limit with what you can do. Especially if you would rather ditch behaviors and write your own systems, I think writing your own behaviors in the form of scripts can fix whatever issue you have with the program.

    Also, with the recent addition of TS, and with the VS Code extension, I think Unity C# with Visual Studio isn't that much of a better coding environment compared to C3. The only thing maybe is that it doesn't integrate into the editor, and C3 scripts aren't treated the same way as Unity scripts.

  • I recommend any JS dev to give my framework a try, as I feel it can make the process a lot more fun and less cumbersome. I also hate writing a lot of boilerplate.

    My take on what should be addons and what should not is that if other people are able to use a system without context in unrelated projects with no deep understanding of what it does under the hood, then it should be an addon. Otherwise, it should be a JS module.

    A while ago I wrote a lot about how to design code in Construct to be modular on many levels, but a lot of what I wrote is outdated, and I think there is a lot to be taught on that regard considering what Construct 3 has become in recent years.

    Overall I think most of the issues people have been complaining can be solved by Brackeys type community members teaching people about the software and writing tools to cover more and more blind spots.

    So I don't even think the burden lies on Scirra, instead IMO they should focus on doing whatever the **** they've been doing for the past 15 years.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You want the 99 that didn't to love your product. So forget the Unity types and go after the 12 year olds who's parents buy RPG maker for them.

    I don't necessarily agree. The 99 don't look at products to know which engine to choose, they look at games they love and try to replicate them. With close to no successful indie titles made with Construct, the 99 will flock to Game Maker, RPG Maker and Unity instead.

    In fact, only reason I ever used Multimedia Fusion 2 was because of I Wanna Be The Guy and only reason I switched to Construct 2 was because of I Wanna Be The Boshi.

    What I mean is that while Construct's accessibility is a big plus, alone it doesn't sell the engine. Convincing power users will make the engine look more capable, and will in turn motivate beginners to give it a try.

    Another recent example has been Five Nights At Freddy's making a horde of new users flock to MMF2 in the past 5 years. Undertale made ppl flock to GMS and Friday Night Funkin made some beginners want to learn Haxe!

  • Jumping in;

    IMO the game engine market is rapidly evolving and I am very worried that Construct will not be able to keep up with engines like GDevelop or Godot being supported by grants and donations, eating away at significant chunks of market share.

    The free version of C3 as it stands is very limited and I understand that it is not something that can change without reducing license sales. However, have you considered doing a timed "free trial" of a paid version? Something like 14 days of having the full engine unlocked, once per account before having to pay for the full thing. It would make it far easier for a lot of us to recommend the engine to developer friends looking to try it for real.

    On another note:

    I'm also working on something else to highlight games made in Construct, but it's going to take some time to put together.

    Laura_D if you need me to hand over the work done on madewithconstruct.com , its database, or its domain name, let me know and I will gladly do so.

    Also, on the topic of recommending the engine, I was at the poki office 3 days ago (Poki is a web games portal I've been working with for a while: poki.com ) and I made a presentation about the work my company has been doing to push web games forward and a lot of that talk has been Construct related. It has also sparked a lot of discussion with Poki staff about the state of game engines for web games.

    I am planning on sharing that presentation in the following weeks, as it's not exactly geared at web games but rather games made with web technologies.

    In general, I think changing the appearance of Construct can be a community effort, because at the end of the day, an engine is only as good as its community. I'm not as active on the forums as I used to be but that's something that's important for me and it's why I've been working on so much free open source things around Construct. We cannot recommend an engine to power users without power user tools and tutorials, which Construct severely lacks.

  • Chiming in on the topic of 3rd part developers taking some of that weight:

    I've been contemplating making a brand new Steam NW.js plugin around the new steamworks.js which seems to be much more actively maintained.

    My main issue right now is that I have never used the lib before and I don't have much time to learn it, and don't think I will have much time for it for at least a few months.

    That being said, if someone else has time for it, we've recently set up an Open Collective to crowdfund Free Open Source 3rd party stuff for Construct with some folks in the Construct community.

    I invite any dev that would be up for the challenge to reach out and we can set up a project for them (we've already funded one project and others are on the way)

    opencollective.com/construct-community

    That way everyone could chip in to fund the development of this new plugin and it could resolve that issue, while also avoiding long term issues that come with important addons like these being closed source and abandonned after a few years.

    On an unrelated note, I would also like to add that indeed the lack of File System access for the WebView2 export is sad. I already advocated for Tauri as an alternative to a custom export maintained by Scirra as it would make developing addons for it much easier. Tauri has the same benefits as the Cpp WebView2 export, but also has full File System access (as well as a bunch of NW.js equivalents) it also has cross platform support, and lets you write Rust which means extending the app with native stuff (like steam support and such) much easier for 3rd party devs.

    I understand that using Tauri might also come with a bunch of challenges of its own. Also Tauri suffers from the same issue Ashley's WebView2 wrapper has with Steam overlay.

  • Ah well, I don't know how easy it is to detect Proton :/

    + even if you were to detect proton that wouldn't even give you any info on wether you're running on a regular Linux machine or on Steamdeck.

    I guess we're back to trying to implement steamworks.js

    The alternative would be to do some machine profiling using CPU, GPU and screen size info to try and make an educated guess but that's not really a great idea.

  • Nevermind, run this function and it should work 

    function isRunningOnSteamDeck() {
 try {
 let os = require("os");
 let info = `${os.type()} ${os.release()} ${os.platform()}`.toLowerCase();
 let list = ["valve", "steam"];
 return info.includes("linux") && list.some(x => info.includes(x));
 } catch (e) {
 return false;
 }
}

console.log(`Is running on SteamDeck? ${isRunningOnSteamDeck()? "Yes" : "No"}`);

  • Hey,

    Greenworks doesn't support that method. It was added in SDK v 1.52 and greenworks support stopped at 1.42.

    The best solution would be to write a new Steam addon using steamworks.js (or implement that directly)

    github.com/ceifa/steamworks.js

  • I've talked about this subject in the past and made a feature request in a past suggestion page.

    I also looked into it and tried to hack it into the engine, but from what I've seen it's pretty hard if not impossible to do with the way C3's rendering is done at the moment.

    I agree it would be really useful if this became a thing.

    Mikal and I both experimented with making pixel shaders that can repixelify a layer with linear sampling. That might be worth a try.

  • As I stated in the github report, I really think UIDs hold C3 back in many ways. I understand moving everything to UUIDs can be a big change, especially for backwards compatibility, but the alternative is trying to do a band aid fix that will not work.

    I full agree with Tokinsom here, UID shuffling makes C3 unusable with source control nowadays, which is a huge issue.

    For backwards compatibility, UIDs can stay, and UID shuffling can also be kept for a while, but instances should start getting referenced using UUIDs or SIDs (like object types and other editor elements), especially internally.

  • You do not have permission to view this post

  • That code uses undocumented internals of the runtime. Do not do that! It can and will break at any time and we will not provide any support either.

    Oh yeah for sure forgot to specify. I just assumed that was a given, forgot we were in a big thread with many people that check in while not necessarily being aware of that.

  • While I agree with the fact that it should probably be added as an action, if you need this for any reason, know that it's fairly easy to do in JS. 

    let templatePerObjectClassMap = c3_runtimeInterface._localRuntime._templateManager._templateDataMap;
for (let templatePerObjectClass of templatePerObjectClassMap.entries()) {
 let typeIndex = templatePerObjectClass[0];
 let objectClass = c3_runtimeInterface._localRuntime._allObjectClasses[typeIndex];
 let templateMap = templatePerObjectClass[1];
 for (let template of templateMap.entries()) {
 let name = template[0];
 let data = template[1];
 }
}

    if you know the object you wanna check (which you most likely do) you can get its object class using 

    	let myObjectClass = c3_runtimeInterface._localRuntime.GetInstanceByUID(uid)._objectType

    you can now check if the template name exists by doing something like 

    function templateNameExists (objectClass, name) {
 let templatePerObjectClassMap = c3_runtimeInterface._localRuntime._templateManager._templateDataMap;
 return templatePerObjectClassMap.has(objectClass.GetIndex()) && templatePerObjectClassMap.get(objectClass.GetIndex()).has(name)
}