INTRODUCTION
Be aware, this tutorial is not a guided "how to, step by step"/recipe that will give you the exact same clone once your done with it.
Instead, this is more a guided tour explaining how and why I did what I did.
I will pinpoint parts of the code in different places, but still working together as an ingame system that I planned/designed/coded.
What I'm aiming for with this tutorial is to have a full finished game with an increasing wave system (with background changes), a local score system (using array and Local Storage) as well as displaying those, using three different layouts, which first is a loader/splash screen, having background music and sounds playing (or not), an easy way to pause/unpause the game and having everything done in the free edition, so in less than 100 events and using no more than 4 layers per layout.
There is still room in the current project to add more events.
For this tutorial I've used textures, music and sounds from the Scirra's free bundle that you can find on the here.
You can find the final project in the Arcade and download the capx there (in the arcade page for the game).
I hope to cover some points that beginners often ask in the forum with this tutorial.
Nevertheless, you really should have read and practised the Beginner's guide to Construct 2 before going on with this tutorial. It will show you some of C2's basic work flow (adding sprites/plugins, actions, conditions and events/subevents to a project, importing images/animations, ...) you should already be comfortable with.
I will try to stay logical and go through steps here, but it won't be a guided how-to signalling how to make every single event/action/condition within the editor.
Also, there will be quite some links to the manual or other resources and tutorials. If you are a beginner, really take the time to consult and understand those documents. It will take time, but it's really worth it.
As any learning, learning how to make a game takes time. Fortunately there's all the documentation on the website, just waiting for you to read.
Anyway, it is a massive amount of informations/new knowledge/new things to think about, don't hesitate to pause your reading, come-back to it the next day, even read it/practice it several times.
A lot of making a game is reflection, thoughts, time you think/craft your game in your mind and on paper rather than really "making"/coding the game.
This is part of the process anyway, the more educated thoughts you put into it before starting with the code, the easier the coding part of making the game should be.
Here's a list of some points I want the game to be/to do:
Asteroid clone - base Mechanism
..° Ship moving like in the original Asteroid game (gravity 0-like type of physics, the ship rotates on itself, it can go forward, brake, momentum is present, wraps from one side of the screen to the other; it also can shoot at asteroids), controlled by the player.
..° Asteroids are moving rocks on a straight trajectory, warping on the sides of the screen like the player's ship, each asteroid hit by a bullet splits into two smaller asteroids, or if it is already the "smallest" allowed, is destroyed. Splitting an asteroid score 1 point, destroying an asteroid scores 10.
..° If the ship collides with an asteroid, the ship loses health up to 0 where it is game over. The asteroid is just destroyed, no score added.
Pausing System
..° The player presses "P" in game and everything "freezes" until he presses "P" again to unpause the game.
..° The "pause" must only occur in game, not in between waves (where a "return" input is expected).
Wave system
..° Each wave "spawns" a limited numbers of asteroids.
..° Once every asteroids have been destroyed, the wave is ended, we wait for an input (press return) from the player and we start the next wave.
..° The background picture is changed every wave.
Score system
..° An array containing the 8 best scores
..° A layout displaying the 8 best scores
..° On game-over the player is taken to the scores and his current score is compared to the scores in the array. If the score is greater than one registered score, the new score is put in the array and the former score gets put one row down/out of the array.
..° Scores are saved locally (on Local Storage) so that from a session to another, the player can improve and beat his own scores.
Audio
..° The user can choose if he wants sounds or not (turn it on/off)
..° Music in the background, changing each wave
..° Sounds on some actions (asteroid hit, asteroid destroyed, asteroid in collision with ship, wave end, ship movement, the player presses "return" in the "menus")
Life Bar
..° The life bar represents the value of the ship's instance variable "Health"
Some design decision - I chose not to put sound when the ship shoots for several reasons.
Mostly, I find it annoying. Most of the time in the game you are shooting. A repeating sound can be pretty annoying and also it is not the greatest feedback in my opinion.
Rather, having sound when a bullet hits an asteroid or destroys it (so when the player actually scores) is a better feedback.
The important is not to shoot, it is to hit.
Another decision I made was to use only the keyboard as input.
Sure today's computer have a mouse, but as my basic mechanics are all played with the keyboard, I wanted my "GUI inputs" to be as well.
That's why you press return between the layouts and the wave and don't click on some sprite.
That's why sounds and pause switches have a "keyboard short-cut" and no clicking button.
It's better for the player's comfort as he doesn't need to lift his hands from the keyboard suddenly.
Those decisions were made during the development, not beforehand. This is by testing and tweaking that you come to making those decisions, but it is important also to know why you made those.
I put them here now to kind of put you in the correct state of mind. Focusing your attention on those small details and the reasons why I give credit to them.
And after this motivational speech on carefully spending time thinking about your game, and this list of items I'll focus your attention on one of the most fabulous features of C2 : quick experimenting/prototyping.
There is no penalty for trying in C2, the worst thing that might happen is that when you preview your game, it doesn't behave as expected.
It can be frustrating, but the reward you get when you finally understand why it doesn't and fix your code so that the game executes as you meant it to is priceless.
A sum of new knowledge, experience, a better understanding of the inner workings of C2, of programming, the achievement of your mind overcoming the machine, of having a working game, possibly even a fun game to you as well as others.
So never hesitate to make a new project, throw a few plugins and behaviors in it and experiment, try, toy.
This is what often leads to the first prototypes. A prototype is a first playable representation of your game.
Having a fun working prototype is by no mean having achieved a game yet. It just allows you to display your game idea to other people and have comments and feedback on it.
Nevertheless it is an invaluable source of contentment already and, with C2, allows you to build upon quickly up to the point of finishing/polishing it as a complete game.
Note: All through this tutorial, to have a better look at the images you can right click them, "Display the image".
A revision of this tutorial was made for r210 and the new Scirra Arcade.
Previously, the project used Webstorage, but now it has been replaced with Local Storage and modified to be uploaded in the new Scirra Arcade.