Candescence's Forum Posts

  • Just asking out of curiosity, to be perfectly honest. *Shrug*

  • ... I think I phrased that question badly, because I am perfectly aware of that. >>

  • Speaking of "Else", any reason why the "While" and "On Loop" conditions aren't implemented either?

  • Edited: Better title, and check my latest post for more thoughts on this. I'm mainly advocating polygon-based dynamic lighting now, due to computational reasons and it's kinda how the old lighting stuff worked in Classic.

    I know you guys have a massive to-do list, but I don't think one more can hurt, really. Lighting can do a lot for mood and atmosphere, and while there are methods to create lights manually, as seen in the lighting example that comes with C2, there could be much more in the way of options, especially with WebGL.

    In Construct Classic, lights were objects of their own, not I think they would work better as a behavior. Not only because sprites themselves can act as light sources, but also to allow particles to emit light, as well. While this could theoretically be done with making additional sprites as lights, like in the lighting example, it results in more objects to take up CPU usage. There also needs to be options that are more friendly to side-scrolling games, where shadows work differently to how it works in a top-down environment.

    For an example, I'm gonna have to pull out Terraria. As a game, it's decent, but it's not that great. For the most part, I'd rather look at its engine rather than its game design, mainly due to how it can have two layers of potentially thousands of individual tiles on-screen at once, and its lighting system. For those who don't play Terraria, I'll throw up a couple of screenshots to demonstrate.

    <img src="http://dl.dropbox.com/u/919275/Screenshots/2011-12-16_00003.jpg" border="0" />

    <img src="http://dl.dropbox.com/u/919275/Screenshots/2011-12-16_00005.jpg" border="0" />

    Terraria's lighting is designed around a side-scrolling environment. When light hits an object, it passes through it, and for every consecutive object it passes through, it gets dimmer until it reaches pure black. Certain lights also have their own colours, which go onto other objects, including not-solids. During the day, the above-ground world is lit by the sun. Many engines call this type of light a 'directional light', as sun's light shines down on the world from a certain direction depending on the time of day.

    Until recently, dynamic lighting in 3D and top-down environments could have a problem of shadows being pure black, if a single light source is produced. This is unrealistic, as light bounces. Even trying to emulate the effect of indirect lighting would go a long way for more natural lighting.

    A list of features for Lighting/Shadow behaviors that I'd like to see, on top of features already in the Construct Classic equivalents:

    • Multiple options for light colours (white, RGB, using the object's own colours, etc)
    • Transitioning between two light colours over time (times of day, etc.)
    • Options for allowing light to pass through multiple objects
    • Directional lighting for emulating the sun/moon's rays
    • Light strength and range
    • Emulating indirect light for top-down lighting

    I'll add more things as I think of them. I hope we get to see something like this in a future build... Eventually. :)

  • Construct Classic also has a "Overlap by Offset" condition that can easily serve this purpose. It's something I've kinda been wanting to see in C2 as well.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • So. I've been thinking about this lately...

    Who wants to start a collaborative project to create a physics-based platforming engine, with rotations, a physics-based environment ala Trine, that sort of thing? That could be an interesting way to gain exposure for Construct 2.

  • I have to agree with the above two posters. Drag and drop just won't cut it for tile maps. Changing animation frames is a temporary solution at best, and it's not nearly as intuitive as a proper tile map editor.

  • I imagine saving entire arrays would be a massive pain in the ass, though, since there doesn't seem to be any method to saving a whole array to webstorage in one action.

  • ou mean a (physics based) platformer, and that's not totally true.

    Families is obviously an extremely useful feature for any game, but it's certainly possible to make things work without it, it's just more labor intensive.

    Families is an upcoming feature anyway (probably within a couple of builds, I think), so...

    n the same way it's possible to make a "loop gate".

    True, but still...

    Anyway, I've implemented an angle detection system (originally designed by Davo) that doesn't rely on the actual object's rotation to work. There's a slight problem with jumping, however - at random, jumping causes the player objects to shoot up at incredible speeds for no apparent reason (and no, my angle code ain't the problem).

  • Well, the current angle detection system is fairly rudimentary, it doesn't work with certain tiles. I know a method, but I can't implement it right now.

    Anyway. It seems clear to me that there are a couple of features missing to make a fully-featured Mario/Sonic style platformer:

    • Families (duh!)
    • Using events to selectively choose what a certain physics object can collide with or pass through, such as platforms, or how Sonic games use a 'gate' method for loops, with one half of the loop being completely solid to the player and the other half being non-solid, and they switch states as the player passes through.

  • Ah, I can see how it works, and it works quite well, that is, if you don't plan on having the box rotate on slopes. Right now, it can't really do that, which prevents it from being able to do stuff like, say, Sonic-style loops.

  • Yeah... What the physics behavior is missing is the fixed angle and angle joints. A Revolute Joint keeps the two objects together and the circle spinning, but the rectangle keeps falling over.

    Just add those two joints, and this would be a piece of cake to implement, I think.

  • Very interesting! Though, really, using it with 8-direction would be a walk in the park compared to using it with, say, the Platform behaviour.

  • What Arima said.

    Also... Arrays are adequate for storing values for stats and whatnot, but for stuff like data entry, it's freaking tedious. Proper data structures (like the 'S' plugin Lucid made for Construct Classic) would alleviate that heavily, and be much easier to organize.

    An XML object would be a godsend too, btw.

  • While I'm happy that the 'push out at angle' bug was fixed, there is a few Custom Movement things that are bugging me that aren't really bugs, so I decided to talk about it here instead. It's more of a comparison of how the behavior works in Construct Classic, where it works better for a few reasons, IMO.

    Construct Classic Example (coded by Davo)

    Construct 2 Example (recreating the above)

    With the 'settings' more or less exactly the same in both caps (where possible), I'll outline the main differences the C2 version of the behavior has:

    1) Acceleration doesn't adhere to angle of motion (very much). A main example being that you can go up a slope, but once you hit a flat part of the wall, you can't go down (or even slow down, for that matter). Trying to results in the PlayerSprite eventually launching itself off the wall. In Construct Classic, "horizontal acceleration" was kinda loose in that way. And yes, I have tried accelerating "forward" and via angle - doesn't work either.

    2) The RotSensors are hilariously oversensitive to a fault, despite having the same 'settings' as the Construct Classic example. They'll go around right angles when they shouldn't, for starters, preventing the PlayerSprite from falling off a ledge, or not allowing the PlayerSprite to launch into the air going up a ramp.

    3) The PlayerSprite can't handle bumping into walls. Just try to touch the wall on the right in the capx, and watch crazy stuff happen. It's probably because of 2), methinks.

    4) Inability to decelerate. Construct Classic's version of the behavior has a 'decelerate' action, while C2's doesn't. A few people have said I'm supposed to be using positive acceleration for accelerating and negative for deceleration, but I'm convinced that's not the case, especially since all my attempts at 'custom' deceleration don't work, period.

    Some other gripes that are a bit more minor:

    * No 'bounce' action'. You'd think this would've been an obvious inclusion! <img src="smileys/smiley36.gif" border="0" align="middle">

    * Inability to pick by 'solid'. The "is overlapping <object>" condition only includes objects, not solids, meaning I have to work around that by using a LOT of "is overlapping <object>" events to include every since Solid object. Kinda one of the downsides of merging attributes to behaviors, really. Sure, it'll become moot with the implementation of families, but still.