+1.png)
Make a SNAKE clone.
Why SNAKE? Because the game utilises the basics of game engines and game design. The player moves faster through the use of a formula, collisions must be handled for the game to function, and there is emphasis the states of a game. It is a solid test for both testing game-making suites and custom game engines. For the reasons listed above, this is the first game I plan make using Construct 2.
The game design of SNAKE is fairly easy to grasp for anyone
who has played it or its clones. The player starts as a one-block-by-one-block
head. By eating the fruit that is randomly placed in the playing field, the
player increases his/her speed and also gains an extra body segment. If the
head of the player either runs into one of the walls or another body segment,
the current game ends and the player is sent back to the title screen.
There are four main game objects to this design; the player
head, the body segment, the wall, and the fruit. Everything else that could be
considered an element of the game (IE the title screen, scores, etc.) are all
secondary to these four objects. I start with designing the player head,
arguably the most important object in the game. What I have found in creating
SNAKE with other tools is that it is usually easier to have many aspects of the
design to be controlled from the player head, as many functions of the game
directly affect the head. So that is my first goal; creating the player's head.
+5.png)
Construct 2 has an unusual way of programming. Although I'm
not extremely well-versed in the system, all of the programming is represented
in what Construct 2 calls an 'Event Sheet'. In this event sheet, users can
create events that can have multiple conditions to trigger and multiple actions
that the event triggers. From what I can tell, this event sheet is the only
“File” where the programming code is placed. If you're more familiar with
traditional and statement-based programming it is a bit jarring to transition
to this event-based system, but it is manageable.
Ignoring a brief moment of confusion and an expressionless
face, I am easily able to dive into the event sheet and produce an event that
allows for a switch to be triggered that tells the player head game object when
it can jump to its next position. Of course, I had to trick the ‘Update Every X
Seconds’ command and input a formula dictating how fast that updating should
occur, but it achieved the desired results.
A brief and successful test later I am now onto creating the
events which tell the player head to jump to a relative position based on a variable.
This was fairly easy, but I was snagged by a slight problem; there are no
clearly-defined IF statements in Construct 2. In programming, IF statements
lock specific code behind a variable-checking gate. If the variable check comes
out as positive, then the locked code is executed. If negative, then that code
is skipped over. It did take me a few minutes, but by adding a sub-event to a
simple variable-checking event you can achieve the same type of effect as a
traditional IF statement.
+2.png)
Or so I thought.
The first issue I ran into with my grey walls was placing
them around the level. Originally a 32-by-32 sprite, my wall did not fit like a
glove on the sides of an 800-by-600 layout sheet. (a ‘Layout
Sheet’ is the area in which a game takes place.) I originally just started to
copy and paste more versions of the grey wall, but upon realising that I would
have to continue to place dozens and dozens of those little walls and line them
up exactly for collision detection purposes, I became very ill and decided the
only cure was a traditional programming loop.
Surprise surprise, Construct 2 doesn’t have any programming
loops. In traditional and statement-based programming, loops continuously perform
an action until a certain variable value is met. They are very useful for
overriding the manual labor of tedious and repetitive programming, which would
solve my issue of placing the walls in my SNAKE clone. But as Construct 2
doesn’t have any loops, I would have to suffer the manual labor of individually
placing all those tiny grey walls. Frustrated, I took several dozen minutes
before I came up with what I thought would be an alternative and workable
solution to my wall problem; stretching the wall object.
This did not work either. For some reason, stretching a game
object in the layout only stretches the collision box to a certain extent. This
limit does not cover the whole object if the object is stretched to a very
large size, such as more than 20 times its original width and/or height. Due to
encountering another faux-solution, I decided to just change the walls to two
different game objects that would have appropriate collision boxes based on
their individual sprites. This finally gave a workable solution to me problem
and I was thrilled.
However, in-between all of this fiddling in creating a
working wall, I noticed a glitch with the player head; if the player does a
half-circle of keystrokes, they can end up moving in the opposite direction
that they were previously traveling in. This is very bad as since the
as-of-yet-to-be-implement body segments will be following the player head from behind,
the player could accidentally hit a combination of keys that would make them do
a 180 and lose instantly from hitting a body segment without any warning. Puzzled
with this new problem and still slightly frustrated from my adventure in
getting a wall to act like a wall, I decided to end there and be done with my
game this week.
Come back next week to (hopefully) see the end of the making of this SNAKE
clone and actually play a semi-finished project created with Construct 2.