Making an endless runner similar to Turbo Pug

Started by
5 comments, last by Khatharr 7 years, 4 months ago

Hey everyone!

I'm pretty new to this forum, so don't know if this is the right place to be posting this. I'm a hobbyist game developer, and have been teaching myself Game Maker for a few years now - with a view to moving over to Unity in the near future.

I've been thinking about how to go about making a 2d sidescrolling procedurally generated endless runner, and have worked out the basic programming logic (move the background rather than the player, have platforms spawn and scroll across the screen etc). I've been playing this endless runner called Turbo Pug recently, and have been trying to work out the programming logic for the platforms. I've posted a video below. Most endless runners I've come across vary the length of their platforms (so, kind of like Canabalt), but Turbo Pug seems to have set sizes/types of platform. I'm unsure whether there are different sprites drawn for each platform 'type' (which seems long and unlikely), or whether the developers have meshed together different combinations of tiles. This still seems really complex to me, but if anyone has any ideas about how this might have been done, that would be really helpful! I'm not asking for anyone to code this for me, just to give me some idea of the logic behind it. Cheers!

Turbo Pug:

Advertisement

Do you mean the method for procedurally generating the series of platforms?

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.
Yes - and also whether they've drawn different platform types. Or whether they somehow generate these through code?

with a view to moving over to Unity in the near future.

I would look at UE4's 2d paper side of the engine. It has some very good resources for this.

Developer with a bit of Kickstarter and business experience.

YouTube Channel: Hostile Viking Studio
Twitter: @Precursors_Dawn

Procedural generation like this relies on creating a set of rules defining what you want to see and then determining how you can generate data within those bounds.

For what I saw of that game, they made a handful of concepts about floors and ceilings, then they added possible variations to each concept, such as how high or low the thing is, or how wide it is. If your runner accelerates over time then you probably want to increase the width of things (gaps, floors, etc) a little bit over time as well. Other than that you just use the RNG to pick all the variable factors (within the ranges you specified) for the thing, spawn the thing with those factors, and then use the RNG one more time to determine how long it will be before another thing of that type is spawned.

For example, you could have one function for spawning floors, one for spawning ceilings, and one for spawning groups of score tokens. If you use the distance that you've run as a timer then you can have one function for generating and spawning each of those and returning the timestamp of when that function should be called next. Every frame you check the timer against the timesteps and call the functions that need called.

Make sense?

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

Thank you, that makes perfect sense! You've set out a really good method for coding procedural generation, and I think it's within my remit to put something like that together. Although, I'm still unsure whether they used your specific method in Turbo Pug. Most sets of blocks seem to be the same width/appear at the same height every time - and the gaps between them seem to be the same width. If that's the case, do you think they've purely drawn separate sets of sprites (whilst using the procedural generation method you suggested above)?

I didn't look too closely at it, but when I made a runner with some other folks a while back we had a few tall but narrow sprites that we tiled together to make spans of rooftop of varying lengths and heights.

Whether the developers of Turbo Pug used large sprites or just predefined chunks with tiles doesn't have much impact on the final process, but if they used tiles (it sure looks like it) then it would have been easier for them to create and edit the chunks during development. Tiles are also smaller on disk and in memory, although the difference in this case is probably trivial.
void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

This topic is closed to new replies.

Advertisement