Suggestions for a new Cheapo Copycat game

[guest]

Also, for the fallers and floaters, when the number of the countdown would be to 1, it could be nice to hear the "oh no!" at this moment! It could be more realistic!

That would be neat but would be impossible to do correctly.  The issue is that the game cannot always correctly predict in advance how long the lemmings would be falling for.  For example, imagine the floater is landing on a location where another lemming is digging, or where a builder lemming is about to reach.  And now consider the fact that I might cancel the digging or building at any point, so you might not be able to tell the final fall height until the last moment.

[guest]

Let me correct what I stated above.

You can of course always have your faller/floater say "Oh no" at a countdown of 1, as your suggestion literally suggests.

The point is that if you do that, sometimes your faller/floater could end up saying "Oh no" twice, and in general it is not possible for the game to correctly predict this situation and prevent it.  Alternatively, if you restrict your faller/floater to say "Oh no" just once, then you will get cases where the faller/floater landed and walked for a bit, but having already said "Oh no" at countdown=1, wouldn't be saying it when it actually raises his arms and explodes as a walking lemming normally does.

[Essman]

Sounds cool! Is there an estimated release date?

Not yet.

[DragonsLover]

Yeah guest, you're right!

[guest]

Minor feature request but useful:  can you make Cheapo support Windowed mode, as well as Full-Screen as it does now?

The obvious advantage of windowed mode is that it makes life easier when you want to switch back and forth between apps.  It's also less annoying when, for example, another app that's running in the background decides to pop something up (Windows update being a nice recent example).  I know not every video card supports it, and I found that many people tend to prefer full-screen modes in their games, so that's why I'm suggesting supporting both.

By windowed mode I of course don't mean the user can arbitrarily resize the window during the game.  Instead, maybe through a menu option the user can select a window size from a predefined list.  Most likely the window size will simply be the list of standard screen resolutions, like 640x480, 800x600, 1024x768, and 1280x1024.

Or maybe the game is currently fixed at 640x480 (as it seems to be the case).  Then you could just offer the option to have only windowed 640x480.  I have to admit that's probably a bit small for most people, but there are still occasions where it might be useful.

[Essman]

Minor feature request but useful: &#A0;can you make Cheapo support Windowed mode, as well as Full-Screen as it does now?

Yes, ever since I've started working on this new game, it has supported windowed mode and full screen mode. The level editor MUST be run in windowed mode, but the game can run either way, in many different resolutions.

[DragonsLover]

New suggestions:

1. In the editor, at the same time we could edit the levels, have the possibility to hear the music we chosen for each level with an option to turn on/off the music. Of course, for a new level, just play the music of the title screen.

2. Still in the editor, it is possible to hear musics. But what about sounds? It could be nice to have a window with a list of each sound and then have the possibility to hear each of them.

3. Still in the editor, it could be nice to hear sounds when activating objects (traps, trapdoors...).

4. Have a hand tool to move entirely the level around (landscape and objects).

[guest]

3. Still in the editor, it could be nice to hear sounds when activating objects (traps, trapdoors...).

Isn't this covered by suggestion #2?

[Essman]

1. In the editor, at the same time we could edit the levels, have the possibility to hear the music we chosen for each level with an option to turn on/off the music. Of course, for a new level, just play the music of the title screen.

Wouldn't that be more annoying than useful? Still, I'll put this on the wish list.

2. Still in the editor, it is possible to hear musics. But what about sounds? It could be nice to have a window with a list of each sound and then have the possibility to hear each of them.

I have added this functionality already.

3. Still in the editor, it could be nice to hear sounds when activating objects (traps, trapdoors...).

Okay, I'll add that.

4. Have a hand tool to move entirely the level around (landscape and objects).

I think this has been asked for already. So this is probably important and I'll add it. I already have a dialog that lets you shift the level around, but I guess a "hand tool" is easier to use than a dialog where you input pixel values.

[Essman]

The 'shift level' dialogue will still be available, won't it?

Yes.

Also, I've been thinking of an interesting feature involving moving terrain...
I realise this could be difficult to program, or even to define the rules of...
It could get very confusing, but also very interesting. What do you think?

Ignoring any problems with defining rules or programming: I think that the timing issues it would cause trying to solve levels would drive people insane.

[guest]

The 'shift level' dialogue will still be available, won't it?

I want to add my vote to have both available as Conway suggested.  That way I can use the handtool for coarse adjustments and the dialog for fine adjustments.  presumably the handtool will be an icon on the toolbar, while the dialog is accessible from the menu in the same place it currently is located.

Also, I've been thinking of an interesting feature involving moving terrain.<snip>

 &#A0;I realise this could be difficult to program, or even to define the rules of. For instance, if a lemming falls and is intersected by the side of a moving piece, will he then be encased in it?

If the terrain is already carrying the lemming around as he's walking, then logically, I would expect the terrain piece to actually "push" the lemming in the above situation.  That is, the lemming's fall trajectory gets shifted by the moving piece.

How about the case where a bridge being built on stationary ground gets into the way of the trajectory of the moving terrain?  Will it affect the moving terrain?  Or will be the bridge be affected instead?  Or both?  Or neither?

How about situations where the terrain piece moves partly out of bounds?  Or the terrain piece itself is within the screen, but the lemmings walking on top of it is no longer within the screen bounds?

What about intersection of terrain pieces themselves, be it moving against moving, or moving against stationary?  Especially regarding the behavior of excavation lemmings who happens to be at the boundary of intersection?

Of course, for a lot of these questions, I suppose there's always potentially an easy way out (sort of) involving things getting destroyed, be it the lemming, the bridge, etc.  

Or if one builds from a moving platform, will his bridge move as well? Or if a moving piece is metal, will its metal property be carried with it?

I would expect it to.

It could get very confusing, but also very interesting. What do you think?

Interesting, yes.  But I doubt we'll be seeing this in the next release.  Maybe the next next version if Essman feels up to it.  And someone better make sure they carefully work out all the situations this could lead to, so that this feature doesn't become a breeding ground for bugs/glitches.

[Conway]

The 'shift level' dialogue will still be available, won't it?

 Also, I've been thinking of an interesting feature involving moving terrain. When you add a terrain piece, you have the option to make a path of a few points for it to follow, either back and forth, or rotating if the path loops, and a speed which the designer can set. When a lemming walks or falls onto a moving surface, it then carries him but he still walks across it and treats it a normal terrain.

 I realise this could be difficult to program, or even to define the rules of. For instance, if a lemming falls and is intersected by the side of a moving piece, will he then be encased in it? Or if one builds from a moving platform, will his bridge move as well? Or if a moving piece is metal, will its metal property be carried with it? All these variables can be set if you have a moving area which contains the piece, and have everything - all terrain, objects and lemmings, moving together within that moving area.

 It could get very confusing, but also very interesting. What do you think?

[guest]

Ignoring any problems with defining rules or programming: I think that the timing issues it would cause trying to solve levels would drive people insane.

It has the potential to create some nasty timing-related puzzles, but like anything else, it can be used for good or for evil, so to speak.

Here's an example of moving terrain that may be interesting without being nasty:  take a simple, flat horizontal moving platform made of steel, with a vertical pole in the middle (also part of the moving platform) also made of steel.  Above it is a stationary platform from which the lemmings will fall onto the moving platform.

The moving platform is moving such that at certain times, the vertical pole will be to the right of the edge of the stationary platform, while at other times the pole will be to the right.

Notice what this means:  the moving platform effectively becomes a sort of "splitter" for a stream of lemmings (at least if the stream is not overly compressed), where given a stream of lemmings heading towards the edge of the stationary platform, after falling onto the moving platform and then off that, some will be facing left while others are facing right.

This could lead to interesting puzzle possibilities without necessarily requiring timing.  (Of course, it could also possibly lead to backroutes that involves timing.)

[guest]

The moving platform is moving such that at certain times, the vertical pole will be to the right of the edge of the stationary platform, while at other times the pole will be to the right.

In case the typo isn't obvious, that last word should be "left" not "right".

[Conway]

Yeah, I realise it could get nasty, but I suppose a level designer would only use moving pieces if he/she was willing to fully experiment with the level to notice any backroutes. Unless, of course, the level is the sort that's just for fun with no intended solution, just many possibilities.