Mikal's Forum Posts

    Looking at some of the sample v2 addons, I notice that this is removed: 

    GetScriptInterfaceClass()
	{
		return self.IMyDrawingPluginInstance;
	}

    My hope is that is because the scripting interfaces for addons will be 'automatically' generated somehow. Is that correct, or is there something else happening?

    Will Scirra provide assistance to help with porting from V1 to V2, besides the very simple SDK examples?

    Is there a possibility to make a 'wrapper' around V2 SDK to support previous V1 SDK addons or at least for the vast majority of the V1 SDK?

    Can Scirra create a script or tool to translate the majority of an addon (and add comments or highlights where the translation is not possible via automatic translation).

    Ashley - please take a collaborative look at the SDK V2 requests - realize that they are not trying to prescribe your SDK V2 design, they are requests for functionality - which could be implemented in different ways. If the request does not map directly to you design, can you please consider other methods or alternative approaches to the functionality that can be used. We want to work together with you as you promised and make SDK V2 powerful and useful for the new addons which use V2.

  • See the latest release for initial 4.2 runtime and physics support. If you see an issue, please share your 4.2 physics project with information about expected behavior. You can post link to project or send me a DM at Discord (I an in Construct community server.)

  • How would you process the data? Use events or JS?

  • Which version of C3 were you using?

    The update was a change specific for r389, if you were using an earlier version, it would not work.

    Today, I just added a new release 1.819 which is backwards compatible.

    If you see an error, report:

    - C3 version used

    - Platform (mac/win/mobile)

    - Errors seen on devtools console:

    developer.chrome.com/docs/devtools/open

  • Released fix for r389+:

    github.com/ConstructFund/proui

  • Hi Mikal, can you help me?

    my character wears Spine physics in her hair, but doesn't construct the physics doesn't work.

    What can it be?

    Physics are not implemented yet in the addon, I'll need to add 4.2 support, but busy at the moment.

  • Added optional functionality to codesign the fat app (tested with adhoc signature).

    We found that on ARM MacOS codesigning is needed to correctly handle permissions.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The retro style is so well done. The grainy noise really hits. How do you create your nice detailed level, do you do in C3 editor or external tool and import?

  • I didn't see the MacOS nwjs universal app binary available yet, so I created a tool that can combine two c3 MacOS arm and intel exports into one fat binary. Don't package the C3 nwjs exports.

    FOSS tool - so C3 could integrate if needed/wanted.

    github.com/MikalDev/fattennwjs

    Tagged:

  • Nice work!

  • So, as I said before, we are not actually going to remove all undocumented features in the next release. However we will move forwards with a plan for a v2 SDK over the next year or two, which should give enough time to design a suitable SDK and deal with the inevitable difficult backwards compatibility issues that come up. Let me be clear: we did not have to do this, as we reserved the right to say "tough luck". However as it is clear this is untenable and obviously unpopular, we are promising to do the necessary work to make sure this transition goes smoothly. This does mean designing a new API in co-operation with the addon developer community, and I would hope this ultimately ends up a comprehensive, capable API that does pretty much everything addon developers could reasonably want to do, short of unfettered access to the internal engine. I would ask for co-operation during that process so we can end up with a reliable, robust, maintainable SDK in the long run, and not the risk of disaster that we are constantly running at the moment.

    Thank you Ashley, I appreciate this response and I look forward to co-operating with this effort and helping out with the process as it moves along, whether that is adapting addons to a new C3 SDK, offering suggestions, explaining what features would help port addons or sunsetting addons which can no longer be supported with the new SDK.

  • 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.