Basically, if you resize the tiled background to be larger than the original image, it will begin tiling it. If you don't want it tiled like that, then you have to use a regular sprite. It can be resized however you want.

+100 to this.

I know it is hard to justify adding features to c2 tilemap when there are 3rd party plugins that do the same thing... but here is the bottom line: Workflow takes a major hit when you have to screw around with importing and exporting from one tool to another. Also, while making tight levels for difficult games, it can be very difficult to be able to rapidly tweak and test levels. Many people in the community make their own level editors... and I can't help but think that the built in tile map sort of encourages that. Anything that people have to repeatedly create should probably be included in vanilla c2.

The feature requested by the OP is very reasonable.

Prominent Tokinsom - Somebody suggested that it would be good to share layout size? I agree. I have a hunch what these sizes are though... I have noticed that c2 has a very good feature set ~if~ you are making "small" games. Phone games and the like are nice but when you sit down to make something like iconoclasts in c2, you realize the default tools don't cut it... and then you go make a level editor (a long process indeed). C2 is a game engine, and as such it should provide users with the tools needed to make games. It does this fantastically. But I do feel that anything that saves users' time should be a priority. I don't use a game engine to have to still remake part of the wheel, and lets face it, that wheel is being remade everytime someone doesn't want to use tiled (workflow or other reasons) and makes their own level editor.

Tokinsom - I feel your pain, and feel prominent clearly has not the perspective that you have on this issue. I'm not trying to antagonize anyone here, but I do feel tokinsom has been reasonable with what he has said. And it does make a difference what you are making a small game with 8x8 tiles is easy... a larger game with 8x8 tiles becomes exponentially more difficult to use the built in tilemap.

If Tiled is the solution that why bother having tilemap tools in c2 at all? If it is worth it to have those tools in c2 then it is worth it add the necessary features to make it worth the time to use.

Did you use tiled background object?

(be sure to use Ruskul if you respond or I won't see the post!)

When you say tile, are you referring to the tilemap? In which case you don't spawn it but rather set the tile at x,y to be what you want (0-n)

also... you destroy the object before you have it spawn a new one. Is it still spawning the new one?

Also, instead of destroying the object and creating a different one, you can simply change animations, and set a flag for whether it is yellow or white. If it just comes down to changing the color of the sprite (or tile in a tilemap) I wouldn't destroy and create objects.

(be sure to use Ruskul if you respond or I won't see the post!)

Hey everyone,

You should be able to specify a layer offset, changeable at run-time! I should think adding this would be pretty easy, but it would give total control over how each layer is rendered. if you wanted to move a layer, not in conjunction with the camera, you would just change offset values (x,y). When construct 2 renders the layer, it simply adds these offset values to the draw call.

Some kids in a class I run thought this should be a feature, and I think that it is a good idea!

What do people think? I can think of uses for independent layer movement that is not tied to the camera. Sure you, can do it already bu moving each object in the layer, but that can get tedious (even when using families).

I don't know if anyone else would be interested in this but I would love to be able to get a little more back from the system on overlapping objects. Right know, we can only know if something is overlapping and that is it. Given that construct 2 uses polygons for collision, there should be some good information left over from calculating those overlaps.

My thought is that surface normals and points of contact could be really useful in making alternate styles of collision resolution.

As it stands, there is the platformer (and the custom movement) behavior that can be used to resolve collisions, but the algorithms have somewhat of a classic feel, but they don't offer much capabilities beyond that. You can certainly emulate the collisions and calculate surface normals, but it seems strange to calculate info already calculated.

If you play a bunch of platformers, you will realize there is an enormous wealth of approaches to collision detection and resolution. These different ways of doing the same thing can help give a game a unique feel. How you resolve collisions plays a large part in this feel. Take superMario3 for example, You'll notice that depending on the direction mario is moving, and the location of a block, it may resolve the collision in a way that makes no sense physically but makes plenty of sense based on the players perspective and intent.

What do people think? How many of the developers out here end up implementing their own collision systems / platform behaviors? and if so, to what extent (ie... do you build off of the base behavior or have you tried making something from scratch?)

Hey everyone,

I was wondering about the ways in which behaviors update each tick.

I know the the pre and post ticks and just tick in general, but is their a fixed update call? Like something that calls the behaviors "OnFixedUpdate()" It could be usefull for some things that need frame independence but also need a fixed timestep... I have seen such things in other game engines so thought something of the sort may exist here too.

Aphrodite - I knew about the stepping mode... I always make very project framerate independent and it seems to work just fine an many circumstances... I just don't understand why there is so much about physics needing a fixed time step.

I did just realize though that you can't use every x seconds to make a true fixed timestep. this is because physics box2d world is going to be updated in tick(). Everything box2d does, is done once every game frame regardless of dt... I wonder if there is a fixed update call for plugins and behaviors. I know there is pretick and post tick stuff but I have now clue about fixed update.

Hey everyone,

I keep seeing that you really shouldn't use dt with physics due to small changes causing potentially large changes in how physics operate each time you play a game. It is my understanding that we are talking about very, very small changes (that certainly can cascade) but that shouldn't have an effect on, say, a racing game? or anything that's not angry birds or similar. Sure dt will change and in a puzzle game or anything where physics needs to behave very consistently this could be bad, but anything else seems like it doesn't matter.

but what does matter in most games is framerate independence... So, shouldn't the default be to use dt with physics unless your project fits certain criteria?

On another topic, I have noticed that some other game engines actually incorporate multiple time steps. Unity, for example typically is scripted to have physics run in a fixed update loop (like 40 times a second) while the main game loops is running 60 times a second. I have been using physics for a while and it doesn't seem like dt does anything bad to it in an action game where nothing relies on a tower of blocks falling the same way each time.

Can anyone elaborate on any of this?

And... also, could one use every (1/40) seconds to create a fixed timestep in construct? Are those timesteps called independently of when the main game event loop is running (in other words is a fixed timestep called on time, evertime, regardless of what is going on) ***EDIT*** This won't work because physics is updated once a tick in the behavior- does anyone know if there is an update method for behaviors that uses a fixed timestep?

It is weird, because not using dt with physics cause the game to speed up and slow down... would a fixed timestep solve this and the issue of not using dt?

Ashley - What version of ams.js is being used by construct? I found a recent build featuring the most recent version of box2d. It seems like a completely automatic build using emscripten. The bindings are also auto generated.

Ashley - that's cool, real cool. So there really is no reason to go through a project and disable collisions on objects you don't need to collisions...? Nice... in that case... *editing OP*

My biggest fear would be to do work that could be outdated by an update in construct... So... if you could, if you do hear anything or priorities change, could you please let me know, if you think of it...