Well I had a choice of either that or Rick Roll, but Rick falls more into the torture category.

If it makes you feel any better it did startle me a little, even though I was expecting it. It's one of those tricks that always works.

You're absolutely right about the story needing to be made before the game, but I assumed he had already planned what he wanted in that respect before he started any work on actually making the game. I was just saying that a good game gameplay-wise can not (usually) be made in a day.

Ah, I see. Carry on, then

I know you probably don't want to hear my advice, but I'll give it anyway because it's good.

I've seen you start and stop a couple different projects in a very short amount of time. You seem to be suffering from an advanced case of what is known as Big Game Fever. This happens to a lot of people just starting out making games. It happened to me. Hell, it still happens to me.

This is always the result:

There is only one cure for Big Game Fever. Don't make a big game. It's that simple. Put those ideas on hold for a while.

What you want to do is make a small game that you can actually complete, just so that you have the experience of knowing what it takes to finish a game. Make Asteroids, or Pac Man, or Space Invaders, or a small arena shooter. Something like that. Nothing more complex than, say, Super Mario Bros. In fact, Super Mario Bros might even be too complex to start with considering the number of enemies that you would have to create.

I am being totally serious here. This is good advice. Literally THOUSANDS of developers have struggled through trying to make their Big Game when they're just starting out, and they have all fallen flat on their faces. They will all say the same thing... start small.

Make a small, complete game with everything in it. Title screen, a couple of levels, game over, scoring, music, sound effects, etc. Put a little polish on it. Completing the thing will do wonders for your experience, even if it's a small, stupid game. And it's a HUGE moral booster. Your Big Ideas will still be there when you're done with the small game, and you will have a MUCH better idea of what it takes to turn your Big Idea into a reality.

If you keep starting and quitting Big Game after Big Game, you won't learn anything.

The only problem is that nobody ever listens to this advice. Big Game Fever apparently affects their hearing as well. Perhaps this time it will be different...

Heh, can I call it or what. Even uses the same image from the video I posted.

Sorry newt, I saw that one approaching from orbit

To play wait for the tiles to auto arrange, and then drag the corresponding tiles together.

http://dl.dropbox.com/u/666516/Matchgamestart.exe

Calling that it's some kind of jump-scare thing a-la that maze game:

Downloading now, will report back...

Scary isn't about gameplay. Most other types of games have enemies that you kill and want to kill you, etc. Scary games are no different than any other games in that regard.

What makes a scary game different is the story, and character development. And psychologically messing with your player's emotions. You can't make something scary in a day.

So, Jayjay, I absolutely disagree with you. Scary games do not start with the engine and controls first. They start with a story. And lots, and lots, and lots of pre-planning before you ever even start coding.

Once the story is down, you can make whatever game mechanics and control scheme you need to fit the story.

First off, don't use your character sprite to detect collisions. You should use your Pbox object.

Secondly, your worm animation is changing size much too dramatically to use Bounding Box collisions. You need to either use Per Pixel, or redesign your worm so it's more consistently uniform, and then give it a collision box similar to your player's Pbox.

Thirdly, you have some really odd conditions here, and I don't understand why you would need them:

<img src="http://i55.tinypic.com/123pbw9.png">

Why is the worm's attack animation important in figuring out whether or not there is a collision? Why is the player sprite's angle important? You're trying to do too much at once in one event, and you're getting your order of events all wonky.

You need to think a bit more logically about how the attacks take place. As a general rule of thumb, when making your conditions you need to filter them from the very basic (two sprites colliding) at the top, and work your way down towards the more specific things (is an animation playing?) towards the bottom, or in your sub-events.

So, what is the very first thing that happens when checking for an attack? Two sprites collide, that's what. What next? Well, you need to know if the player is falling, or if he's just standing there. Etc. This other stuff either isn't important, or it's out of order, and that is the reason your combat is behaving so randomly.

Well, how does the AppPath thing in Construct work? I would take a look at that and try to... er, copy it .

Anyway as long as you can change the path at runtime then that would be fine. Then developers can create their own "where do you want to save your screenshots" option in their games themselves.

Okay, here you go:

http://dl.dropbox.com/u/529356/Construc ... ceship.cap

Hope this helps

Since you called me out by name I'm tempted to just ignore this

But... fine. I will answer. I no longer have that .cap. But it was pretty simple to make the first time so I will try to whip something up real quick...

It's probably not the platform behavior messing up, it's coded pretty solidly. It's likely my clumsy fingers just mashing the jump key a split second too long.

Still, if you gave a little more clearance and a little more room to make small mistakes in the early levels, it would make the game much more approachable to more people. Slowing down the spike wall would be good as well, and you can make it gain speed every few levels or so.

Like I said before, just allow people time to get used to the game gradually. The first few levels should be challenging, but not necessarily "hard." Since you're an expert at your own game the first few levels might seem like really boring levels for babies, but that's just not the case. Expertise comes with practice. You can't practice if you can't get past the start.

Another thing that keeps game levels interesting, and will keep players engaged, is a good level flow. Take a look at how other games set up their difficulty within a level. The start is usually somewhat calm, then the action ramps up, then there's a truly difficult bit, then it calms back down again for a moment. It's like a wave. Easy bits followed by hard bits, repeated over and over until the level is done. If it's all hard all the time there is no chance to catch your breath, and people get frustrated more easily and are more likely to put your game down.

Of course there is always a niche for super-hard games that start off hard and stay that way. And if that's what you're looking to fill then that's cool too. Just keep in mind that not everyone enjoys maso-core games like that. It's just a matter of which audience you're trying to reach.

> There's a built in save feature, and i think it's supposed to work quite well, but check the bugtracker. I've had poblems with it in the past.

>

In some of my own tests, I've found that it tends to load layouts with very few assets quite well, but when you get into layouts with a lot of on-screen assets it has trouble. In my own case, save and load has actually caused the game to malfunction completely in very strange glitchy ways.

I haven't ever used the built-in save feature myself (I have used INI's like Jayjay mentioned though), but would it be possible to have a very small, bare-bones save screen layout to save and load from at runtime?

Like, you hit pause and transition to a separate save/load layout with a simple UI. Hit the save button, and it stores all the globals you need. Hit the load button to load them. Then you can transition to whatever level is stored in your "currentLevel" global or whatever, and populate any scores, powerups, stats, or whatever with your other globals. Would that be one way around the lots-of-assets-to-load problem?

Edit:

By the way, if you are using INI's to build levels (by saving the size and position of platforms and enemies, for instance), then it is possible to store those in the game itself with simple hidden text objects by useing the Text Manipulator and the File objects.

Step 1:

On level load, you read the INI file information stored in the text object.

Step 2:

Use the Text Manipulator to save that text information to a temporary INI file in the game directory.

Step 3:

Use the INI object to read the info from the file you just created and do your level building loop.

Step 4:

Use the File object to delete the INI file.

This can all be done in one tick, seamlessly. In fact I'm not even certain that it writes an actual file to the drive because it's being created, stored in memory, used, and deleted all in one fell swoop before Windows has a chance to process the write command. Anyway, this is how I did dynamic level loading for my game Vert, which only uses one layout for the entire game (even though there are only two levels ).

Of course, with Rojo's new Resource plugin you can just store whatever INI files you want in the .exe itself without any fancy tricks like this, I'm just saying. Well, obviously you can't CHANGE the contents of an INI stored in the exe, but you can save basic level building data.

Rojo, since you are now helping to develop Construct Classic, is there any way to incorporate this functionality into the main features of the program? It really seems like this kind of thing should be part of the program itself, and not a separate plugin. Fonts especially, since I believe it was originally planned that you be able to embed font resources anyway, and that feature just fell by the wayside somewhere over the course of development.