Suggestions for a new Cheapo Copycat game

[guest]

Here's one possible (but highly incomplete in its definition) way for the program to handle moving terrain, as a reference for future considerations:

1) moving terrain is organized through a logical object known as a container.  A container is a transparent frame (the frame itself is not visible though) that "holds" a set of terrain pieces (or using the current way to dealing with terrain, the actual terrain pixels) and also a set of interactive objects.  Containers also have a position within the level, a defined route it will execute throughout the level, as well as various parameters defining how the container will move through the route (eg. speed).  When the container moves, its contained elements move with them.  This includes the contained terrain pixels and interactive objects, and possibly one or more lemmings during game time.

Different containers can intersect each other, either as the initial level setup, or more likely at some point during game time.  There is a z-order associated with containers, so that when objects from different containers overlap, when painted on the screen one will obscure the other based on the container z-ordering.  Intersecting containers do not interfere each other's movements, just as lemmings move through each other.  Notice that the terrain pixels from different containers are kept track of independently, even when an intersection of containers occur.

2) All levels have at least one container, whose size spans the entire level area and its stationary.  This is the "default container" for holding terrain and interactive objects.

3) The tricky issue of course is how lemmings fit into this.  A scheme is needed to define when lemmings transfer from one container to another, and also how their positioning is affected when they are contained in a moving container.

The general idea though is that, as long as a lemming is always associated with exactly one container at any time, then the pixels resulting from builders are also associated with said container.  Excavation should result in pixels of the lemming's container from being removed, although it's still an open issue whether pixels from other containers might be removed as well, in situations where there are overlapping of terrain pixels from different containers.

This area still needs to be worked out, but one idea is that whenever the lemming is falling, he will be transferred to the default container.  Landing is defined to be when the lemming's current position is a terrain pixel from any container, at which point the the lemming is re-associated with the container.  If at that pixel position there are multiple pixels from different containers, the game chooises one container, say the way with the highest z-order.  (This is in line with how the game currently handles overlapping interactive object trigger areas.)

Anyhow, this is the tricky part that needs to be worked out with some thought, but hopefully this helps define a starting point for how to implement the moving terrain idea sometime in the future (probably not the near future, but anyhow).

It should be noted that from a level design point of view, I definitely do not recommend purposely creating situations where terrain pixels or even interactive object pixels from different containers overlap during the course of the game.  However, this is practically impossible to accurately check for at level-editor time (unless you're willing to be very restrictive), and given that the terrain pixels for a container is not fixed anyway (due to excavation and bridge building), in a sense it is truly impossible to check for.  This is why I believe for simplicity the game engine needs to consider situations where pixels from different containers might overlap.  The simplest approach would of course be to treat pixels from different containers as independent, but this needs to be carefully orchestrated with the behavior of the lemmings and the player's intuitive expectations.

[Conway]

That is quite a detailed plan, Guest. Most of it is what I was thinking, except for the part about builders. If the moving container only overlaps the terrain that moves initially, a builders steps wouldn't be contained in that moving container if the builder starts from the uppermost edge of the container, ie, the surface of the moving platform. Unless the game automatically extends the moving container to contain any builder's steps when they are built. Is this what you meant?

  Also, in the level editor, surely there would be the function to turn on one or all moving containers to see how they will interact.

  I believe also that when a moving terrain temporarily moves outside the confines of the level area, the terrain and objects should be preserved, and any lemmings taken with it should die, as they do anyway when they walk or fall outside a level.

  I know it will be complicated, Essman, but PLEASE consider it, even if it delays the release by a few weeks!

[Essman]

I know it will be complicated, Essman, but PLEASE consider it, even if it delays the release by a few weeks!

I liked that design description, it's pretty close to how I would implement the feature. But I'm not going to implement it in the first release of the game. While it may seem like it wouldn't take a long time to make, it would take me many months because I have very little free time.
I think what I need to do now is make a web page that describes what the level editor can do so you guys can get a feel for how it works. It'll basically be screenshots of the menus and dialogs with explanations.

[guest]

I think what I need to do now is make a web page that describes what the level editor can do so you guys can get a feel for how it works. It'll basically be screenshots of the menus and dialogs with explanations.

Sounds good.  Actually, I'd suggest that some version of that webpage (or even just a URL shortcut to it) eventually be included in the final product as some sort of help file.

[Essman]

Actually, I'd suggest that some version of that webpage (or even just a URL shortcut to it) eventually be included in the final product as some sort of help file.

But of course.

In case anybody still cares, I started a web site here:

http://spadapet.members.winisp.net/dimwits/

Most of the sections are empty, but I did fill in the part about the level editor's menus. So at least you can see screenshots of most of the dialogs in the editor.

[Conway]

Oooh! It looks so cool! B) I can't wait. Just a few things . . .

  I don't think it should be possible to use any bitmap as a background when designing a level, or it could lead to some very cheap tricks and crafty levels.

  And the level dimensions have to be a multiple of 16? That's not so bad (although it's still a step down from the current cheapo, where it uses multiples of 10). But why does this also apply to shifting the level?

  Also, maybe it would be a good idea to reduce the minimum level dimensions to something ridiculously small, like 32x32. This would be useful for designing wraparound levels, anyway. And maybe for non-wraparound levels smaller than the screen size, it could have a black border or something.

[guest]

&#A0;I don't think it should be possible to use any bitmap as a background when designing a level, or it could lead to some very cheap tricks and crafty levels.

Then what do you propose?  I'm sure no matter how extensive a set of backgrounds Essman provides someone will want to have their own, especially in conjunction with style editing.

Can't we just trust that people here are sensible?  

(Incidentally, parallax scrolling would be a good way to avoid having backgrounds that can be confused with things in the foreground......)

[Conway]

Well, in the current version of cheapo, the style designer can choose to have non-interactive objects (i.e. background) identical to the terrain pieces, but if the designer chose not to, the level designer couldn't add their own background, besides choosing a plain colour. But the preview indicates that it will be possible for the level designer to paste from the clipboard, either as terrain, or as background. When I first released my Sonic cheapo style, I was told that having some terrain identical to background could be used to make very sneaky levels, and I agree. So why not have it as it is in the current version, where the level designer can only use background from the style, and not paste it from the clipboard? (But, of course, still allow the pasting of terrain!)

  Also, what is parallax scrolling? If it's where the background scrolls at a slower rate to the terrain, to indicate that it is in fact behind the terrain and everything the lemmings can interact with, that would look very sleek and 3D-ish! And that way there would be no room for confusion. Except, of course, in non-wraparound levels no bigger than the screen size so you can't scroll. But other than that it sounds like a very good idea.

  One more thing: Guest, are you Essman?

[Essman]

And the level dimensions have to be a multiple of 16? That's not so bad (although it's still a step down from the current cheapo, where it uses multiples of 10).

16 pixels is equivalent to 8 pixels in the old game (since the minimum resolution has doubled). Some things process the level in chunks of 16x16 pixels, so the size has to be a multiple of 16.

But why does this also apply to shifting the level?

Actually, the level could be shifted in multiples of 8 rather than 16. I'll look into changing that.

Also, maybe it would be a good idea to reduce the minimum level dimensions to something ridiculously small, like 32x32. This would be useful for designing wraparound levels, anyway. And maybe for non-wraparound levels smaller than the screen size, it could have a black border or something.

I'll investigate the reduction of the minimum level size, if you really think having a canvas smaller than the screen will help create levels that you can't create with a 640x400 area.

[Conway]

Actually, the level could be shifted in multiples of 8 rather than 16. I'll look into changing that.

Then why is it possible to shift levels in the current cheapo by individual pixels, and not in the new version?

  The reason I suggested changing the minimum level dimensions is primarily for wraparound levels, since their quirkiness would increase the smaller the level.

  And Essman, you didn't answer the question about Guest's identity.

[DragonsLover]

More suggestions:

1. Something cool for the "Nuke 'em all" feature: Make the screen flashing in red with an alarm sound instead of nothing...

2. What do you think about animated buttons like in Lemmings 95?

3. I though about to add more tools but not too much. I was looking tools in Lemmings 2 and some could be nice to add and some are so exagerated. Here are these it could be nice to add:

- Runner (where a lemming is faster than the other lemmings)
- Jumper (where the lemming could make a little jump to go higher in front of it)
- Swimmer (lemming that isn't affected by water and swim through)
- Laser Blaster (where the lemming uses a laser to dig a hole over his head, it's like a reversed digger)
- Stacker (could be interesting for climbers and diggers it's when a lemming is building a wall by piling up blocks)
- Platformer (where a lemming could build an horizontally platform over a hole)
- Slider (when a lemming is near a gap, it slides down safely)
- Rock Climber (same thing than a climber, but it is not necessary for the wall to have little holes or bumps for the lemming to fall)

And those where I'm unsure, it depends of you :

- Roller (where a lemming is faster and that falls diagonally without crashing, by rolling)
- Hopper (where a lemming is constantly making high jumps in front of it)
- Diver (where a lemming is diving in front of it)
- Shimmier (the lemming jumps and if it touches the ceiling, it starts to climb horizontally (you know what I mean))

All others are less interesting and some are similar to the normal tools like the Stomper. What do you think about these tools?

[Essman]

Then why is it possible to shift levels in the current cheapo by individual pixels, and not in the new version?

The new game was built from scratch and works much different (internally) than the previous clones. But since you REALLY want to know why the level can only be shifts in multiples of 8 pixels, here's why: You won't be able to see this, but there is an invisible grid of "wind" for every level. To save memory, I have one "pixel" of "wind" cover an area of 8x8 level pixels. It's impossible to shift the level by 2 pixels and have the wind grid get fixed up correctly. Objects in the level will depend on a consistent wind grid. Now, I'm not actually making objects that affect the wind, but it's an option for the future.

And Essman, you didn't answer the question about Guest's identity.

The guest is a user who chooses not to log in, I don't know who he or she is.

[guest]

Also, what is parallax scrolling? If it's where the background scrolls at a slower rate to the terrain

Exactly.  It's the type of scrolling you typically see in SNES platformers.

One more thing: Guest, are you Essman?

"Darn!  My cover is blown!"  X_X


Actually, no.  No idea why you'd think so.  Given that I made my own share of suggestions to the upcoming Cheapo several times, wouldn't it be kinda disturbing if all those suggestions actually came from Essman himself?    

[Conway]

Actually, no.  No idea why you'd think so.  Given that I made my own share of suggestions to the upcoming Cheapo several times, wouldn't it be kinda disturbing if all those suggestions actually came from Essman himself?    

It would make sense. You might have posted suggestions as 'Guest' to get the reaction of other users before speaking about it as Essman himself, maybe for ideas you were uncertain of. I also thought it was strange that you were talking about the new game as if you were a co-designer, and making plans for features yourself. You might have also made suggestions as 'Guest' to encourage others to keep their suggestions coming in, and maybe even so people will think that more of the features have been suggested by other fans and less are your own ideas. Those are just a few possible reasons. Anyway, that's just what I thought . . .

  But yeah, parallax scrolling sounds cool! B) But I still think it's a bad idea to allow level designers to use any bitmap as a background. I also don't like the idea of other skills, at least not initially. If people want to program their own skills, fine, but I don't think it should feel too much like Tribes or even Clones.

[DragonsLover]

And what about my other suggestions?

Conway, why you disagree to add more skills? It could be nice to get more puzzles using new skills. Also, it could be nice to choose which skills you want the player to select for a level. For example, I created a level and I want to add these skills (always 8 ): Rock Climber, Floater, Blocker, Exploder, Platformer, Stacker, Swimmer and Basher for the player to use. I replaced: Climber, Builder, Digger and Miner. Imagine a level with these skills, you can have more possibilities to design levels. But I don't want to force you to agree, it's your opinion if you don't want these ones. I just wanted to tell you what do you think about these 8 new skills. Anyway...