Even easier, set the x position to player.x-(desired width of bar/2) and the y to player.top-some amount.

Imagine an image of a circle. There's a lot of wasted space in the corners, right? They would often stuff those wasted spaces with other stuff and reassemble it all every frame.

I would love a solution for this, but if such a fix gets implemented it would probably have to wait for construct 2.

Casual games are huge, and have an established audience. They're also smaller in scope, but that doesn't mean they're a cinch to make!

To be honest, I feel somewhat uncomfortable giving advice on the subject as I don't have any first hand experience in the market. All of my knowledge of the topic comes from lots of research, and the only consistent theme I hear from small developers is that most at best only sort of know what they're doing and even the successful ones are often fumbling around trying to determine what will make them more successful. You read some of their blogs about like advertising or something and they give stats, only to mention in the next paragraph that the stats don't necessarily mean anything for whatever reasons.

The advice I feel comfortable giving: do your research beforehand, make sure an audience exists first before making a game (but make sure it's still something you want to make! If you make a game you don't want to make, it'll show). You don't want to make a game only to find out afterwards there's no market for it!

For example, the audience for hidden object games is very large right now, but then again it's probably not a good idea to make one because the result of that is the market's getting saturated and so developers are throwing more and more money at making them to stand out, making it hard to compete.

The whole thing is very complex and I really don't want to give you bad advice. However, if you want brutal, honest business advice there's a lot of good info on the indiegamer forums, and some on TIGsource as well.

Oh, yeah, one more piece of advice. Just because someone says something doesn't mean it's true or that the person knows what they're talking about! Look at what they've worked on to see if they're talking from experience or not. Can't tell you how many people think making whatever type of game is easy before they try it...

If you want to make a commercial shmup with the goal of making money, sadly I've heard from experienced devs that the PC is a miserable platform for it. Not only do they generally require a game controller to be played properly, which PCs don't come standard with, as I hear they don't sell well either.

However, if you're still determined, then here's the review.

Ditch the acceleration deceleration of the ship. Shmups are the twitchiest of twitch games, and if I press up, I expect the ship to go up instantly. It's not realistic, but it plays much, much better and in these games gameplay is king.

All bullets, bombs and lasers need to be easy to spot at all times. Use high contrast to make them easy to spot (watch videos of Ikaruga to see what I mean). Also, the particles from the explosions hide stuff like the lasers too much. Render threats on top of everything else like explosions.

As I mentioned about twitch gameplay, the controls need to be razor sharp. The same frame the button is pressed the bomb should explode, saving the player from what was about to hit them instead of moving to the center of the screen first.

Serious overuse of particles.

Add some way to adjust movement speed while playing. Einhander was awesome that it could be adjusted without powerups.

Periods of way too much waiting while the boss simply sits there.

Needs more impressive weapons (I assume you simply haven't made them yet).

Try using either containers or the pairer object, and make sure there are the correct number of instances at runtime.

I'm using a method like this: there are two variables, currentexp and nextlevelexp. Upon currentexp being greater or equal to nextlevelexp, nextlevelexp is multiplied by whatever amount. If it's *5, then each level *5 will be adding more to the exp needed than it did the previous level.

STAR CONTROL 2

Love that game. Still listen to some its music every once in a while, along with the 3DO versions.

All of what you mentioned is possible with construct, but it sounds like a rather complex game and as such won't be easy no matter what engine you use.

Let me give you some advice - don't make your dream game first. Games are deceptively difficult to make and you're going to make a lot of mistakes while learning how to make them, which becomes a real hassle when working on a large project. Start with something small, much smaller scale and much smaller scope to learn how to make games so you don't overwhelm yourself with a project you're not ready for. What's more, with the lessons you've learned, your dream game will be more awesome because of it!

That said, even 'simple' programming languages go straight over my head, but I find construct easy to understand. I've tried a lot of game creation tools, and nowhere else have I found anything so powerful and easy to use.

First, don't use system compare to check y positions, because it doesn't pick objects. Doing that doesn't make the cap work, though, because it picks all the buildings with a less .y, and doesn't know which one to put the player in front of.

What I recommend doing is putting all the objects you want to sort into a family and use the event:

if family is on screen

for each family (ordered): family.y ascending

• family bring to front.

Keep in mind though that 'is on screen' doesn't take into account zoom or screen rotation, so you might need to use a different method of determining what's on screen, like putting an invisible sprite over the screen, setting it to box collisions and check for collisions with the family.

You could use PR's method, but I think this way is easier because all you need to do to get another object to sort is add it to the family.

You can already achieve the same effect, without fps issues, of switching models by using two different 3d objects.

I'm talking about the object bar that's to the right of the properties, the one that's listed in the ribbon as home>bars>objects.