Suggestions for a new Cheapo Copycat game

[Isu]

Yes I probably would die first. I've been working on the game for so long that I'm practically dead now.

Don't know about anyone else but I don't expect all the suggestions (even the ones I gave) to be present in the next or any future cheapo game. I expect everyone is just throwing as many ideas to Essman as possible so that he could choose the best ones to put in the future versions of cheapo.

Its still a brilliant clone though.

[Timballisto]

So...uh...how's it coming?

[Essman]

So...uh...how's it coming?

Don't hold your breath. I still can't work on it for another couple months. By the time I'm done, everyone here will have lost interest in the game, and then regained interest. Many of the suggestions were being implemented before I had to take a break.

[Conway]

By the time I'm done, everyone here will have lost interest in the game

 Never! O_o

[Shvegait]

, and then regained interest.

I think what Essman was referring to is that it will be a LONG time before Cheapo gets done, so long that we will have lost sustained interest in Dimwits and will have our interested sparked again... Things like interest in something tend to go in cycles... That's what I got out of it anyway

[Timballisto]

This is true.  If it wasn't, I'd always play the same video game over and over.

[Conway]

 . . . true . . .

[okmot]

the CLONES development team has implemented some of the ideas from this thread and will soon release a new version which we feel is about 3x more fun to play due to the new gameplay objects and features   now we just have to make some singleplayer levels which take advantage of the new features..  i wish we had more level designers

http://www.clonesgame.com

[guest]

New suggestion.

Yet another random idea off top of my head.  Might not work too spectacularly well but interesting to consider.

Weak terrain.

Basically this comes off of a strange and rather cruel idea that briefly flashed in my head for no apparent reason.

I was imagining how a basher tries to bash thru the base of a gigantic hill but then the earth collapsed on him.  

And so born the idea of weak terrain.  There are a number of variations with this, but the basic idea is it's an invisible "field" you can assign to the terrain, analogous to metal areas and one-way walls.

Weakened terrain has the property that during excavation, with a short bit of delay the column(s) of pixels starting from the point where you removed terrain, will fall down until it hits ground.

So for example, say we are bashing, and the weak terrain pixels are marked as "X":

Code: [Select]

XXXXXXXXXXXXX
XXXXXXXXXXXXX
XXXXXXXXXXXXX
 XXXXXXXXXXX
 XXXXXXXXXXX
XXXXXXXXXXXXX
(I know a basher's tunnel is taller than that, just humor me ok)

Then after a short delay, preferably once the basher bashed further and out of the way or something, the terrain will fall down at some unspecified speed and eventually the terrain becomes:

Code: [Select]

  XXXXXXXXXXX
 XXXXXXXXXXX
XXXXXXXXXXXXX
XXXXXXXXXXXXX
XXXXXXXXXXXXX
XXXXXXXXXXXXX
Although not completely decided, I'd say the lemmings who gets hit on the head by such falling columns of terrain pixels will be killed instantly, although to make it sensible there probably should be a minimum height and falling distance for the column to be lethal when falling down (having a single pixel knock the air off a lemming is a bit silly even for this wacky idea).

I'd imagine the terrain probably falls at the same speed of a non-floater lemming, maybe a bit faster.  I also imagine that the columns of weak pixels affected, during the "delay" phase when they're about to fall, they'd flash so the player is aware of the imminent danger/problem.  For extra punch, when the falling columns of pixels finally touch ground, maybe we can draw some confetti or dust cloud or something.  And of course we'd need some good sound effects.

I haven't decided yet on whether cascading terrain collapse is allowed, but I think it's a neat idea on top of a simple collapse.  Cascading terrain collapse could occur if an entire column of weak terrain sit in mid-air unsupported by normal terrain below.  For example, say we have a bridge-like thing with water or air below:

Code: [Select]

         XXXXXXXXXXXXXXXXXX --
               XXXXXXXXXXXXXXXX   |---- all weak
XXXXXXXXXXXXXXXXXXXXXX --
XXXX  
XXXX   (water or air here)
Then after the first collapse we get:

Code: [Select]

                     XXXXXXXXXXXXXXXX --
             XXXXXXXXXXXXXXXXXX   |---- all weak
XXXXXXXXXXXXXXXXXXXXXX --
XXXX  
XXXX   (water or air here)
If we allow cascading collapse, then since the first collapse lands on a column of completely unsupported weak terrain, that column will be triggered to collapse after another delay, and so we finally get:

Code: [Select]

                XXXXXXXXXXXXXXXX --
                    XXXXXXXXXXXXXXXX   |---- all weak
XXXX  XXXXXXXXXXXXXXXX --
XXXX  
XXXX   (water or air here)
-----------------------------

The interesting property about weak terrain is that it is more difficult to create a path through such terrain by excavation, because the collapse will quickly close the path off.  At least until you excavate enough times so there are no more terrain to be collapsed from above, or unless you started off excavating so high that there is nothing to collapse from above.  At the same time, this collapsing property can be useful in its own right:  imagine demolishing a tall column blocking the crowd's way by bashing thru it, and imagine it sits on entirely weak terrain and we have cascading collapse enabled.  Then after bashing, the column will eventually fall off on its own.  If that column was originally in the way of a second higher platform, you have effectively clear out the obstacle with just one basher, instead of two (bashing at lower platform and bash at higher platform) you'd be required normally.

[guest]

Just want to add 2 more details to this.

I mentioned that the weak terrain will be assigned to terrain pixels in the level editor in a manner analogous to the assignment of metal areas of one-way walls.

However, it just occurred to me that at game time, you'll need to track weak terrain differently from regular one-way walls and steel.  Because for the whole scheme to make sense, we need to keep track of weak terrain at a pixel level, since the weak pixels don't stay in one place but will likely fall down during gameplay.

So memory-wise this is more expensive than steel or one-way walls.  However, we can keep this manageable by limiting the total number of weak pixels supported by the game, and have the level editor check accordingly to enforce it.  This will work since the number of weak pixels in the level can never increase during gameplay, so at any time you have, at most, only as many weak pixels as you assigned to the level initially.

Further memory reduction may occur if we realize that, since the pixels move as columns, we may represent them as such, instead of individual pixels.  Of course, each time you apply excavation you'd effectively split a single column into two, so it would seem like you might ended up using up just as much memory.  But here's the beauty:  since the number of skills are also fixed by the level designer, you can use the total number and types of excavation skills available, in conjunction with the total number of columns of weak pixels you start off with, to calculate/estimate how much memory you might need and limit the level designer's usage of weak terrain accordingly.

------------------------

Finally, I forgot the issue of visually representing weak pixels.  This is unfortunately somewhat difficult, especially once the columns of weak pixels starts separating themselves out one by one during some excavation.

Though perhaps we can still rely on the memory of the player to keep track of which pixels are weak once they start collapsing.  In which case it suffices to only indicate which pixels are weak at the initial state of the level.

Since we assign weak terrain using the same system we assign one-way wall, naturally we can indicating weak terrain similarly.  For example, perhaps we can overlay a bunch of red Xs, as opposed to red arrows, to indicate weak terrain.  Of course, once the terrain starts collapsing, the arrows will collapse with the pixels so it can become harder to tell, but it's a viable solution.

You can of course also just make weak terrain pixels be constanting 'glowing", so that you can easily tell them apart visually even after arbitrary amounts of collapse, although that might be a bit too distracting (not to mention it might make the terrain look radioactive rather than weak).

---------------------------

Oh, and I just see another interesting aspect of this.  So far I only consider collapse during excavation.  But perhaps we should also consider collapse caused merely by a lemming landing on/walking over a column of weak pixels unsupported by anything below?  I'll have to think about this, though it seems like a sensible and workable idea.  We might even consider having two (visually distinguishable of course) types of weak terrain, a "weak" and "extra weak" one, with the "extra weak" prone to collapse by walking while the normal one not.

It is also interesting, if we accept the possibility of introducing Lemmings 2 style skills, to extending some of that to this weak terrain concept.  For example, perhaps the weak terrain can absorb the glue from the filler skill or the glue pourer skill, and turn into normal terrain.

Anyway, the possibilities are fascinating.

-------------------------

To the programmer or Clones:  it seems like this weak terrain idea can work out quite some havoc on multiplayer gameplay!  Though it might need to be constrained somewhat to avoid being too cheaply exploited.  But I'd say it's worth thinking about.

[Essman]

However, it just occurred to me that at game time, you'll need to track weak terrain differently from regular one-way walls and steel. &#A0;Because for the whole scheme to make sense, we need to keep track of weak terrain at a pixel level, since the weak pixels don't stay in one place but will likely fall down during gameplay.

So memory-wise this is more expensive than steel or one-way walls. &#A0;However, we can keep this manageable by limiting the total number of weak pixels supported by the game, and have the level editor check accordingly to enforce it.

There are many ways that this can be implemented. I know of an extremely efficient way to do it that doesn't require keeping track of every single pixel that is weak, so the whole level could be weak.
Anyway, this will go on the wish list as something to do after the initial release.

[Conway]

It's an interesting idea, but it sounds far too complicated to be worth while. If it is incorporated, however, maybe weak terrain could be represented by semi-transparent terrain.

 Also, it doesn't seem logical that falling terrain should kill the lemming under it. Lemmings can, after all, be completely embedded in a wall and not be crushed to death! At least, that's the case with every previous version or clone.

[guest]

Well, I see falling terrain as very different from simply being embedded in a piece of normal terrain.

After all, it is falling!    That extra momentum is not something the poor lemmings would scoff at!  Also, when in the case of being completely embedded in the terrain, notice that the terrain pixels still exists at where the lemming is drawn, and therefore the pixels are still supporting each other, so from that point of view the lemmings should not feel any weight or pressure.

But I'm not pressing too hard for falling terrain to be lethal.  The main concept is that as the basher or miner excavates thru, the terrain soon closes on itself.  The cascade-falling idea is also interesting.  Also, although I didn't explicitly mentioned it, since normal terrain are unaffected by any of this, note that you can temporarily or permanently hold up a column of weak pixels with build bricks which are normal terrain.

There will definitely be some complexity no doubt, as is the case of any extensions which involves terrain pixels that can move around.  I'll let Essman decide for himself.

[guest]

Hey Essman, while you're around, I want to ask whether you have enough time to answer some questions regarding the existing Cheapo, in particular about modifying styles.

Basically there is a preliminary plan to add new MIDIs to the music list of certain styles, in particular the XLemmus styles.

I see roughly 2 approaches:

1) if the original .stt file exists we can just modify and regenerate the style.  Unfortunately I don't know if anyone has the .stt files in question.

2) I'm under the impression that it's possible for new .stt files to reference stuff in an existing .sty.  If so then life would be awesome, we'll just make a new style off of an existing one plus the new MIDIs.  But is the referencing thing true or am I just confused?

3) Finally, if all else fails, and here's where you really come in:  either give me enough info on the internal file format of .sty files so I can write a program to turn it back into an .stt file and do #1, or better yet, give me just enough info on the file format so I can attempt to hack the new MIDIs into the .sty files.

And no, it's not acceptable to wait until hell freezes over...I mean, until Dimwit is ready.  (Just kidding about the hell part  )

Anyway, do you have time for this?  I'm hoping it wouldn't be too time-consuming to just educate me on the relevant info.  please e-mail me (guestlevels 'at' yahoo) if we end up needing to pursue option #3.

Thanks!  

[Essman]

Hey Essman, while you're around, I want to ask whether you have enough time to answer some questions regarding the existing Cheapo, in particular about modifying styles.

I'll email you at the address you provided.