Do you mind if I try something over the weekend" Andy Clitheroe (Worms 3D Lead-Technology Engineer) asked me, "I've got a new idea and I think it's worth a go!" Andy was referring to the technology base for Worms 3D and whilst we were happy with the way that the concept & prototype was going, it just didn't allow us to do things the way we really wanted, i.e. ledges, tunnels, floating islands in a fully free-form way.

"Sure, no problem" was the answer and 3 days later Andy blew our socks off. The weekend had been extremely well spent. Our expectations were completely surpassed. This really was game on.

The 2nd generation prototype was born. A new approach had been taken as two principal technologies (voxels and polygons) were ingeniously mixed to create a new technology that was simply perfect for Worms 3D. The fact that no other game (to our knowledge) used this technology was equally exciting, particularly given that with the technology came a new 'look and feel' which was unavoidable - but what was great was this forced 'look and feel' was completely and undeniably Worms! We still haven't decided what we call the technology (we did think about naming it as developers generally do) and we can't decide on a 'Volygon Engine' or 'Poxels' - I quite like Poxels.

Pretty soon a number of Islands and landscapes were built using a fairly primitive text file, which spliced the land and used "sections" to build it, allowing tunnels, under-hangs, cliffs, you name it. Best of all it was able to be deformed very freely. At this early stage, this was crude and quite slow, but genuinely exciting - for the first time, people really could see this working more than any other way; it was absolutely perfect for the game.


Voxel Engine A couple of weeks later we were approached by Ken Silverman, who developed the original Duke Nukem engine for 3DRealms, Ken had developed his own Voxel based engine. The problem with voxels is that you need a lot of them stacked vertically to get any decent image resolution; otherwise they tend to be 'ugly' and overly blocky. They've been used in the past to create intriguing 3D landscapes (as early as 'Rescue on Fractulus' (LucasArts, circa 1984) on the C64!) and are generally height-mapped elements within a grid. The problem with a lot of voxels is that this means quite a lot of processing time which in turn means it's difficult to implement on polygon-based consoles. And to get good resolution on PC you need to be processing a lot of them - and they aren't textured like Polygons, they're simply coloured.

Ken's engine was impressive in terms of voxels, but it wouldn't work on console - and Andy had found a much better, hybrid system that suited us perfectly, offering the benefits of '3D material' the way voxels work, which was constructed out of polygons. It is by no means a cheap way to build the landscape, but it would work on all our formats and give us the desired look, feel in terms of both imagery and game play.

After a few weeks of improving it, adding water, a basic camera control, some visual improvements and several data structure rewrites, work on a usable editing system for the lands begun which would replace the very raw and rudimentary data entry. At that time, the levels were generated from a series of 2D bitmaps which dictated where in the 3D grid there was land or not.

This made the landscapes of the time look quite simple, they had no lighting, very simple 'programmer' textures and absolutely no details. Yet still, the whole team could see where it was heading and when you look back now, comparing how we stand today, it's great to see that our vision for the game has been superceeded by what we've achieved - and the system itself has grown to support all manner of effects and cool stuff.


project evolution Worms 3D had been born and with one fell swoop, the thing that separated it from all other 3D games had been delivered - freely deformable landscape technology that wasn't limited, controlled or staged.

The basic core of this is now part and parcel of the Worms 3D editing tool which will be supplied with the PC version - although it's much more enhanced these days, with work on the tools going on for months now. It's now a very powerful, dynamic tool and can be used to very quickly generate exactly the world you want.

This was perhaps the most fundamental evolution of the project, its potential, drive and enthusiasm, which has kept driving the project and the team forward to this date. In tandem with the code and art, it's allowed the designers to get on board and get their hands dirty from a very early stage. Designers have been creating levels & objects with the tool for about 5 months already, which means by the time the real game worlds will be generated, there will be no holding them back.


Traditional destruction It's important to understand what we mean by fully destructible; basically you can blow the land up, objects up, everything up - just like you could in 2D Worms. What's more, we could replicate the same mechanics where floating land could remain, just like in 2D - this gives the game its own look and feel. It meant we could have caves, overhangs, tunnels... everything that Worms needs and traditional 3D engine simply can't provide in a destructible way. Everything you see can be destroyed and none of it is 'animated' or cheated in anyway. Traditional destruction sees objects disappear in a puff of smoke particles & you see animated polygons collapse, perhaps you see land scorched but unaffected geometrically speaking, a few games use height-mapped deformation of the mesh to show some destruction, but nothing (as yet) does what our game does.

With perhaps the core ingredient now proven and other elements such as the aiming, movement and camera deep in prototype design, Worms 3D forged onwards dramatically with an energy, purpose and conviction much higher than ever before.

Auf jeden Fall müsstest Du die Würfel in "durchsichtig" und "verdeckend" einteilen.
Alle Würfel, die komplett von undurchsichtigen Würfeln verdeckt werden, kannste sowieso verstecken.
Außerdem könntest Du alle Seiten, die an verdeckende Würfel angrenzen auch rausschmeißen, was aber nicht so leicht sein dürfte.
Wird nun ein Block rausgesprengt, so muss die Sichtbarkeit für alle angrenzenden Blöcke neu berechnet werden.


Die geeignetste Technik hängt davon ab, was Du genau machen willst.

@Waveblue:
füge so eine Function ein:
BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN]

 Function ruckelfreimachen(mesh$, camera$)
If EntityInView(mesh$, camera) = 0 Then
HideEntity mesh$
TranslateEntity mesh$,0,0,0
End If 
End Function

mesh$ ist/sind der/die cubes (rufst du für jeden Cube auf), und Camera$ ist die entsprechende Kamera
(falls du mehrere verwendest). Da die Kollision etwas wegen HideEntity spinnt,
würde ich die Schwerkraft ausschalten (soll durch das TranslateEntity dargestellt werden)...


mich würde nur interessieren, wenn du cubes nimmst, wie teilst du dein Mesh in diese ein ?