At this point, it would involve a lot of work, so there aren't really many examples of tile based games. It also has the disadvantage, where displaying many tiny objects (tiles) can slow the game down, if not done properly.

So, basically it is an unexplored territory. I've dabbled a bit, but right now I am busy with other projects, before I get back to it. My next major game project will be tile based.

Therefore I suggest that you experiment. Keep experimenting, until you come up with an acceptable solution. There are some others working on tile engines, they may have a few tips.

The most important thing to note - destroy objects that are offscreen and create them before they come onto screen.

Well, you have to take chain and more-than-3 elimination into account. The premise is simple, but execution - especially smooth and failproof - can be a little tricky.

It can be done with simple condition checking (if a bit slower than array):

For each block on the field, check if it has any neighboring blocks of the same color. If it finds one, check that block's next neighbor - that is in the same direction. If there is one, mark for demolition. Do this for EACH block on the field.

Then, once checks are done, start the demolition. Whee! Fireworks! After that, collapse the pieces or whatever and repeat the check, until there are no blocks that meet the condition, then allow the player's input.

This method has the advantage of streamlining; you can use fancy animations and stuff!

Pseudo code:

+For each block

• Are any of its four neighbors of the same color?
• Check that block's adjacent block, that is in the same direction

> Mark these blocks for demolition

When done checking all blocks, DEMOLISH! Then re-check all blocks until NONE are marked for demolition and wait for player's move.

That totally blew my mind.

Seems one needs the Advanced Camera plugin to open this cap.

Oh well, I can only speculate at this point. If the bullet is duplicating, then it must be a duplicated trigger, event or action. It may not be always apparent; are you using two instances of Mouse and Keyboard object? Only one global instance is enough. Next check any conditions related to firing; perhaps it is allowing two triggers before it clams. Then check actions, sometimes it is not apparent but some people mistakenly duplicate the spawning event.

Moreover, check if the bullet isn't in a container with another bullet, though that sounds silly by itself - objects cannot be containers of themselves.

Just a few tips to tide you over until someone with the camera plugin can dig in.

Think pacman movement.

Actually, roofs, treetop and stuff could be drawn on layer above, only including obstacles on base layer (where player is located). So, you'd use two-level array (or more if you include more levels). Then you draw additional stuff on these layers with offset, turn on/off for visibility etc.

I've not been using Perlin Noise because I'm not really working on any projects right now, the month being November. Busy NaNoing

But yeah, the plugin you propose would be immensely useful, not only for dungeons, but for other applications - imagine a randomized town, for example.

So looking forward to your plugins after I'm done with my novel!

Isn't there a way to bypass the problem? Is that feature really necessary?

Split your sprites up into components - body, shirt, lolpants and turban. You could choose the tone of skin, different color combinations of clothes etc.

Of course that means you'd have to do exact animations for all parts.

There are certain issues with copy&pasting between projects, so I tend to avoid it where possible. Copy&pasting graphics etc. is safe, but events, objects and stuff aren't so safe.

I tend to create a project template, barebone .cap, which includes the basics that I repeat a lot, then I create new projects from that template.

Sprite for custom pointer appearance, slap mouse behaviour onto it and there you have it.

I, for one, welcome our robot overlords.