Making games with Construct 2: An introduction

I generally like the ability to read. Not only does it open up a world of written works to me, but it also allows me to process information and turn it into reviews and news posts for this very website. Without the ability to read, I would not be able to proofread this feature and it would inevitably come out to be incomprehensible nonsense.

Not only does it detract from performing the activity depicted in the instructions, but instructions can also easily fall plague to the issue of clarity. If a manual has too much information, the reader inevitably has to pick apart and piece together parts which they find relevant. If a manual has too little information, the reader could easily be left out on very important pieces of information which are considered commonplace or unnecessary to the writer. In all of my time reading instructions, there have been countless times where I wish I could edit or add additions to a specific set of instructions.

And this is a reason why I thank Scirra Ltd., the creator of Construct 2. Rather than just bundle several written tutorials with the game development suite, the company added simple, fully-working examples of the various games and features that the suite can create and perform. By editing these examples in various ways rather than being attempting to follow their instructional equivalents, I learned my way through the Cosntruct 2 suite and learned what could (and could not) be done with the tools.

My journey started with the first example of the built-in eight-directional behaviour that can be applied to game objects. As it was the first time I was using the suite, I took a look at my surroundings while inspecting this example. The first thing that will catch almost everybody’s attention when using Construct 2 will be the ‘Layout’ sheet. Unknown to me, this was the space in which any Construct 2 game would be played. I then noticed the ‘Projects’ window that was to the right of the Layout sheet. This window holds all of important aspects of the current project that is being worked on, including the Layout sheet and the game objects which Construct 2 refers to as, “Sprites.” Believing to have now understood down the basics, I ignored a text-filled window to the left of the Layout sheet and searched for anything that resembled a green stoplight, or more accurately the ‘Play’ button. After wandering around the suite for several minutes, I noticed a button called ‘Run Layout’. After hesitating for just a second, I pressed it and was shortly thereafter faced with a browser window that had the example running, with the arrow keys providing support for the eight directional movement of the character.

With this simple knowledge in my memory, I quickly dashed through several tutorials, learning of the proper name for the text-filled window (the ‘Properties’ window), what a layout was (the area of play of the game), how behaviors modified an object, where all the function executing took place (PS: it is in the ‘Event Sheet’ window), and how plugins changed the entire purpose of a sprite. And then I stumbled upon the series of particle effects demos.

“This is where it gets good,” I thought.

From explosions to water fountains to smoke, those demos showed me all of the neat tricks that particle effects could do. They were also very easy to make; just choose the particle effect behaviour, edit some properties, and presto! Your very own particles are displayed in the running layout. However, the particle effects were just that; neat tricks. In practical terms, they were useless features. So I decided to turn down my enthusiasm and be on my digging through the rest of the examples.

I should have been excited for what came after the particle effect demos, which were the pathfinding examples. Not only did the pathfinding demos showcase good pathfinding, but Scirra Ltd. had cleverly added a path cost function that quickly decided whether or not to journey around a slowed space or travel straight through it. This was something that was practical and something that could be used in more complex games, like an real-time strategy game.

What followed the pathfinding demos were examples of the physics engine that is built into Construct 2. These examples showed nothing out of the ordinary except for a bizarre showcase of a rotating platformer. However, something that was worth taking note about was that literal sprites also act as the 2D models for the physics engine. Simply changing the tool in the custom sprite editor allowed for manipulation of model hooks, which if moved change the barriers in which collisions would occur.

Beyond the following series of demos which showed a platformer in different stages of its evolution, a small amount of examples were placed for showcasing the ‘Sine’ behavior that could be placed onto objects. Simply put, the Sine behavior allows for objects to wave back-and-fourth in both random and non-random cycles. (One example of this behavior showed an effect that gave the impression that grass was waving in the wind.) While extremely cosmetic, this behavior could be used to good effect if implemented properly.

After the Sine demos came a series of that tried to use the capabilities of webcams. I say, “Tried,” because none of them worked. At all. I have no idea whether this was because of my hardware or because of the suite, but regardless nothing particularly interesting happened. After several other examples all showcasing relatively minor features, the examples came to a close with a series of demos of the WebGL showcase.

WebGL, for those uninitiated, stands for ‘Web Graphics Library’. Although it could be programmed all by itself to run a game, Construct 2 only used WebGL for distortion effects. And while these effects were neat and could be used to enhance a product, they by no means would help in the creation of a great game.