Well I came up with a workaround that'll hopefully keep working as I get farther along in my project. Figured I'd post my hack of a fix here in case someone else was having a similar issue.

Basically what I did was set a condition comparing the layout size to the resolution size. If the layout size is smaller than the resolution size, then it resizes the layout to match the screen resolution.

<img src="http://img51.imageshack.us/img51/8809/fullscreenevents.png" border="0" />

After that, I set the magicam camera up with gridscrolling. That way the player's view will still be restricted to being inside the layout.

The only bug I have right now is upon switching from windowed to fullscreen, where the camera position is set to the top left corner for whatever reason. When the player gets back onto the screen it begins to scroll like normal again. I tried having the camera automatically move to the player when changing to fullscreen, but to no avail. Oh well, I'll try to figure something out.

The layout in fullscreen would have to be at least as large as or larger than your system resolution. I can't predict a system's resolution and I'd also like to be able to future proof. Plus, making 4000+x4000+ layouts isn't a good solution.

Hey guys!<img src="smileys/smiley4.gif" border="0" align="middle">

So I'm trying to make a retro style game here. No real biggy, except that I'm having problems with zoom rates and fullscreen and such.

I've got pretty much the setup Ashley came up with here, except I'm using Magicam.

The problem I run into is that I can't seem to use layout sizes smaller than the window/screen resolution. In this case if I have a 640x480 layout, any window size larger than that and the camera starts to lose its focus on its target, and ends up showing stuff outside the layout (in this case, the white layout background). If the layout is larger than the window/screen size, everything works. Unfortunately system resolutions are variable from computer to computer, and I'd rather not have to have 4000x4000 layouts for just a single room. It'd also be pushing it for a small town in my game.<img src="smileys/smiley24.gif" border="0" align="middle">

I need a way to keep the camera focused on the player properly and to stay within the confines of the layout while zoomed in. Anyone got any ideas?

Here's my cap:

http://dl.dropbox.com/u/20459682/eclipse.cap

Made a music video with Construct Classic! The premise of the video being my bandmate and I running through a whole number of old 16 bit console games my friends and I used to play, in the vein of one of those many speedrun or playthrough videos you find on YouTube.

http://www.youtube.com/user/davidleeband#p/a/u/1/lVZsotFlVpQ

And now to actually get some work done on my original game! Or at least try to figure out if I'm going to use Construct Classic or 2... <img src="smileys/smiley29.gif" border="0" align="middle">

This does look really really cool.

What kind of art style are you thinking of? Or are you open to interpretation?

Can you post your cap, or a screenshot of your event setup / object setup?

I've been playing around with a point and click adventure game, too. It's a bit of a mess to be honest, and I plan on redoing it in a far cleaner manner, but I'm sure there are plenty of ideas, methods, things of that nature that might help you out a little.

I have an inventory, a skill system, a HUD, a combat system, enemy AI, condition sensitive mouse cursor, and some other neat little details going on in this little thing. The game is controlled entirely via the mouse, with the left mouse button being used for movement, attack, item pickup, skill/item use, so on and so forth, and the right mouse button being used to stop movement or cancel out a skill or item or melee attacks if the mouse is over an enemy.

It's a cool little demo (at least I think it is <img src="smileys/smiley17.gif" border="0" align="middle" /> ) of my master project that I'll likely never finish. I plan on using Construct 2 for it when I get around to restarting it, but I'm also working on another Construct Classic project right now that's almost finished, but yea, Classic is fully capable of point and click adventure games games. Proof of concept I guess.

I don't recommend all the methods in this, but like I said, could give you some ideas.

dl.dropbox.com/u/20459682/eclipse.cap

Make sure you have the layer you want selected, then in the Layer Properties, under Display, you should see Scroll X Rate and Scroll Y Rate. Turn these to 0%, and they'll stop scrolling with you.

You have:

{
On collision between castle_guard and Mikey
Trigger once
       {
       Is global variable 'magic_glow' Equal to 0?
               {
               Mikey, blahblahblah...
               }
       }
Else
       {
       castle_guard: Destroy
       }
}[/code:2kaewgg6]

Tutorial reads:
[code:2kaewgg6]{
On collision between castle_guard and Mikey
Trigger once
       {
       Is global variable 'magic_glow' Equal to 0?
               {
               Mikey, blahblahblah...
               }
       Else
               {
               castle_guard: Destroy
               }
       }
}[/code:2kaewgg6]

If you want to, my suggestion is to follow Davio's advice. The tutorials will teach you everything you need to know and offer great introductions to all of Construct's features. A good place to start would actually be Deadeye's Platform School Tutorial:

He gives a great overview on setting up conditional animations. Yea, the tutorials are for 2D sidescrolling platformers, but the principles really are the same as far as animations in Construct go. You'll want to get used to the event sheet system and variables and such, as they are what give you control over what animations are being displayed at any given time on whatever sprites are picked.

I really really recommend listening to Davio if you want to get anywhere with Construct. Go through the tutorials and become intimate with the program. They explain far better and through examples. I can tell you from experience as I myself am working on a top down action RPG and would not have gotten anywhere with it if I hadn't gone through the tutorials.

Games made using behaviors =/= boring and unprofessional, at least to me.

I find behaviors to be a great method for avoiding having to reinvent the wheel. Behaviors are great for taking out chunks of workload and can be used for multiple purposes, like using RTS movement to make a point and click adventure game. Sure, behind the scenes it'll seem simplistic to other devs who get a look at your cap and may not impress them, but what really matters in the end is how well the game plays. The player isn't going to know whether you used preset behaviors or from-scratch scripting. They're just gonna know if the game plays well or not.

Nothing to fear from behaviors and plenty to adore, I say.

Won't lie about being a little conflicted. On the one hand, I came upon Construct looking for a free game maker just to tinker around with and then I got way more than I expected in it. On the other hand, as a musician, I completely understand the mentality of wanting to do something that you're good at, that you love and get paid for it, and the generally common consensus that your hard work should be free just because it falls under the realm of entertainment and not necessity. So all in all, I do want to add that I do support your decision to go commercial.

As far as your proposed licensing model goes, I personally think it looks good but I think you should make more distinction between the fact that people are paying for a license rather than continued use of the editor, so that they don't panic like I saw in the other thread before it got locked with worries about their editor locking up on them.

I saw one person on here propose limited features in the free trial a la many other pieces of software. I think what you might be able to do is lock exporting functionality, so that you need to use Construct to run the games on the trial or expired versions, but leave all the actual game creation ability open. That way it'll be more of an inconvenience than a nag screen but not so much that they can't continue work on their game and continue to test it. They just can't make it convenient for others to play, as other folks will have to download Construct in order to play trial games. I think it'd end up win/win.

As for piracy, I've heard it said pirates will be a problem no matter what you do. Which is true. However, the numbers aren't as bad as most people seem to think (I've done some studying). People are willing to pay depending on not only price points they find fair but also if they believe in and appreciate the faces behind the work.

You seem to already have the fair price point, which you can make even more readily apparent by just adding something along the lines that "this translates to only $x.xx a month" or "help support the development of Construct! buy a license!" or some such thing that would be written far better than my 5 second attempt right there.

The other thing you need to worry about is keeping an active and appreciated position in the community, whether it be frequent news/blog posts, getting people's opinions on proposed additions or changes, things like you're already doing. Only thing I can think to suggest you do in addition is to make sure it's readily apparent to new users/members from the get-go who you are (I had no clue as to how important Ashley was to Construct development until probably the beginning of this year, and I started playing with Construct probably second quarter last year ).

I know folks may disagree with the exporter functionality thing on expired licenses, but from what folks have been mostly complaining about (at least before) was that they wouldn't be able to keep working on their games with expired licenses, but if you can devise a way to test games without exporting I think it could be a simple but somewhat significant way to either A) get folks to pay, or B) get more users downloading Construct = more potential licenses or at least word of mouth.