I really wish I could... this would be a fantastic theme (remember, minimalism doesn't always mean simple or small). Courier demands my time.

It could be that they are placed between pixels. Go to the view ribbon and set snap to 1x1 grid. Then select all of your objects, move them away a little and back again with the mouse. I've found anything placed between pixels has small visual issues--particularly at edges.

Unless you have something else going wrong!

The "Manual" link at the top of the page, of course!

It's actually quite helpful, isn't too dry, and is practical. It doesn't read like a manual, it reads like tutorials.

There are essentially two types of conditions--they're all variations on those. Every Tick and Trigger Once. Every tick is something that is a process or continues over time (moving an object over time, for instance). Trigger Once happens when a certain condition is met once. You'll use other things like "is X> 40" or whatever to narrow it down. You can add "trigger once" under "system" to a normal event to make it happen once while that condition is true. Those two types of actions can build a game--and eventually you'll get fancier and add loops and arrays, etc.

But read the manual, check some tutorials, look at the example files that come with C2. It's all helpful stuff.

BTW, before you do it any other way, do all of your movement or anything that happens over time *dt (multiple by delta time). This will make your game smoother and framerate independent--which you want.

Every Tick | Set X to (X+20) works, but now how you want. Will run differently on each computer.

Every Tick | Set X to (X+150*dt) works how you want. Will run the same on any computer, is smooth.

This is actually quite simple. You need to add a small, invisible sprite to your game. I call it camera. Give it the "Scroll To" behavior. The game will always scroll instantly to that sprite, so you're really only concerned with how that sprite moves.

+Every Tick | set camera position to

............lerp(camera.X, touch.X, 3*dt)

............lerp(camera.Y, touch.Y, 3*dt)

Lerp does half the distance between the starting point (where the camera currently is) and where it should be (touch). This creates a natural deceleration the closer it gets to its target, and is extremely simple to set up. You can change the "3" to whatever you want. 3*dt means it will arrive in 1/3 of a second. Make it a bigger number to go faster, smaller to go slower (decimals even, if you wanted).

Here's the inside of the Inn (first floor). I'll populate it with some NPC's, but I'm just showing the map for now.

<img src="http://www.adamprack.com/materials/inn1.png" border="0" />

I would have picked modularity, but a debugger seems more essential and more immediately useful. That gets my vote!

The gist:

Every tick

If object.opacity>0 | set opacity to object.opacity-100*dt

It will fade out in one second. Switch to > and + to fade in. Change the values to chande the speed, but multiply by dt to make it framerate independent and smooth.

I've heard countless people claim doing a for each ordered loop for sorting is the best way. Most of these people don't use it in any complex or detailed settings. It is a nightmare if you ever use any objects other than just one type (ie, if you mixed tiled backgrounds with sprites--you can't mix object types in families). Like anywhere else, I'll recommend you stick with the z-sorter plugin (and use rex's updated one, too). You can choose how often you sort in a single event. Instead of every tick, use every few milliseconds or whatever and then call the "sort objects on layer" action. It really is the best way to go currently, and you can modify things easily now, too! If you need to manually move an object in front of another, you can with C2's relatively new z-ordering events. Just call that after the z-sorter plugin call and voila!

As far as shadowing goes, perhaps a second layer could be your solution? That's my solution to the same problem in Courier. It isn't perfect, requires a little more manual placement and fixes, and can cause the player to occasionally have a shadow over (or not over) them at the wrong moment, but it sure beats doubling your objects and running anything CPU-intensive.

In actuality, I have several layers that I use for my game, really, as a solution to most of your problems.

Overshadow -- shadows on objects over the player permanently

Over -- things like rooftops always over the player

Player/objects--my z-sorted layer. Really not a ton of stuff on it in many cases

Structure shadows--shadows on structures like buildings or cliffs

Structures--buildings and such

Regular shadows--shadows like you're doing now

Ground--duh

I make the objects never overlap between the shadow layers, and it covers the majority of instances that I would require. The only downside is not getting shadows on the player, but that's a small trade-off for the tons of fixes and flexibility I get. You could run a darken/tint shader on the player if they overlap a shadow and semi-fix that issue, but otherwise this fixes about everything in a simple, easy-on-the-CPU kind of way.

I get a little more mileage since my game's perspective is more of a 3/4 view straight-on instead of isometric, so I can get away with simpler shadows at times. Also, making the shadows blurrier makes them not stand out too much AND you can blend/fake things. I have a non-uniform blobby shadow that I've gotten a ton of use out of with just stretching and rotating it to be "close" to the shadow that object would cast.

Our games are set up differently, but this all should be worth looking into to see if it helps. Scroll through the few pages of my Courier thread to see a few more of my shadowing examples because my shadows don't overlap, and buildings cast shadows on themselves, too--which is more useful to me since I don't pre-draw any of them in an image editor, but rather build them out of parts and textures in C2.

Good luck!

Bonus pro-tip: You can import some shadows objects as a tiled background, but import it upside-down. Rotate it right-side up in the editor. Now, when you resize it, you crop instead of distorting. Now you can have multiple different partial shadows using the same object. Very useful in a some rather specific instances. Also, if you need the bottom of the shadow to be round or something instead of flat, use one of your multi-purpose shape or blob shadows to fix the bottom edge. Using a uniform opacity for the layer, no-one will ever know you combined two objects to make the shadow.

I think the moving left/right controls should be "key is down" conditions and NOT "on key pressed." Otherwise, it only triggers for a single tick.

This is a job for sub-events! Create your key press condition

On C Pressed.       Now right-click on it and add a sub event (I think S is the shortcut). Now add your other conditions

-------Box.Whatever = "closed" | open the box, set box.whatever to "open"

-------Else | close the box, set box.whatever to "closed"

The indentations help your know you're in a sub event. Basically, when you press C, it then triggers evaluating the other conditions. How you were trying before wouldn't work because the "else" of on C pressed is infinite. Sub events fix this by letting you run multiple layers/tiers of conditions off of one action.

I hope that solves it for you!

Thanks everyone! Here's a screenshot inside the big mansion in the forest area. I can do a little more with fancy effects in these enclosed spaces and still achieve similar performance to the larger, more npc-heavy, outdoor areas, so I do!

<img src="http://www.adamprack.com/materials/mansion2.png" border="0" />

I hope you enjoy it! More to come, as always!

From a performance standpoint, I would take the time to cut out (or make!) your resources in manageable objects that you could use to assemble your levels in C2's editor. You would drastically improve memory load and file sizes. That, and it'll be easier to make changes later. The temptation to fully make your levels in Photoshop is there, but I would suggest avoiding that route. I don't necessarily mean tiles, though that is a wonderful option for many, but making smaller and more flexible objects is something you would thank yourself for later.

Also, I feel it increases the likelihood of completing the game--a very real concern for indie developers.