Here’s a ‘game’ that takes your FLine
vocabulary & knowledge and moves it almost all the way towards actual gameplay. Let’s aim to build four boxes:
These will build a character and a world, manage the (physics) simulation of the character and a world, manage interaction (through keyboard presses), and manage the camera on the layer. You’ll be able to translate, in your head, many computer games into this quartet of tasks that sit at the core of many computer games. Of course, lots of other things (keeping the score, the networking code, non-player characters, the level loading etc.) sit around this core, but this is the core quartet.
Let’s proceed in turn.
That’s it! The simplest player character and world:
We can make a more complex world by making a more complex floor:
That will make 30 random rectangles stretching away to the right of the screen.
Next, some animation, specifically some physics.
Now our triangle falls:
This is the missing ingredient — actual interactive input.
Now in a full game the interaction between the interaction and the physics engine might be quite a bit subtler than this (for example, we’ll find that we can jump even when we are in the air). You can finesse the contents of _.stage.keyboard.edge_down.up
quite a bit more than this (to permit double-jumps for example). But still, with this, we get a playable game:
The last stage is to move the camera around so that we can explore our proceedurally defined random level of rectangles. Creating the illusion of camera motion, in particular panning in 1 or 2 dimensions, was, in some sense, the primary occupation of many game engines in the 80s and 90s when software and hardware would go to incredible lengths to use panning — all to suggest that the screen was just like the frame of film: merely a window onto a larger world.
For us, however, its easy: layers have 2d cameras:
Now we can explore (if we’re good enough at platformers):
This kind of camera control can be scene as a physics simulation in and of itself (a kind of ‘damped spring’). There’s a long tradition of constrainted, physics like approaches to cameras in computer games — you’ll see this everywhere from The Witcher 3 through early Legends of Zelda.
In the above example we’ve constructed everything in an untextured Stage layer called ‘main’. We can build into a textured layer like things:
Where ‘grid.jpg’ is a jpg that we want to be able available for texturing geometry in that layer (note, we might want to put the player in a different layer from the background, and we’ll almost certainly want to break the background up into more than one FLine
to give us better control over how it’s textured ).
Once we’ve studied the texturing documentation for Stage we’ll realize that we have a bit of a problem: since the physics engine is continually, and magically, rewriting our FLine
to reflect how it moves under the control of physics, how do texture it? We’ve added a new call to physics for the most common case:
setting textureRect
on physics
object causes the engine to map the (rectangular) bounds of an FLine to a particular (rectangular) portion of the layer’s texture. Here’ we’ve mapped it to rectangle that starts at x=2/5.0, y=2/7.0 and has width=1/5.0 and height 1/7.0. This will make sense if we look at our test texture:
The texture atlas, as it is called, is actually a 5x7 grid of little images. We’ve mapped the 3rd from the left, 3rd from the top square to the body of our character (we’ve also made it a square)
If we design a function like this:
Then we’ll be able to set, for our 5x7 texture map, which little image goes on our character when with a single call.