Mikal's Forum Posts

  • Thinking about UE/Unity model more...

    Ashley if you do take the big step and encapsulate everything except API in the future. There may be a business/revenue possibility for Scirra.

    Add a license to get an unecapsulated version of C3. This license could explicitly state that there is no additional support for licensees that work with undocumented features / API. So, it will be very explicit about where the responsibility lies. Also it will _limit_ the number of devs who actually have this type of access to ones that accept the responsibility and also show their commitment via a payment.

    Now to make this have real added value vs the situation we have today where addons can already use undocumented features and make it worth the extra license payment. With the above knowledge about licensees responsibility of using undocumented features and possible feature breakage. This additional license would also provide a C3 editor with code that is _not_ obfuscated. Which would allow advanced devs and addon makers to look at doing more advanced editor customization to improve their workflows.

    So, you would then have a limited subset of devs with the resources to both do / hire out for more involved customization than the SDK allows, ability to pay for the extra license and explicit knowledge from the license agreement about the possibility that they may need to freeze their C3 editor and runtime version due to the customization they have done.

  • The reason I described what UE and Unity approach source code was not a discussion of that vs encapsulation. It is their design philosophy - they are open to people changing their source and engine internals making custom versions UE/Unity possibly without using any official APIs, even if it makes their custom version incompatible with future releases. The devs know they are responsible for the custom versions and they do it when it benefits their game design to add missing features or improve the editor and workflow.

    My hope is you approach us devs in a similar way, we know about possible incompatibility in the future as do UE/Unity devs. As mentioned earlier there could be a completely separate addon repo for undocumented api use with all the caveats around them, so people know they are heading down the equivalent of a custom engine route which may mean they need to freeze their version of C3 if they wish to remain compatible at some time in the future.

  • In regard to industry practice and encapsulation/hiding engine internals, if we look at the 2 largest companies in the game industry, they are focused on keeping the engine and the editor open, accessible and customizable.

    So, that is the current industry standard by the 2 biggest players.

    Unity has source code available for engine and editor in c#. You can also get an option to be able to create a custom version of editor -and- engine built from source that you change.

    UE also has source code available for engine -and- editor and also has an option create a custom version of editor and engine from the source.

    In other non-game engine sw industry of course this could be different, but the majority of the game engine sw industry has a focus on lowering obstructions for the game developers to create great games using great tools.

  • It is interesting to see other very successful engine companies philosophy about access to runtime internals. Obviously, some are many orders of magnitudes larger than Scirra, so going as far as they do, could be prohibitive in terms of support. Their general direction is interesting and informative and you can see they are focused on their users and game developers and shipping games.

    From UE:

    Accessing Unreal Engine source code on GitHub

    Unreal Engine includes full access to the complete C++ source code, so you can study, customize, extend, and debug the entire Unreal Engine, and complete your project without obstruction.

    Ref: unrealengine.com/en-US/ue-on-github

    The main difference I see from the discussions so far is their focus on the user and their game project/product. Ashley - can you, also put yourself in the position of C3 developers trying to ship ambitious games / products (some of your customers, certainly not all) and see how the above UE attitude / philosophy would be appreciated? Or do you consider this sub group of customers not very important in decisions about C3 roadmap (this is not a facetious question, I know Scirra has other focuses towards education, animation, casual hobby devs.)

  • Hope springs eternal...

    Adding distance and height fog to the effect / shader. Banding due to gif compression.

  • Update here's another suggestion to vote on, in case the other one is not implemented (it is more flexible than the other one.) Please vote if you like the possibilities you see here:

    github.com/Scirra/Construct-feature-requests/issues/180

    Another example (added to the 8 frag effect):

    Directional Light (acts like a 'sun' light).

  • Some more non-light examples that would be possible:

    Snow shader:

    Height fog:

  • Ashley - I understand what you are saying and after doing C3 addons for a few years, I hope I have somewhat a feel for how you handle suggestions. In the past I have seen you comment on suggestions, so I was just looking for similar feedback and was not worried if you were not able to.

    I did not imply how hard or simple the change is, I understand there is complexity.

    In terms of making a full 3D engine in C3, I understand that is not your direction. Instead some 3D features are being added and it is great that the addon SDK is being expanded to support other 3rd party devs so they have the possibility to go in the direction of adding more 3D features, which a smaller subset of the C3 community is interested in. This seems appropriate in terms of the philosophy of 3rd party addons for adding features to C3 that are not directly included in C3 or on the internal C3 roadmap. I really appreciate this and the support the SDK already provides.

    In terms of this specific suggestion, I am following your lead here, I am grateful for the addition of the direct-3d rendering SDK support for effects and this suggestion is aligned with that in terms of supporting direct-3d effects in an expanded way that allows for some cool world position based effects. I know it may or may not happen, but I hope you keep it in mind as you update the c3 render engine in the future.

    [As an aside the talk of direct-3d takes me back to the 90s and MS doing a new API too...]

  • Thanks for the reply Ashley. For now I have inserted one of the smaller libraries directly into my addon files and may go with the globalThis for the other larger one.

  • A new, very cool example from Dokse, also uses a form of light pooling to have a lot of lights scattered around the environment (e.g. more that the 8 available in the effect.)

    Subscribe to Construct videos now

  • This is an addon in development.

    Example with kinematic character controller w/ beta version using Rapier 3D physics:

    Example with 3D raycast:

    Check it out here:

    kindeyegames.itch.io/construct-3-cannon

  • Ashley - any suggestions on how to import modules in addons (for example in instance.js)? Right now it seems to work in preview (import * as Comlink from...) However it fails in export (due to fail in workermain.js, unable to Loadscripts, it sees 'import *' as an error).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Ashley any thoughts on this? With your new change we are so close to just having a new effect for lighting. If you are concerned about compatibility, perhaps only use different vertex shader with the aPos pass through when the effect has direct-3d rendering enabled?

  • This works for me, but I need to figure out how to change it during export, besides hacking it.

    import * as Comlink from "https://preview.construct.net/comlink.js";

  • I am having issues importing a local file in an addon, for example in it's 'instance.js' during preview. (e.g. import * as Api from './api.js') - I know that preview mangles file names to blobs, but I thought there was a service worker which helped to make it compatible. Right now it cannot find the file.

    Anyone else do 'import's in addons?

    My workaround for now is importing from a full URL/CDN (which requires an online connection and is slower.)

    e.g. this works fine:

    import * as Comlink from "https://kindeyegames.com/forumfiles/comlink.js";