This blog post is licensed Creative Common Attribution Required v4.0.
That's a simple example - TypeScript goes much further, with type annotations for classes, properties, methods, and even generics.
Construct now provides comprehensive official type definitions for its entire API, as well as the details specific to your project. Then you can use an external code editor with TypeScript support, like the free Visual Studio Code (aka VS Code), to edit script files used by Construct. It's so good, we use VS Code to build Construct itself! (And it's also built with web technology being based on the Chromium browser engine, and written in TypeScript itself, which highlights the robustness of these technologies.)
Using TypeScript, tools like VS Code can identify the exact list of every available property and method, and no others. This helps make sure you get your code right and get the right spelling too.
TypeScript has a sophisticated type system that has been refined over the years since its launch in 2012, and it does a lot more than that. For example when setting properties that only allow certain strings, such as the Sprite blendMode property, it can suggest valid strings, thanks to the type definition files provided by Construct.
If you make a typo, normally you wouldn't find out until you previewed the project, ran the line of code, and then got an exception. However TypeScript is able to use type information to catch such mistakes in the editor, even suggesting the correct spelling.
It goes further still, being able to suggest the available event names for addEventListener! It can similarly identify errors inside the editor if anything is wrong, helping you make sure your code is right before you even preview your project.
TypeScript also has comprehensive type definitions built-in for all browser features - so if you want to use WebSockets, WebRTC, IndexedDB, or any other browser APIs, that'll all autocomplete properly too.
Tools like VS Code use the type information to provide lots of other tools too, such as:
And one more thing we added in to help: Construct's type definition files include links to the official documentation and VS Code shows them for you if you hover something, providing a quick way to jump to the reference.
TypeScript is a big improvement to the developer experience when writing code with Construct. Precise autocomplete is one of the biggest advantages, but its ability to catch errors in the editor, and provide lots of useful code editing tools, are also important improvements.
As a big test, we converted our Command & Construct game project to TypeScript, updating thousands of lines of code. It worked out great and helped show that TypeScript support is robust and can scale to larger codebases. In many cases only minor changes are needed, as TypeScript's ability to infer types means it often figures out types automatically without anything needing changing.
Get emailed when there are new posts!
TypeScript is amazing, big thanks to you for officialy supporting it from now on! :)
This is amazing. This is the best update in years! :)
Thank you, brother.
What do you mean by that? How collisions are not supported via scripting?
I do all my game logic solely with code for a few years now, and yes, there is still some limitations and missing API, so you have to mess with events from time to time, but most of the stuff you can do in JS
Now, the issue is that Ashley has focused on other things. Your issues won't be expedited since it is evident that issues and limitations still exist, as was the case with multiplayer issues when Ashley focused on other features. It's not a problem for hobbyists, but for professionals with actual contracts, it's not ideal.
Furthermore, Ashley recommended the full scripting approach in his previous blogs. You actually have to be updated with the current events to know these first.
Contrary to the recommendation, as someone who actually attempted it, there are substantial issues with that, especially being locked out of the event sheet context as a last option when it is evident that the JS Scripting API is heavily lacking compared to the event sheet ACEs. You would inherently be self-limiting and rely on building everything on your own.
There are two approaches to using scripting: one is full scripting, and the other is through the event sheet context. The latter is what I recommend.
"there is still some limitations and missing API, so you have to mess with events from time to time"
You actually answered your own question, try collision performance test with only the JS Scripting API.
This is great progress!