next »

[RCIX]

I'd make Cortex Command.

Someone's already made that I should look into Cortex Command more, but from what I've seen in videos and stuff, it's not a genre that sets my world on fire.

It's sort of a combo between sidescroller, mining game, 2D FPS, and sandbox. It'll be way better when there's actually a campaign (and hopefully online play)!

But thinking about it, i'd do some sort of Captain Forever-esque game where you could build your ship with modules, then blow it (and other ones) to bits! Literally!

[Xion]

A game contained in a continous playspace but with seperate planetoids, each with their own fields of gravity and orbit patterns as dictated by some fantasy physics simulation that focuses on interesting and predictable over realistic. You control a space-bastard who rockets to each planet with his army of goons, mines it dry, and captures or destroys any native life that may exist. Sometimes you'll come across planets populated by sentient races - either primitive or space-faring - that will need to be broken before you can exploit them and their planet to the fullest. There are several ways to do this but most all of them involve large-scale destruction of the planet's surface. One way could be to redirect a nearby asteroid or small planetoid to collide with the one of your desires, causing all kinds of fuckery with the orbits, planets' shapes, and native life. You could also purchase various tools of planetary destruction such as the world-splitter, that literally cleaves a planet in two halves, or the minisun, that changes gravity and orbit patterns, or the Very Large Thruster, that you can attach to planets in order to steer them around the solar system and crash into other planets. May need several in order to move the more massive bodies.

Being on planets and commanding your goons wouldn't be so much like an rts as Pikmin + Liero.

Different materials have different strengths ( and weaknesses )

Also your ship is customizable because why the hell not.

[ras]

A 2D populous?

Populous was already basically 2D, wasn't it? God games are not really my thing, but I agree that building stuff is cool.

Well, Populous was isometric, TheSpaceMan probably meant a 2D from the side (like Worms) Populous.

[J-Snake]

Now I see why you were interested in TrapThem:)It is basically the same thing, it requires only a small scope. TrapThem looks like in side-scroll-perspective but gameplay-technicaly it is a mix between top-down-gameplay (equal movement in all directions) and sidescroller-gameplay (blocks can fall down).

But to possibly give new inspirations feel free to check out some "From Dust" footage.



It is 3D but you can probably reduce it to a top-down-perspective. I think especially in top-down there are many ideas available to find something interesting. My recommendation is to think in sidescroller vs top-down first. Try to compare the advantages vs disadvantages of both. Then decide to go with a preferred perspective. If possible and needed you can also combine mechanics of both perspectives into one (like in TrapThem).
Hope it helps for the start!

[Retrogames]

My first thought; don't get caught up in the terrain destruction / construction as the overall play mechanic. Instead, make it a complimentary element and not the sole major feature.

Imagine a platformer where the character is able to manipulate the world around him. For example, dredging up chunks of earth to absorb incoming attacks, to create platforms to climb, uncover hidden rooms, etc. Nothing MASSIVE like completely tearing up the level, but small manipulations befitting a platformer instead of a terrain-mod game.

Maybe on the player's first playthru or in the introductory level, they're just a typical platforming character, and maybe introduce something like a bomb that can cause terrain deforming (but on a very small, simple level). The player would see it and go "Oh, that's cool, I can mess with the terrain in this game". Then, using an RPG-like skill or class system, allow terrain deforming to make an appearance as simply one (of several) ways in which to play the game. Perhaps the player builds a warrior character who doesn't really experience terrain manipulation (though pixel-perfect environments are still really cool for him to experience), that just happens to be his experience. The potential, however, is there...

One of your skill / class options would be the terrain manipulator class, which is a crappy combat class in terms of traditional platforming games, but with the manipulation of the environment can more than make up for it. Maybe they're telekenetic and can manipulate not just the environment, but lifting up enemies and dropping them off cliffs (even better; digging out the cliff and tossing enemies over it), or using one enemy or chunk of manipulated terrain as a shield against incoming enemy projectiles.

So you have this terrain modification-heavy character you can play as, but if the player decides not to take on that role, you still have pixel-perfect collision detection and that can lead to all sorts of interesting things.

If you arrange a long row of modifiable terrain spikes that the game recognizes as a player-killing hazard, maybe one character gets past it by having a really long jump. Another manipulates the terrain to make platforms out of the spikes, or tears down chunks of the ceiling to use as platforms. Another tosses (or psychically manipulates) enemy bodies into the spikes and uses them as platforms.

Maybe the deformable soil can be used by another character as a special, navigable terrain; they can 'walk through' the deformable soil, passing as a whispy spirit past the danger entirely.

Here's an example of what I'm talking about; the same obstacle, but many ways to complete it.


I guess I'm just thinking of giving the player lots of ways to overcome obstacles and having terrain modification as simply one method instead of the absolute focus. The platforming, however, is still the main drive of the game. Try not to think of them as puzzles so much as just... different ways through the same stage.

[Seth]

I don't know, something like roguelikeish like Spelunky in Space.  Causing cave-ins would be important

[AndroidScholar1]

You could make it into Worms, but on a much grander scale, in which environments attack each other instead of the people. The player has their own planet/map, and the computer/enemy player has their own planet/map (I say /map, because a whole planet is a bit overkill, and so a single map to represent the planet each person is on should suffice). You both have a set amount of time to mine/drill for materials and the like that fuel your weaponry (oil to power a laser beam, metals for the guns, etcetera.), and then a set amount of time to allocate your found resources to your weapons. Then the two worlds attack each other, and the cycle begins again, running until one planet either gives up (possibly surrendering their resources to the other by doing so) or is annihilated of all life (represented by Lemming like NPCs in the map).

Essentially, War of the Worlds (literally) mixed with Worms.

[LemonScented]

There's enough cool stuff here that I've finally overcome my laziness and started coding up a pixel-landscape joy. Still not sure what the actual game will be. I'm leaning towards something involving asteroid mining, but it's all pretty much up for grabs right now - I plan to build the tech and then let it "speak to me" about what sort of game I should make with it.

Ugh, I went poking through my old code and of course it was one of my first projects so it has horrendous code structure and (though it is apparent I had intentions to refactor) I must have gotten halfway through a change and abandoned it. Unfortunately it's pretty much toast. However there are specific bits which are intact, such as how to resolve a 'normal' to a pixellated surface and terrain generation. Much of this is adapted from various tutorials on the internet so it wouldn't really be anything new.

Care to share the code for getting a normal from a pixellated surface? I'd love to see that. My biggest obstacle at the moment is that although it's pretty easy to know when two bitmaps intersect, it's not so easy to figure out the closest surface points are for the bitmaps (for seperation) or to work out the normal (for collision response/bouncing/physics stuff). Any help would be... Well, very helpful. 

[Draknek]

Care to share the code for getting a normal from a pixellated surface? I'd love to see that. My biggest obstacle at the moment is that although it's pretty easy to know when two bitmaps intersect, it's not so easy to figure out the closest surface points are for the bitmaps (for seperation) or to work out the normal (for collision response/bouncing/physics stuff). Any help would be... Well, very helpful. 

An algorithm I've seen mentioned (but not implemented myself) is to count how many pixels are overlapping when you offset one of the objects by one pixel in each direction then calculate a weighted average normal.

Obviously that would only work for shallow collisions though.

[LemonScented]

An algorithm I've seen mentioned (but not implemented myself) is to count how many pixels are overlapping when you offset one of the objects by one pixel in each direction then calculate a weighted average normal.

Obviously that would only work for shallow collisions though.

Hmmm. Can't quite visualise how that would work. I'll need to play with some graph paper to wrap my head around that, I think. As a first pass I was thinking of testing single points (particles, basically) against a static level bitmap, so in those cases I can't rely on a lot of information from the particle because it's basically a single pixel. So, I've got the particle position at the start of the frame, and the intersecting position that occurs before the collision response, and from that I can make a bounding box. From the section of the bitmap in that box I need to get a position to move the particle back to to stop it intersecting, and a surface normal for working out the rebound velocity.

Although, this is probably something that's better suited to the technical forum than the design one 

[mcc]

Tetris w/destructable terrain, tectonic forces that move bits of the payfield around at random, and wads of earth for tiles? Dunno.

[Zaphos]

Here's a related thread which has some ideas for getting a normal from a bitmap, I think -- http://forums.tigsource.com/index.php?topic=4268.msg135697#msg135697 (edit: actually that thread is rather non-conclusive, but I think glaiel must have figured it out for closure so you could just ask him what he did.)

Another idea is to just pre-compute a signed distance field (eg using fast marching method) and sample the gradient.  (I think you could locally update the field whenever the terrain changes.)

[LemonScented]

I have indeed messaged Mr. Glaiel and he's been very helpful at getting me started. He's mentioned that he might do a blog post about his techniques at some point in the future.

The signed distance field idea is interesting. It's a bit like an idea I had in my head (i.e. encoding information about the distance/direction to the surface inside the bitmap), but I'd never heard of the proper term for "Signed Distance Field" before, so I've had fun with Google One thing I don't quite follow is that although there seem to be plenty of techniques for ways to compute the fields, I can't find many examples of them being used in collision/physics - mostly they just seem to be used for generating sharp decals and fonts from low-res textures. What do you mean by "sample the gradient"?

[jotapeh]

Care to share the code for getting a normal from a pixellated surface? I'd love to see that. My biggest obstacle at the moment is that although it's pretty easy to know when two bitmaps intersect, it's not so easy to figure out the closest surface points are for the bitmaps (for seperation) or to work out the normal (for collision response/bouncing/physics stuff). Any help would be... Well, very helpful. 

This is what I do. It's very much point-specific and requires that you have extricated the point from the surface by exactly one pixel.

Code:

// terrain surface normal calc
		private function returnSurfaceNormal(thisObject:PhysicsObject):Vector2D {
			var testBD:BitmapData = new BitmapData(thisObject.objWidth-1, thisObject.objHeight-1, false, 0x000000);
			var ripRect:Rectangle = new Rectangle(thisObject.xZ - (thisObject.objWidth >> 1),thisObject.yZ - (thisObject.objHeight >> 1),
				thisObject.objWidth, thisObject.objHeight);
			testBD.copyPixels(terrainMaskBD,ripRect,new Point(0,0));
			
		//	SnowTest.testBitmap.bitmapData = testBmd; // for test purposes, shows the b&w terrain map being analyzed
			
			var colHeight:uint = Math.round(testBD.height);
			var rowWidth:uint = Math.round(testBD.width);
			var slopeXAvg:Number = 	0; var slopeYAvg:Number = 0;
			var center:Point = new Point(testBD.height >> 1, testBD.width >> 1);
			
			for (var i:uint = 0; i < colHeight; i++) {
				for (var j:uint = 0; j < rowWidth; j++) {
					if (testBD.getPixel(j,i) != 0xFFFFFF) {
						slopeYAvg += center.y - i;
						slopeXAvg += j - center.x;
					}
				}
			}
			
			return new Vector2D(slopeYAvg,slopeXAvg);
		}

Emm.. so to try to demystify that bit, it takes a small snapshot of the black/white terrain map surrounding the point being tested, half of the size of the object being tested. Then it averages out the slope. IIRC the 'subtract one' I did helped to 'center' the bitmap. Even bitmaps technically have a center between two pixels, so reducing it to an odd number forces one pixel to act as the center, or something.

I'm pretty sure you can find this code somewhere else on the internet, but I brutally sliced it down to just what I needed (precise surface normal calculation.) Again I wrote this two or three years ago, I wasn't the best coder.

[LemonScented]

Nice 

How do you extract the point from the surface? The general wisdom seems to involve just stepping pixel-by-pixel from the intersection point back towards the original position and testing each pixel in turn until you're outside the solid part of the bitmap. Which would work, of course, but I'm wondering if all that iteration and testing might be a bit of a performance hit and if you could use some other technique involving looking up precomputed stuff (something like the signed distance field, perhaps) to jump immediately back to the surface without having to go one pixel at a time.

[Zaphos]

The signed distance field idea is interesting. It's a bit like an idea I had in my head (i.e. encoding information about the distance/direction to the surface inside the bitmap), but I'd never heard of the proper term for "Signed Distance Field" before, so I've had fun with Google One thing I don't quite follow is that although there seem to be plenty of techniques for ways to compute the fields, I can't find many examples of them being used in collision/physics - mostly they just seem to be used for generating sharp decals and fonts from low-res textures. What do you mean by "sample the gradient"?

In physics they're used in fluid sim (by level set people) and for fast collision detection ... they're advocated for example in the Guendelman rigid bodies paper that is sometimes mentioned around here: http://graphics.stanford.edu/papers/rigid_bodies-sig03/rigid_bodies.pdf

By sample the gradient I mean you can find the surface normal by taking the gradient of the distance field -- if you visualize the distance field as a height field, this is essentially the direction the field is sloping down.  If you compute it by finite differences, the normal-from-distance-field looks like n = normalize(vec2(dist[x+1,y]-dist[x-1,y], dist[x,y+1]-dist[x,y-1])).  This should give the closest normal anywhere on the field, except it can return zero when you're equally close to multiple surfaces.  Guendelman also suggests casting a ray in that direction to estimate the closest point & perhaps a 'better' normal.

[jotapeh]

Nice 

How do you extract the point from the surface? The general wisdom seems to involve just stepping pixel-by-pixel from the intersection point back towards the original position and testing each pixel in turn until you're outside the solid part of the bitmap

Yeah I just reverse projected, exactly as you described. It's not very computationally expensive in my experience.

[PowRTocH]

A fictional futuristic sport that takes place in underground mines. Sort of a Dig-Dug/rugby hybrid with a macro strategy element of being able to collapse parts of the mine by breaking pillars.

[nahkranoth]

How would you create damage per pixel? (say that one "material" is stronger then the other)
After an explotion some pixels may die, while others survive because they are steal pixels.
Make an array full of health per pixel or does anybody think there's an easier way?

I do not mean anybody should hand me the code ofcoarse... I want to get in to the logic of pixels and pixel collision checking.

[TheSpaceMan]

How would you create damage per pixel? (say that one "material" is stronger then the other)
After an explotion some pixels may die, while others survive because they are steal pixels.
Make an array full of health per pixel or does anybody think there's an easier way?

I do not mean anybody should hand me the code ofcoarse... I want to get in to the logic of pixels and pixel collision checking.

As mentioned earlier in the post. The image is the data and the pixel health packed into one. when you hit a part of the image, you modify the alpha value of the current pixel. I guess you can work in either direction, when the alpha value reach max alpha or 0 the pixel is destroyed, otherwise the alpha value is just increased/decreased based on the damge dealt.

When working with pixelcollision etc you usualy have the entire pixeldata avalible and do logic straigt towards that data. When the logic is done the resulting image is presented on screen.

To speed it up you could hold multiple smaller buffer for the total image size, then just work with those buffers that are effected.

Am I making sense you old pixelninjas?

Could be wrong.