Mikal's Recent Forum Activity

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

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

Mikal's avatar

Mikal

Early Adopter

Member since 22 Apr, 2016

Twitter
Mikal has 107 followers

Trophy Case

  • 8-Year Club
  • Entrepreneur Sold something in the asset store
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Popular Game One of your games has over 1,000 players
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x10
    Great Comment One of your comments gets 3 upvotes
  • Delicious Comment One of your comments gets 10 upvotes
  • Email Verified

Progress

20/44
How to earn trophies