The Getaway - racing+survival - "full scale" city with a "survival" theme

  • Subscribe to Construct videos now

    The Getaway is a "unique" racing game in that the opposition comes in the form of time and the assortment of enemies and obstacles found.

    Held captive by a mysterious villain, the Driver must navigate an enclosed cityscape to survive and escape to freedom. With complete freedom to navigate the city, the Driver must complete a series of missions in the hope of outwitting his captor and leave the giant prison. Further, the Driver can explore the city to find clues as to the truth behind his capture and the nature of the city.

    Features

    These are aspects to the game I hope to include, though the cutting room floor is sure to be filled...

    • Multi-level roadways - Using layer scaling and Z-elevation in creative ways, a sense of depth will be crucial to the level design and graphical presentation.
    • Hi-speed missions - Each of the main missions will feature a race against time as the Driver seeks to achieve his goals. Quick reflexes will be needed to navigate the city as the Driver pushes the pedal to the metal. If time runs out, it's only the beginning of the end as the Driver must then face off against an increased set of challenges all while still trying to complete the mission.
    • Drive + Run - The obstacles and enemies will leave a toll on the Driver's car. But just because the car takes one too many hits doesn't mean it's automatically game over. The Driver will have the option to get out on foot to find alternate vehicles to drive. But this will leave the Driver severely vulnerable...

    Themes

    The themes of the game could probably fit all under the "do or die" mantra...except on four wheels (and sometimes two legs).

    • Fast, constant tension
    • You're not racing to be first, but to survive
    • Exploration is the key to solving the mystery
    • Time is a patient enemy

    Tagged:

  • I was asked how I did the "3D" buildings and the trick is really simple.

    It's literally just a stack of similar sprites with a progressive Z-elevation value.

    Using For() loops, I spawned [a number of] window and non-window sprites to create a "floor". In my case, I used 5 instances of a window sprite and 5 instances of a non-window sprite to make one floor...hence why the HowHigh variable on event line 3 is set to a multiple of 10.

    From there, I just tell it to alternate between a window sprite and non-window sprite. Every five instances of one sprite lead to a swapping out to spawn five instances of the other sprite. And I set the Z-elevation in according to the current "floor" count. To keep the buildings from appearing too tall, I divided by 4...but this is subjective and will depend on how you might want to use this setup for your game.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Following my post above regarding the technical set-up for the buildings, I used a similar setup for the creation of the sloped roads, too.

    Subscribe to Construct videos now

    At first, I was going to draw each road sprite at different sizes and then arrange them accordingly. The different sizes would represent different elevation levels in the city. And this probably would have worked just fine until I remembered I plan to include bridges, as well. Since I want to employ serious amounts of scaling/Z-elevation factors, it became clear that the roads wouldn't line up properly if different road pieces that represented different elevation levels weren't actually scaled properly.

    Simply put, everything that's on a different elevation level in appearance has to actually be on a different elevation level. But actually accomplishing that with the sloped roads was going to be tricky because if there's no way to scale a sprite where one edge is secure at a lower Z-elevation while the other edge aligns with its adjacent road sprite at a different elevation.

    What I did then was created "slices" of the road and spawned them in such a way that as the road pieces connect from end to end but are on different elevation levels, the road "slices" would "step" along to connect the two ends. It's literally like a set of stairs but because it's all flat images and aligned just right, it appears near-flawless (at least, I think so...). An actual sloped road that appears elevated from one end to the other.

  • Subscribe to Construct videos now

    A key aspect to my game is to have a large-scale cityscape to drive around in. I decided to go "all out" and actually incorporate an actual city into the game...my old hometown of Tyler, Texas.

    One thing I'm mindful of...hopefully more-so than not...is the fact that a large size like this will be more demanding on GPU. So balancing a large environment, a large number of objects (on and off-screen...working on that) and yet making sure that the environment is still big enough to drive around in (can't be too small) is all squarely on my mind. And more!

    But so far I think I've got the scale just right.

    I literally screenshot maps from the city archives and worked them into my game. Later I'll be adding a system which will adapt these map images to incorporate actual game road elements.

    This video is just to showcase the non-blocky road system I'm working on as well as the scale of the city and hopeful 2.5D visuals.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)