next »

[J-Snake]

First I want to let you know that this thread is no way intended to pimp my game or to pimp anything at all.

The idea of cutting out arbitrary shapes in a discrete block-set which are going to be physicalized then was personally not remote to me, especially when you saw games like boulder dash.
To show you what I am talking about watch the part after second 50. It is demonstrating the physics well, I think.




My explanation would be that old gaming systems didn't have the power to do them. And newer games like minecraft are too big to feature them in real-time. I thought about ways how to implement them in real time in a large-scale environment but TrapThem is probably the only game of that sort that I want to create.

But I would like to know what you think about it.

[increpare]

My explanation would be that old gaming systems didn't have the power to do them.

Any pc made in the last 15 years would have, though.  So I don't think there's any reason.

[J-Snake]

I was mainly thinking about super nintendo and previous platforms.
I guess afterwards everything went up to 3D or/and other type of games.
The only 3D-game I know of that could fit would be minecraft. But at this scope the technological challenge would be bigger than having the idea, I guess. I am also not in the position to claim it will hurt or help the gameplay since I haven't really played it so far.

[J. R. Hill]

I think the main reasons are:

1. Most platformers didn't have deformable terrain
2. Platformers that did (e.g. Digdug) were understood to be cross-sections, so the dirt falling wouldn't make sense.

That said, most older games that had deformable terrain always had certain objects (usually rocks) that fell if unsupported.  (Boulder Dash, Digdug, Penguin Land, etc.)  The idea of cutting out forms of dirt that fall as a group likely never popped into peoples' minds because it's not natural or intuitive to think of physics as they would behave in a strictly 2-d universe.

[J-Snake]

I fail to see how cutting out solid shapes of earth or even stones that will fall down is less natural than having solely discrete objects which fall down when they are not grounded. It is probably even more consistent to let every piece of terrain fall down when it is not grounded. At least there is no basis to consider it less consistent.

The funny thing is that in the intro-clip of Dig Dug (xbox360-demo game), it actually shows identical physics-example-idea like in the vid (starts at second 50), so my theory is just that old hardware was not powerfull enough to run them. So they replaced the physics with discrete objects since it takes hardly processing power compared to this unified physics-system

[Defsan]

That kind of physics is too specific for a certain type of gameplay, and I'm sure people have thought about it, but decided not to implement it because they felt it wasn't fitting the game they were making.
You ended up pimping your game anyway, but it's alright because the idea looks cool

[Paul Jeffries]

I think Notch said that at one point he was considering requiring the 'floating islands' in Minecraft to include some Obsidian, otherwise they would fall down.  I take from this that he believed it to be possible to do stuff like this in real-time in 3d, and I can think of a few ways you could optimise the process that might make it feasible.  However, he later changed his mind - not sure whether this was because he did find it too hard to implement neatly or for some other reason.

It's certainly an idea I've thought about before (and so has at least one other person: http://www.squidi.net/three/entry.php?id=110), but I've never seen anybody actually go so far as to implement it before so kudos to you for that!

[LemonScented]

I don't see a technical reason why it hasn't been done before. I can see a few gameplay reasons, depending on the game (Boulder Dash would have been a very different beast with gravity for instance), but I think the main reason is probably that not many people have thought of it. Or at least, thought about it seriously enough to try to work out the gameplay implications and build a game design around it.

This is a long way of saying: Interesting experiment, carry on, looking forward to seeing how it turns out. 

[Xion]

That kind of physics is too specific for a certain type of gameplay, and I'm sure people have thought about it, but decided not to implement it because they felt it wasn't fitting the game they were making.
You ended up pimping your game anyway, but it's alright because the idea looks cool

This. I noticed that in your game, very specific kinds of gameplay spaces arise from the use of this mechanic - the inability to make looped paths, for instance, and large, open spaces that are made from the 'filler' terrain falling to the bottom, leading eventually to bottom-heavy arenas. Not saying this is a bad thing, but it takes a particular kind of game to employ the mechanic successfully, I think.

[J-Snake]

@Paul J: Thank you very much sharing your information, Paul! I am looking forward to  reread the article to see a different approach. However I think it is not that easy but you never can tell as long as there is a proof to it.

@LemonScented: I think there is a technically heavy reason for it as long as I don't see a completely new way in approaching it. Especially the smaller the grid gets (or rises in amount) the more processing demands are rising (in 2D up to square-complexity). If you use photoshop to mark and cut out arbitrary shapes, even on recent hardware you might notice a small slowdown, depending on size and the shape you are cutting out. The same happens in TrapThem, it needs to detect cutted out shapes, no matter how exotic they might look or how big they are, they can also have holes in them. But it all shall happen in real-time without any slowdowns.

@Xion: That is right. I noticed the problem of not having a looped path and that the problem just can get bottom heavy. That would reduce valuable depth in gameplay so I thought how to keep it without hurting the mechanics. The solution was simple and nice;)
I just have two types of stones, the white stones are fixed and whenever a piece of a block is landing on them it can be considered grounded (the same as if it would hit the bottom of the map). That way you have more flexibility and there is room for sophisticated trap-tunnels. And so is a challenging puzzle-design possible. You won't solve the hardest puzzle-levels that fast, I assure you:P

[TheSpaceMan]

Mr Driller hade a system where the terrain would fall if not supported. But the terrain would be grounded if it fell by a block of a simular color.

Hard to explain in a good way. Here is a video clip instead.

[LemonScented]

@LemonScented: I think there is a technically heavy reason for it as long as I don't see a completely new way in approaching it. Especially the smaller the grid gets (or rises in amount) the more processing demands are rising (in 2D up to square-complexity). If you use photoshop to mark and cut out arbitrary shapes, even on recent hardware you might notice a small slowdown, depending on size and the shape you are cutting out. The same happens in TrapThem, it needs to detect cutted out shapes, no matter how exotic they might look or how big they are, they can also have holes in them. But it all shall happen in real-time without any slowdowns.

On an 8-bit machine it would be a problem, but on any machine with a reasonable amount of power I'm sure there are suitably optimal ways to figure it out. I can think of a couple of algorithms that are promising when I run them in my head (although I'd have to sit down and actually code them to know if they'd work in all cases), but even if the approach meant iterating through every tile in the level every time a tile is destroyed, that should be well within the means of modern processors (even what we'd consider to be limited platforms like iPhones or the DS) unless the levels were huge or the tiles were tiny.

[J-Snake]

@TheSpaceMan: Mr Driller looks like another story, not like lego. But thanks anyway for interest.

@LemonScented: TrapThem needs max something around 1500 stones so it is Ok anyway. In case you have rough ideas how it can work for potentially unlimited or very large amount let me know, even if those are just rough ideas.

[Fallsburg]

Well, not directly applicable, but I feel like you would want to use some of the lessons from Golly, a Conway's game of life/other automata program/library. Given the grid sizes capable in it (potentially infinite), it would seem that there are definitely lessons to be learned.  My 0th order understanding of Golly and similar programs is that it uses a hash table and only keeps track of cells that changed in the last time step.  Since, only the neighbors of cells that changed need to be looked at, it cuts down on the number of cells that need to be analyzed from step to step.  The exact same methodology could be applied to your physics as well, if my understanding of them is correct (i.e. most cells are asleep, if a cell is changed wake up the neighbors and repeat as long as cells are still be changed.)

[Zaphos]

In case you have rough ideas how it can work for potentially unlimited or very large amount let me know, even if those are just rough ideas.

The generic high level ideas that I might try are:

(1) Only update locally where the change was made -- after one stone is cut you just have to verify that the neighbor stones are still connected somehow, and in a lot of cases this will involve looking at only ~10 stones.

(2) Use a hierarchical representation -- cluster groups of connected stones, and only invalidate clusters locally when their geometry is changed.  Then for large unchanged regions you will only need to look at the high level clusters, instead of looking at all the individual stones.

(3) As a last resort, spread the processing over several frames: While you haven't resolved whether you've made a cut after one frame's worth of processing, do a little "world shaking" animation and defer the remaining processing to the next frame.  Combined with (1) and (2) this might only happen when you cut something that was probably relatively unstable already, so even if it doesn't fall the shaking could still make sense.

[J-Snake]

@Tromack: Thanks for the info. I like that stuff. I also like some concepts from Neumann.

@Jimmy: Yeah, thanks for ideas. I have point 2 in mind by now.
Note that this is just a rough brainstorming idea that came to mind and nothing finished or prooved:

In 1-D space the game is almost trivial but I need to think about how to generate those clusters in 2D-space(and possibly 3D-space) and what can be done in a single frame. I think I have to use the fact to my advantage that in any given frame only few blocks can be destroyed. So I can spread processing power over time to organize things. Especially since a cluster is not created arbitrary but certain condition has to be met to divide a cluster into two. Each block can have additional data that stores information about it is connecting two possible clusters or not.
So in case the data manages to keep itself organized each time, the problem is solved. You will cut a block and the only thing that is going to be checked is whether it divides a cluster into two or not. So by division the appropriate cluster-data will be taken (which was already generated in accompany of your gaming time) and it falls down.

The only reason why I am considering it is because I can indeed imagine something interesting like TrapThem, only in bigger space (in 2D or 3D) and a bit Tower-Defense- styled. Only you are alone and trapped in a lego-styled and dangerous world. You are given a various range of weapons, shooting weapons and ignitor-bombs aswell to build and plan your traps. Each iteration(each night like in MineCraft or according to other events)of lego-styled monsters is getting harder and they are coming to kill you. You have to trap and kill them. The killed enemies themselves provide their lego-stones to repeatedly increase the worlds amount of stones that you can use to form new ground/traps and a growing tower.The goal of the game is to escape this dangerous lego-planet. Your tower can reach a new and secure planet over the skies. Once you made there, you have won the game (just one example to give the game an explicite engaging goal)
To reduce the amount of backtracking and traveling you can get/buy beam-nodes and place the according to your needs.