Destructible Terrain

From YoYoGames Wiki

Introduction

Destructible Terrain is the real-time remodelling of terrain in any game, created with Game Maker, C++ or otherwise. It can take many forms, simple "floating pixel" engines that do not take gravity into account and leave the so-called floating pixels behind when terrain is destroyed to complex 3D realistic engines that can handle hundreds of falling chunks of terrain at once. This aim of this Wiki article is to scrape the surface of destructible terrain when creating it in Game Maker and to discuss the pros and cons of the varied techniques. This is a topic for experts in Game Maker and a high level of familiarity with GML and the inner workings of Game Maker's sprite and surface systems are required.

Destructible terrain topic on the GMC. Unfortunetly, this topic is full of misinformation that clouds the important leaps made. Read carefully and there are some real gems of examples here.

Basics - Many objects

The original Worms game was incredible for it's time. Good sound, brilliant gameplay and a truly awesome engine that spawned a dozens pretenders. Unfortunetly, simulating this in Game Maker for beginners seems to be a moot point for most - The most common method being to create literally hundreds of tiny objects that each have a 2x2 pixel for their sprite and collision mask. It is clear why many fall at the first hurdle - the slowdown is nothing short of ridiculous. Even with 8x8 pixels, things are still sluggish. There are a few positives despite the obscene FPS achieved:

• 1) Collisions are simple to program and will be easy for those using drag-and-drop code
• 2) Gravity can be simulated with ease, merely by adding gravity to each block

The cons far outweigh the pros - who wants to play a slow game with a block resolution of 8x8? The answer is, more often than not, no one.

A modification on this idea is when the ground starts as one large object (lets say 512x512 pixels). When it begins to get destroyed it breaks into smaller objects ( in this example, 256x256 pixels). The process continues until the nessasary part of the ground gets destroyed. It is more efficent then starting out with 2x2 pixel objects, but not much.

Sprite modification

This method was popular before version 6.0 due to the abscence of a crucial factor - the surface. People experimented with sprite_create_from_screen() in order to effectively remove parts from the collision sprite. Some pseudo-code describes the ingenious solution:

• 1) Draw the background colour
• 2) Draw the landscape sprite
• 3) Draw the hole in the background colour
• 4) Draw a pixel in the bottom-left in the background colour to ensure transparency
• 5) Use screen_refresh() to make these changes stick to the buffer
• 6) Create the new sprite

This method was popular but proved to be unweildly for less experienced users and too slow with large sprites. Furthmore, the entire method doesn't work when using a view due to the way in which sprite_create_from_screen() functions, literally taking the image from the screen and ignoring any image information from round the sides. This is due to the screen buffer being the only buffer available for users of version 5.3 and lower to use.

Surface manipulation

A new buffer was needed to play with and Mark Overmars added the surface in Game Maker 6. By using a similar method to before, but using sprite_create_from_surface() and retaining the buffer instead of redrawing it every time, destructible terrain can be easily achieved today by the humblest of GML programmers. An important factor to note is the delay in turning a surface directly into a sprite - there is significant lag time between the two that can be a catastrophic problem in games with large room sizes. Even with 640x480 rooms, the standard size, the slowdown is noticeable. In order to work around this, the surface needs to be segmented in order that smaller pieces can be analysed and converted at the same time. Equally, if explosions are kept on the small side then less tiled surface needs to be manipulated every step. Collisions with this new surface-sprite technique are also rather simplistic, a standard collision with a solid object that can be done effeciently through Game Maker's internal engine. Examples can be found riddled through the URL I gave in the introduction.

New boundries - 3D

3D destructible terrain, much like in the commercial programming world, is somewhat of a problem. Many games have attempted it, Red Faction for the PlayStation 2 and Worms 3D for the PC, and haven't really impressed the gaming community. There are two general methods, Red Faction attempted to modify polygon meshes around an explosion volume with the main issue being with the detail in the deformed landscape. Worms 3D used a 3D block technique (also called a volumetric pixel or Voxel engine) that is the most applicable to Game Maker with limited success. Since polygon rendering in Game Maker is, as of the moment, too slow for polygon deformation, destructible terrain seems to be most applicable via a Voxel engine. By using the new, very fast, data structures added in version 6, the rendering and calculation of destructible terrain seems attainable by the subdivision of cuboids, albeit with a limited resolution.

Conclusion

Game Maker is very much capable of performing destructible terrain, much like it can handle real-time physics and real-time lighting, with some effort on the part of the programmer to consider the speed and complexity restrictions. Memory is also a factor when using surfaces as they can easily get out of hand with little more than resizing a room or using too many layers for detail. Beware the pros and cons of each method and consider them before you become too keen on your destructible terrain game.

Just a warning here, not everything in this article is current, there have been many improvements recently. -- Daniel-Dane/theman