Here's the first tutorial on random maze generation.

Once you've read through the tutorial, you will get the chance to enter your own maze size, and watch it being generated using the exact algorithm described in the tutorial.

http://www.mediafire.com/?wuyw93w42d0

Sponge.

Sorry for the delay guys.

I've been swamped for the past week, and when I did get some time to finish it today, I came across a Construct bug which seemed to affect the enabling/disabling of groups (which I can't seem to reproduce now).

Anyway, it's pretty much finished, so it should be up in the next 24 hours.

Tutorial #2 should follow in days, because it's basically a way of optimising the algorithm, which is important for larger mazes.

Cheers,

Sponge.

Maybe it's a Vista issue? Does anyone else use Vista and experience slow starts?

No problems with Vista 32-bit Home Premium here.

Takes about 2-3 seconds for a large app to preview.

What about your firewall?

Maybe try it offline with your firewall disabled and see if that helps.

Sponge.

Hmm, that's interesting.

I wouldn't have thought that anti-aliasing the text would use up too much memory, even with a lot of text fields.

Maybe the Devs would be interested in hearing about this.

Sponge.

I suggested this a month or so ago, and one of the Devs (I think it was Rich, without checking) said that they could do with that feature for their game too.

Don't know if that means they're working on it or not though.

My top-down driving game uses a huge area of land, and the minimap shows the full layout.

I think we'd all like to be able to zoom in to just show a couple of streets at a time, like GTA or Saints Row.

Sponge.

Nobody is laughing mate, but it does look like you need to do some of the tutorials to get you up to speed on the way Construct works.

As for your problem, you've added an extra instruction that sets the variable rather than adding an extra condition.

Delete the statement that sets your variable in line 5, and then right-click the condition and select "insert new condition", as illustrated below:

<img src="http://img21.imageshack.us/img21/103/ex1l.jpg">

It should then look like this:

<img src="http://img21.imageshack.us/img21/7213/ex2d.jpg">

Now you'll need to delete the first 3 lines in your program.

I don't know what you were trying to do there, but they don't have any conditions.

You also appear to have some blocks hidden on layer 2, and I had to move one of them before I could get to the door when I ran it.

Your next stop should really be the wiki and the many tutorials available.

You'll soon get the idea.

Sponge.

I agree that it's probably something to do with having a While and an Every in the same condition.

Personally, when I want something to grow/shrink/move etc independently, I create a group that updates the object every 'n' m/s, and make the group self-terminate (disable) when it reaches it's target.

So you can enable the group when you want it to happen, and then just leave it to it.

Sponge.

I think what he's after is for the HUD to look like it's a separate screen to the game screen, without anything on the game screen able to go behind the HUD, so it looks like the game screen is the only part scrolling.

If that's what you're after, then I'd avoid the layout in layout approach too, and us the "top layer for HUD" approach as mentioned above.

Then add dead space to the bottom of your game screen, so that the action can't scroll down to that area, and when you've scrolled down to the bottom of your layout, it will look like the visible area that your characters have reached are the end of the layout.

So, if you have a HUD that 100 pixels high, make sure you have nothing for the bottom 100 pixels of your layout, and make sure that your moving objects can't move onto it.

Hope I explained that well enough.

Sponge.

Any chance of a random-maze algorithm tutorial?

Have you not seen this?

The first of the Random Maze Tutorials is nearly ready for release.

I just have to finish off a few things first.

Should be finished by the end of the week.

This first one will focus on a simple algorithm for creating random mazes, going into detail about how the coder should approach the tasks, before allowing you to set the size of a maze and watch it being generated.

As you can see from the screenshots, as well as the size of the maze, you can control the speed of the generation and the zoom level.

You can also decide to have the camera follow Pacman (who's kindly volunteered to carve out our maze for us), or have control of the camera with the right mouse button.

I should point out that originally I'd planned to release this as a documented .cap file, but during the changeover from 0-based arrays to 1-based arrays, I decided to start again without using arrays (to save waiting) and the program uses detection instead.

As this isn't a method that anyone would use when creating a maze for their game, there is no value in releasing the .cap.

Because of this, I've made the tutorial very detailed on the specific aspects of maze creation, with plenty of diagrams, so as long you're comfortable using arrays there's no reason why you'd need the cap file anyway.

Sponge.

As a couple of people have already pointed out in this thread, the "Hide" is greyed out in the right-click menu.

Is this going to be brought back in the next build?

I was going to use an array, but using a listbox will save me having to manually shift the numbers down the array and shorten the range each time.

Nice one!