Learn JavaScript in Construct, part 13: Onwards

17

Index

Tagged

Features on these Courses

Stats

4,487 visits, 9,688 views

Tools

Share

Translations

This tutorial hasn't been translated.

Create a translation

License

This tutorial is licensed under CC BY-NC 4.0. Please refer to the license text if you wish to reuse, share or remix the content contained within this tutorial.

Published on 16 Dec, 2021. Last updated 19 Jul, 2024

How event blocks compare to code

Before we finish, it's worth mentioning how JavaScript code compares to event blocks, for those of you who have worked with Construct's event sheets before.

Event blocks are a fundamentally different paradigm to text-based languages like JavaScript. This means there is often no short or convenient JavaScript code equivalent to an event block. This is because event blocks are a much higher level concept than code. A seemingly simple event block can actually involve running a large amount of complex code to do something that seems straightforward in an event sheet. This is the whole purpose of event blocks: by taking care of so many details for you, they make game creation much quicker and easier and accessible to people with no experience of programming at all.

If you're coming from working with event sheets, you'll frequently need to adopt a different approach if you want to do the same thing in JavaScript code, which may take some getting used to. Alternatively you can adopt a mix-and-match approach where you use event blocks for some purposes, and JavaScript code for others. The ability to add JavaScript code in event sheets is specifically designed to help make this mix-and-match approach easy to use.

Here are two examples that demonstrate the conceptual difference between event blocks and code.

Picking

Conditions in event blocks "pick" the instances that meet the condition. Further conditions filter down the picked instances to only those that meet all the conditions. Then the actions run on the picked instances.

This concept of "picking" is unique to event sheets - there is no built-in concept of picking in JavaScript. The same concept can be applied in JavaScript, such as by creating an array of instances, and progressively filtering it down, and then iterating the array performing some action on the remaining instances. However JavaScript code is not typically written like that.

A more typical pattern to use in JavaScript would be to iterate all instances with a 'for-of' loop. For example consider an event block that tests Sprite: X < 500, with an action Sprite: Set X to Self.X + 100 * dt. This will move all Sprites to the right until they are past the X = 500 line. The JavaScript equivalent would look something like this:

function Tick(runtime)
{
	for (const inst of runtime.objects.Sprite.instances())
	{
		if (inst.x < 500)
		{
			inst.x += 100 * runtime.dt;
		}
	}
}

Notice it does not use a picking process - the code iterates every Sprite instance, and inside the loop it uses an 'if' statement to check if it should move the sprite.

On collision

The On collision event actually does quite a lot of work. Is overlapping is continually true while instances intersect. However On collision remembers if the instances were previously intersecting, and is only true the first time they intersect, which acts as a trigger for when two instances first touch.

In Construct's JavaScript API, there is only a testOverlap method, which is essentially the equivalent of Is overlapping. There is no equivalent to On collision: the part that remembers the previous state is part of the event system.

Sometimes testing overlap is sufficient, such as if the objects are destroyed on touching, as they won't keep touching. However when coding in JavaScript, it's up to your code to remember if two instances were previously overlapping and do something different the first time it happens. This highlights how event sheets do a lot of extra work for you behind the scenes to make your life easier than the equivalent in a programming language. Often tasks that are simple in event sheets take a lot more work as code.

Some advice

Here are a few extra bits advice about programming to help you along the way.

  • Programming often requires patience. When things don't work, try to adopt an attitude of being curious to find out what's going on. While it can be an understandable reaction, try to avoid getting angry or frustrated - it will only make it harder to solve the problem. If you need to, take some time out. Often taking a break, or coming back the next day, is what it takes to solve a problem.
  • If you're serious about learning to code well, then try to practice a lot. Writing a lot of different kinds of code to solve different problems is a great way to learn.
  • JavaScript is an old language, having originally been created in 1995. Some older parts of it have been superseded by newer, better features, to the extent there's no reason to use the old features at all any more. One good example of this is how let has replaced var for declaring variables. There's loads of information about JavaScript on the web, but when finding resources check the date it was published - the older it is, the more likely that it would be written differently now. There's also no need to learn about how the old legacy features work unless you have to work with some old code that uses it.
  • JavaScript is also a constantly improving language, gaining new features regularly. However new features don't always arrive in all browsers or platforms at the same time. Check what the browser support for new features is, so you don't accidentally write code that doesn't work in other browsers. Testing your code works in all major browser engines (Chrome, Firefox and Safari) is also a good way to check that.
  • It's great to feel a sense of accomplishment when you write some complicated code that works. However remember that for any given task, the best code is as simple and easy to read as possible while still getting the job done. Good programmers avoid obscure tricks or unnecessary complexity wherever possible.

Closing remarks

This guide has hopefully given you a solid grounding in the JavaScript programming language, while pointing you towards further resources to deepen your understanding of JavaScript. Construct provides a great place to learn to code, allowing you to mix and match event blocks and JavaScript code to help ease your transition to coding, as well as providing an editor and APIs to handle many otherwise tedious tasks of game programming such as level design and rendering.

The JavaScript programming language, and all the APIs available in browsers and tools like Construct, represent a huge amount to learn about. Programming is also often difficult and can be a time-consuming process to get your code right. Finishing this guide is only the very beginning of your journey in to the world of programming. If you're serious about getting in to programming, recognise that like many fields of work, it will probably take a year or more of regular practice to become proficient, and many years further to become an expert. However even with basic skills you can get useful and interesting things done - and you'll be learning skills in an industry-standard programming language, which makes what you learn highly transferable to other JavaScript-based tools and frameworks. And if you go further, JavaScript is the kind of language you can get a job working with!

Congratulations for finishing this guide, good luck with your future efforts and happy coding! 🎉

  • 5 Comments

  • Order by
Want to leave a comment? Login or Register an account!

  • Thanks for such a great series. As a game designer who's written a fair amount of code in Unreal Blueprint, C# for Unity, and Actionscript 3 for Flash, this was a great overview of the basics of JS - the best I've read. Something like this aimed at writing addons for Construct would be very helpful too, but in any case I really enjoyed this. Thank you.

  • This tutorial was long overdue. thx!

  • Hello. Why don't you recommend using for-in? I did not find any article where they preferred to use for-of or Object keys, values and entries instead of for-in.

    Here I found an article with a benchmark, which talks about the results of for-in, for-of and Object keys, values and entries. hackernoon.com/3-javascript-performance-mistakes-you-should-stop-doing-ebf84b9de951

    Object iterate For-In, average: ~240 microseconds

    Object iterate Keys For Each, average: ~294 microseconds

    Object iterate Entries For-Of, average: ~535 microseconds

    Why shouldn't I use it if it's faster?

  • Great tutorial thank you so much.

  • thanks for being with us!