Tutorial
(^62) July 2018 raspberrypi.org/magpi
WALKTHROUGH
simply give ourselves an upward speed and when gravity
is in effect, we deduct it from the character’s current
speed, creating a reduction in his upward motion until it
eventually goes negative, causing him to fall.
By adding a Speed value to the co-ordinates of our
character, we can get much smoother – and, later,
timed – movement in our characters. We can also
use this speed concept for left and right motion,
using friction to reduce it. The source code for Bob’s
movement shows this principle for both vertical and
horizontal movement.
What am I standing on?
Testing the tile relies on us knowing the reference
point of Bob. Usually that’s the centre of the sprite,
so a simple offset of half his height will get our testing
point to be at his feet. In fact, we should add an extra
one pixel, since we want to test what’s just below
his feet. Also, since our sprite is wider than a tile, we
should really test a few points to make sure that if any
part of the main graphics that make up the sprite are
on a ground tile, we prevent the fall.
Now we have gravity, jumping is a simple case of
giving him an upward speed that initially overcomes
the force of gravity, but which is constantly reduced
by gravity. With the result that what goes up, must
come down, until it lands on a ground tile.
Jumping and climbing both start by pressing the Up
key, so clearly a decision needs to be made when Up
is pressed to determine if we climb or jump, and that
will depend on our test of whether we are on a ladder
or not. In order to climb a ladder, we must know which
tile represents the ladder, in this case tile number 14.
Now, that is fine – we can test for our offset in the
array to see if it has hit that tile number and if the
correct up/down keys are pressed when were are over
or above a ladder, we can change state to climb – but
what if we have more than one ladder type? (We don’t.
But... what if we did?)
That’s a lot of ifs
Our map is fairly simple, but we’re already considering
testing for two or three different concepts of what
makes a ground tile we can stand on. At the moment,
tile numbers 1, 2, 3, 4, 7, 8, 9, 10, and 11 appear to be
types of ground. Our ladder, 14, is also in some ways a
ground tile – so is a brick tile, so is a girder tile, so is
a grass tile, etc. So we need to consider if sequentially
testing tiles with a whole bunch of if statements is a
wise move.
Well no, of course it’s not, for all sorts of reasons.
It is hard to manage when we add new tiles and it also
makes the code test for the last tile in the list slower
than the code test for the first.
A better idea is to consider that each tile has certain
attributes, which we can encode into bit fields. Bits
are the basic binary (on/off) components that make
up all our data values, and it’s possible to set and test
individual bits (Figure 4). We don’t need to be able to
count in binary to use it; we just need to know that the
bits are usable and very useful. In an int we have 32
bits, so we can store 32 on/off attributes.
Our simple game only really needs two concepts at
the moment – Ground and Ladder – but we could later
consider Metal and Brick as an attribute and trigger
different types of walking sound effect.
Because we can use bit fields to define an attribute,
we can in theory have 32 different attributes assigned
to every tile, and that means that tiles which serve the
same purpose but have different tile numbers can be
treated the same in code.
The main difference from our viewpoint is that
instead of testing for a tile number, we use that tile
number to look up the attributes for that tile and test
the attribute.
Next time
This is all so far so good, but clearly there’s a massive
issue: the speed of our game has fallen to unplayable
levels! Do we know why? The source code has a #define
called FastUpdate – try setting it to true and see what
a difference it makes.
Next lesson we’ll examine how to do scrolling, add
some baddies, and also make more improvements
to our updating to explain and further improve the
performance of the tile draws. Sadly, there wasn’t
space this month to discuss text/font systems, so we’ll
try to fit that in next time to make score display and
menu/instruction screens much simpler.
Figure 3
A nice new map!
Figure 4 Encoding tile attributes into bit fields
STATE
MANAGEMENT
MAKES LIFE
EASY
Keep your
states well
defined and
separate,
and focus on
making each
state work
before starting
another.
LEARN
MORE
ABOUT C
Brian has a
whole book
on the subject
of making
games C and
C++, called The
Fundamentals
of C/C++ Game
Programming:
Using
Target-based
Development
on SBCs. Grab
it here:
magpi.cc/
nUkjEt