Candescence's Forum Posts

  • Alright, I've gone back to this topic, it seems...

    Well, right now, I've got two sets of events - one for control-based events in the big 'for each' loop, and another group for events that can't go in there. While I've managed to fix up many events to enable multiple players to work better, I've also hit a snag when it comes to 'duplicates' - when two players are using the same 'character', there are, well, issues. Player 1 works fine, but Player 2 is unable to properly end some animations, as "on any animation end"/"on animation <animation name> end" doesn't properly trigger for some reason, which causes the second player to be stuck on the specific action.

    This is obviously a problem. Any ideas on how to work around it?

  • In one of the few updates for the open source branch of Construct Classic before development on it pretty much died, the platform behavior got an interesting feature - being able to selectively toggle collisions with specific objects. For instance, holding up to walk up a set of stairs while moving towards them (while moving past if not holding up), or onto a lift (if the lift is moving up while the player is holding up, the lift will carry the player upwards, and will simply pass by if not).

    Another interesting example includes changing to another 'layer' of the map - for example, going upstairs or downstairs in a top-down view without changing layouts, or entering a building that's in the 'background' with a sidescroller view. Such things can have some interesting possibilities for map design.

    Stuff like this, though, isn't really feasible right now as things are - you could switch solids/jump-thrus on and off, but that will cause a myriad of problems for other things using those behaviors, especially if you want things to be still be active on multiple 'layers', for example.

    So, yeah, for certain behaviors like Custom Movement, 8-Direction and Platform, I'd really like to be able to selectively toggle collisions with specific objects.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Revisting this thread...

    While it is technically possible to achieve such results, I really think that such useful functions shouldn't need so much work to set up - when programming languages include proper dynamic arrays/linked lists as standard functions, surely it would be worthwhile to implement them. Sometimes it's just better to get better tools for a specific purpose rather than try use existing tools that'll make solving the problem more difficult.

  • Just a note, lucid, there's some strange object replication stuff, especially with importing the platformer template with the gun - when imported, the object comes with four gun sprites even though they're exactly the same, which is kinda bizarre.

    Edit: Also, the muzzle flash animations are basically worthless unless removed from the rest of the animations into their own file.

  • To be perfectly frank, it's not really 'my baby', it's a port of StreakThunderstorm's Classic engine.

    But I'm really not convinced that this engine can actually even be salvaged. I've figured out that the slope detection events are the ones that cause the crash when you remove the reposition functions from them, and removing all the other function calls of Collision and Reposition do little to optimize it and start causing issues anyway.

    At this point, you might as well just scrap the whole thing and start over, because trying to optimize it will inevitably just break the whole thing in half. The engine is too complicated for its own good, collapsing under its own weight and unable to make it lighter without removing any vital parts.

    Back in the day, I was convinced that a direct port from MMF2 was a terrible idea due to the differences in the ways the event systems worked, among other things, and now I'm once again convinced that this route was a futile, pointless effort.

  • Honestly, at this point, I'd say it would be easier to just find someone who could make a custom behavior. It would certainly be more efficient, I think, and probably easier to work with when it comes to stuff like multiplayer, due to the lack of need for picking with all those freaking sensors.

  • Alright, here's what I've got when trying to tweak the engine:

    �

    1. The timescale has been set to 1, because the old way it worked, for some bizarre reason, doesn't stay�constant.�The movement works slightly better as a result.

    2. The pre-movement function calls are�entirely�unnecessary.�Now, removing both the pre- and post- movement function calls pretty much sorta breaks the movement, but removing just one set seems to have no negative effects, making the whole thing slightly more efficient.

    3. Now, you'd think just having one set of calls for Player.Reposition and Player.Collision once every frame would be fine, right? So just removing those calls from the main movement group would be fine, right? Nope! The whole thing�crashes upon startup�if those calls are removed. I'm serious. By all rights, it shouldn't be capable of�doing that.�You'd think it would simply cause the movement engine to spazz out or something, but instead, it crashed! It would be impressive it were not so frustrating.

    �

    I'm pretty much calling this engine a lost cause at this point, point no. 3 just makes it seem fundamentally broken. I'm likely going to have to explore new avenues at this point.

  • Whoops! Turns out I accidentally missed them when composing my post. Fixed, sorry about that!

  • So, last time I tried to get help when it came to a optimizing my Sonic-based platform engine, the focus was collision checking. Turns out I was looking at the wrong area, because, apparently, that wasn't the actual problem.

    For refernence:

    So, it seems the major CPU bottleneck is fairly obvious, now that I've rechecked the CPU profile in the debug:

    <img src="https://dl.dropboxusercontent.com/u/919275/Screenshots/CPUStuff.png" border="0">

    Yikes.

    Yeah, that's more than a bit much. For reference, the Pre- and Post- movement sections only call a couple of functions each tick, and the former modifies a couple of variables. Those two functions are "Player.Reposition" and "Player.Collision", the former of which properly aligns the position of the player sensors, and the second runs though every sensor and checks if they're colliding with something, by ALSO using a function for each sensor. And there's eight different sensor functions. "Movement" itself does plenty of function calls to both above functions depending on the circumstances and to other functions as well. Sensor Routines and Movement Routines in general does a LOT of function calls.

    Unfortunately, this seems to be incredibly inefficient in C2, whereas it's perfectly fine in Classic, probably because of the way the two work differently.

    So, yeah. I'm somewhat at a loss as to what to do. The whole thing is rather complicated, and I wouldn't know where to start in order to optimize the whole thing.

  • Huh, that did work. Well, that's egg on my face, then. Disregard the email, then.

  • Just a heads up, Lucid, I'm getting a Javascript error just from starting up a file:

    "Javascript Error!

    Uncaught Syntax Error: Unexpected token <

    localhost/, line 1 (col undefined)"

    I'm sending you the cap now via email. It's just the original platformer essentials animations except with the head shrunken down to something far less ridiculous.

  • Still, integrating techniques like that could potentially be a hassle.

    Terrain mapping might also pave the way for stuff such as, say, automatic tile blending, with each terrain having a set of 'edges' that, when bordered with another tile, the terrain automatically 'blends' in a certain fashion (for example, 'man-made' tiles will simple sit side-by-side, most natural terrain will blend with each other, water washes over most stuff, etc). Not sure how feasible that would be, but it would be interesting.

  • I know Ashley has mentioned that he doesn't quite see the point in reinventing the wheel when it comes to certain tools from Tiled, but there is one rather big reason why having terrain mapping might be a good idea, and I realized it when the newest update included the ability to modify tilemaps at runtime.

    I mean, with tile maps, inevitably, you're gonna be seeing people using it in level editors and games where you can modify the terrain in some fashion. Aside from making life a lot easier for those people if they want tiles to 'blend', it would also open up interesting possibilities for naturalistic tile-based terrain that can also be modified in-game, and I imagine there could be settings to identify which 'terrain' a tile properly belongs to, for the sake of games like Terraria, where you break blocks to gather resources, and stuff like that. And you can probably have terrain tiles that exist in cases where they don't 'blend' with the surrounding tiles.

    tl;dr: Terrain mapping has plenty of in-game potential as well as being useful for editing. Food for thought.

  • The moment the long-awaited tile-map plugin was introduced, I couldn't help but notice the questions about how to go about handling collision. Well, I do have an idea that could make life easier for everyone...

    Have a separate 'tile palette' that contains a set of generic shapes scaled to the size of the tiles, such as full squares, rectangles that partially cover the tile, triangles for slopes, etc. These are 'painted' over the graphical tiles, and don't appear in runtime (unless you want them to for debugging purposes), and represent collision polygons. That way, you can enable static tile collision that can be individually shaped for each tile. Hell, you might even be able to make your own collision tiles for your own needs, depending on what's possible.

    Sure, it's not perfect, but at least you won't have to create collision sprites for individual tiles. I'm not sure if it's doable in terms of the technical details, but it's worth suggesting, at least.

  • That's really only workable if you're only working with a single layout, anything more and things start becoming a hassle. This is especially true if you want any kind of 'storage' system for party members you're not using at any time, and you don't want to have those party members active all the time.

    The main advantages of a "List object" are convenience, being able to keep track of multiple "Lists" (even multiple lists associated with the same family) at a time, organize and add to them, and keep them active across layouts without having to muck about too much with events.

    Say you want to add a new item to an inventory list object - just tell the list to check if the item isn't already there, and if it is and you've got a 'quantity' value, just increase the value by one, and if there isn't any in the list, just add the the object to the list. Simple.