ooo, definitely worth looking into, thanks for the headsup

Windwalker Which updates do you mean? My main concern with pathfinding was that I'd have to regenerate the obstacle map each time a tile is mined, which causes a very noticable stutter (or did when I last tried it) so it didn't seem ideal for this.

Ha, I'm not sure the Greed capx would be much help for you - the engine's quite complicated and I don't make many notes! I'd really recommend you try this tutorial

dilk Take a look at my project Greed

pixel perfick Hmm, I kinda wanted it to feel like a twin-stick shooter - sorta like an arcadey Smash TV-type setup. As mentioned above, you'll eventually have to run around while dodging/hitting enemies, firing off spells etc, so I think it makes sense to have separate directional controls to attack. I like the idea of auto-mining when you push up against a wall though, I'll give that a spin!

Joannak Thanks, that's good to hear. This game is definitely destined for desktops/laptops rather than mobiles, so as long as the framerate holds up on a reasonably capable machine I'm happy!

I agree about the digging, I think that's to do with the way the dwarf sprite is drawn and animated. I'm using a "Hitpixel" sprite to determine where his pickaxe lands, which is always set to 16px away from the hidden, central "Dwarf" sprite, so the collisions are consistent at least - it just doesn't always look that way. I'll keep tinkering with the sprite until it feels right.

RE the spells, I plan to have a "Map" pickup on every level, which will reveal where the rooms are (but not anything else). The spells will be in the form of different enchanted rings that can shoot various energy bolts (fire, ice, electricity etc) - you'll be able to equip up to 2 at a time and shoot baddies with them instead of having to getting close with the pickaxe, but you'll be limited by a slowly recharging mana reserve. Also there'll be bombs, potions, pickaxe upgrades, all that good stuff, but that's some way off yet!

My biggest problem at the mo is deciding how the enemy AI will work. Since the obstacle map is constantly changing, pathfinding isn't really an option, so I need to get a bit clever about how they'll move around. I have some basic stuff set out but it needs a lot of work... anyway, enjoy the tunnels while they're still rat-free

goyo666 Sure <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile"> I'm a bit obsessed with procedural generation at the moment - this is my first project that uses it and while the engine still needs quite a lot of work, I'm pretty happy with how it's going. I started with abhilash's procedural generation tutorial (http://www.scirra.com/forum/procedural- ... 43387.html) and while I didn't end up using his miner method exactly, it was a great introduction to concepts like nested loops and using arrays to generate a map (fun fact: until a month or so ago I'd never used either, I thought all that stuff was too advanced for me…). I definitely recommend that tutorial for anyone who's interested in proc genning in Construct 2.

The engine works in steps - first I fill the map array with the value corresponding to "EarthTiles", then I do some miner method-type stuff to add the "BedrockTiles" value, then the gold seams, then some oblong-generation stuff to add the rooms and walls, then the tunnels. There are safeguards built in along the way to make sure things don't get too messy - eg tunnels can't overlap floor tiles in rooms, and rooms can't overlap bedrock or each other. The rooms were probably the most complicated bit, I spent ages getting those right!

Then there's the final step where I use the array to generate the actual tiles: most of the tiles are made using a Tilemap object, but some are good old sprites for convenience of working with the lighting system. The end result is that I have a bunch of variables I can play with to adjust the amount of rooms, bedrock, gold, tunnels etc on the map. I know I haven't provided too much detail here, but I'd be happy to PM you the capx and explain a bit more if you like <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

The lighting's comparatively simple: I have a layer of darkness (nontransparent black background) above the main layer, and I'm generating "lightwindow" sprites on this layer which are 46x46 black circles set to Destinationout. Whenever a lightwindow overlaps a floor tile sprite, it generates another lightwindow on that floor tile - because the tiles are 16x16 and the lightwindows are 46x46, this means they "radiate" out and don't spread to any tiles that aren't floor.

Because the lightwindow sprites were building up and affecting framerate as the player explores, I started using Rojohound's fantastic Canvas plugin: whenever a lightwindow is generated, it's pasted to the canvas and destroyed after 0.2 seconds, which is a much more framerate-efficient way of doing it (1 object instead of thousands! Same with Tilemap).

Argh that was a long post, but I hope it helps a bit! As I say, happy to chat a bit more about it and share the capx in PM - but definitely check out abhilash's tutorial, that pretty much laid the groundwork for everything I've done here.

Thought I'd post a little preview of what I'm working on - a procedurally-generated mining/roguelike/bullet hell/Gauntlet-ish kind of thing, tentatively titled Greed.

Updated 26/1/15

Latest version here. Feedback appreciated!

WASD to move, arrow keys to shoot, space to drop bombs. I for inventory, M toggles map view, L toggles lighting, Q and E to switch rings. Find the rings, collect the loot!

Check the devlog for all the latest stuffs.

Guess I'd better get testing then, thanks for replying!

This looks amazing, great to see what you can do with Construct! You got my greenlight

Looking great I like the spells!

I realise this is kind of a "how long is a piece of string" question, but what's a good upper limit to have for the number of sprites in a layout?

As a bit of background on this, I'm working on a tile-based mining game. At first I was generating every tile sprite individually, which meant I was starting every layout with around 7,500 16x16 sprites from the get-go. I've since switched to using the TileMap object and the framerate gain has been phenomenal, but it's got me thinking about more ways to improve efficiency.

For instance, I have a black "darkness" layer above my main layer, and I was generating a Destinationout "lightwindow" sprite every time the player mines a tile, so that only the area that's been mined out is illuminated. These lightwindow sprites mount up after a while and start impacting framerate, so I started using Rojohound's very excellent Canvas plugin, pasting the lightwindow to the canvas and destroying it on creation. This works nicely, but a one problem is that pasting to canvas causes a very slight stutter, so the compromise I'm considering is to let the lightwindow sprites mount up until they start having an effect on framerate, then pasting & destroying them all at once - this way the stutter only occurs occasionally.

Anyhoo, with this in mind, how many sprites is too many? I realise all systems are different and games will always run less well on less capable machines, but are there any good rules of thumb for this?