Ruskul's Recent Forum Activity

  • Thanks for your post, I have also been frustrated by the limitations of the platform and physics behaviours - and I never understood why your simple modifications to the box2d plugin were not implemented. Thanks to your post here I have decided to try to create my own platform behaviour - to compare performance / to enable collision filtering etc (using the raycasting plugin). I've also started (slowly) learning C#.... just in case lol....

    Well, who knows if those modifications wouldn't break some projects, or needed a better ui (like with edge shapes). I know Ashley strives very hard to keep things clean and user friendly. The strong emphasis on beginner and beginner ease can often mean compromises when it comes to more advanced features. I thought physics was going to get an update, but I think not enough people want it to justify it.

    I know getting going with c2 is amazingly simple and intuitive most of the time. Unity as a comparison can be quite frustrating. The frustration comes due to lack of concise documentation and a large and at times overwhelming library of built in calls, and things you need to know. C2's frustration sets in after you start doing larger scale projects or need to implement functionality that isn't there out of the box.

  • While the Platform behaviour offers decent functionality, it lacks a lot of more complex stuff (like selective solid collision) and is hard to walk around it.

    For some time I wanted to build my own platform functionality using events, but didn't know where to start. I am interested in a mario/megaman/kirby type, simple platform with slopes. I would like to avoid Physics since are using more CPU. Which method should i choose ?

    Also, I've found the following tutorials to inspire from:

    http://www.gamasutra.com/blogs/YoannPig ... hp?print=1

    http://www.gamedev.net/page/resources/_ ... mers-r2936

    http://www.hobbygamedev.com/adv/2d-plat ... -detection

    -

    I should also point out that there are some hacks to get around solid collision enabling/ disabling, which could allow for the use of the behavior that comes with c2. I didn't like that behavior for the reason you do, but I also didn't like how it handled slopes and corners.

  • Ruskul Can you give me some pointers regardless my previous post ?

    Sorry to get back to you so slowly. I haven't been online much as of late.

    If you want to make your own platform behavior in c2, I would recommend the point based system. Adding slopes can make things a bit harder, but totally still doable. I have a system moldering on my hardrive, but I used custom behaviors to make it rather than doing it all in events. This makes it faster if that is a problem but I also needed the flexibility of code due to a few "key" features.

    If you would like, I would be happy sit down at some point and go over how to implement such a system, specifically in construct 2 through events, unless you like coding behaviors instead... either way. If you like the way mario 3 felt, or kirby, then Its a great system, but there are some funny bugs that can be exploited (lots of mario 3 tricks, for example)

    I keep meaning to edit the original post to give more info on how to actually achieve it.- though I should probably do this in a tutorial series.

  • Wow, nice post. Yeah, I've been wondering what kind of 2D platformer engine the Sonic game used that he can run & rotate like a roller coaster in 360 degrees.

    But I understand Scirra Team wants to do it slowly, 1 at a time to make the program as stable as possible.

    Somebody, if I recall, created a sonic clone on game maker that was a gigantic project. You could dl the project at the time, but it was expert level game maker stuff. The loops are mostly achieved through trickery. Its not like it actually has a robust physics simulation controlling. I never played sonic much nor analyzed it but if I recall there is this magic threshhold where you either do the loop or bail. You couldn't stop half way through at upside down.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Thank you for sharing this information, it does provide a useful insight into how platformers work at their core. The only think I'd argue about is this: Making a simple engine may not be that hard everyone says it it, but making a general purpose, well optimized engine is not something that could be done easily.

    Making a general purpose anything when it comes to programming is difficult and typically should be avoided, unless that is the intent of the project (like making construct, yay). Most of the time, if you make your own, you will remake it next time, because even if you tried to make it general and flexible you didn't think of your next use case.

    The very fact that I make my own when construct 2 comes with a pretty good basic platformer is a testament to this. It just couldn't do what I needed it to do, so I had to make my own.

  • Hey all,

    I just wanted to share a quick blurb on 2d platformers and their implementations. I think it is quite common to hear that the engines are hard to make. They really are not. At this point (as a programmer that is self taught) I have successfully created 4 different types. I started with XNA and C# and wrote my own collision algorithm for my first. I am going to outline the general ideas involved with each type and what I learned from the experience. Briefly, here they are... of course, the distinction between the types can be blury at times...

    Raycast 2d platformer,

    Physics based platformer,

    Geometry based overlaps platformer,

    Point based platformer.

    RayCast Platformers

    Platformers using raycasts are common these days. They are fairly straight forward to implement. They are nice because you don't neewd to worry about resolving collisions. Instead you make sure that objects that shouldn't overlap never overlap. You do this by shooting raycasts from the characters leading edge and look for upcoming collisions. You use the distance between the character and the upcoming collisions to determine how far you can move the character. You can use engines like box2d to provide raycast functionality or you can role your own engine. But why invent the wheel when you already have rockets. Dustforce is a notable game that uses this idea. Most game engines have raycasts built in (c2 is an exception, but it shouldn't be).

    Physics based platformer

    Most people think of games that actually involve physics and have a certain feeling such as limbo. But in reality, you can make a retro style game like megaman using physics without too many problems. You have to create a number of systems to detect where the character is (on ground, in air, etc). This is most easily achieved using raycasts, but overlapping geometry can also be used. Using constraints and applying forces such as friction yourself, and directly controlling velocity, you can pretty much make any retro style platformer. It doesn't take more work than rolling your own engine, it just requires an excellent working knowledge of how the physics engine actually works. Box2d is a fine choice. One of the top hits in google when searching for "platformer physics" is a popular blog that says you can't/shouldn't use physics to make a platformer. I can only conclude the author is either not accomplished at programming or lacks creative problem solving. An important note is that in construct 2 , there are many features missing from physics that makes it much harder to use to make a platformer without compromises (such as tripping on internal seams).

    Geometry based overlaps platformer

    Rather than preventing collisions, this style of platformer moves the character regardless of collisions, then attempts to resolve the collisions after the fact. The overlapping algorithms are fairly straightforward to implement if you have to roll your own, but figuring which direction to resolve the collisions is the tricky part. C2 has a great collision system that makes using this method feasible in c2.

    Point based platformer.

    Welcome to retro land! This is one of the simplest and easiest methods to implement and was the choice method for a decade. Mario and sonic used this method at one time. Essentially you make a character have points that represent its head, sides, and foot. If the points overlap solids then the point react in a specific way based on where it is. In mario 3, if his head overlaps a tile the game simply changes his upward velocity to 0. If a foot overlaps it pushes him up. You get the idea. The trick is all about where you put the points and this takes some time to figure out. You don't want the foot to be overlapping at the same time as a side on the same surface. In the case of mario 3, to handle slopes mario actually changes the position of his foot points to be more narrow. If you play a level that has slopes, mario's collision boundary is actually different than in levels without slopes.

    All in all, regardless of the method used to make a platformer engine, adding slopes, ladders, oneways, moving platforms start to make it harder to make. Slopes in a raycast system or physics system are easier to add than in a point or overlap system.

    The best place to start when trying to make a platformer is to actually google it and start learning. Simply adding the platformer behavior without understanding why it works makes it really hard to customize.

    Cheers

  • This would for sure be a great official feature!

  • Yes, this bumping is very annoying to my team, we ended up transferring collision to additional single object collision boxes to work around it. It would be nice, trusting what you say, to implement a solution in the engine.

    Well... its still not a good solution, it changes the way the rest of physics works and will still sometimes trip on those seams. It could work for some things, but I wouldn't change a whole project for it. Tell Ashley you want proper collision edges. I did, he didn't care. But I think if enough people yammer about it he will eventually officially include more box2d features. I was under the impression he was waiting for a new build before adding them. He got his new build and then still didn't add them. I even gave him some code for fixing some bugs and suggested adding of a few features that I also had code for... but alas... Ashley is a very busy man and has way too much on his plate. c3 eh? I'm hoping!

    Cheers

  • Construct 2 raycasting plugin

    Welcome back I guess?

    ~Sol

    haha yeah, that is a sweet plugin. Unfortunately, I've spent the last month doing the hard work of getting my game switched to unity. Now that it is there, there are a number of benefits I won't through away after all that work.

    But this plugin is great. I had a discussion with Ashley a year ago about lack of useful collision information (surface normals, distance, etc...) but I guess he didn't think it was useful.

  • Frankly, Ashley should have included this 5 years ago. The lack of this feature is the #1 reason I am currently developing in unity instead of c2. Great addition!

  • I know this has been discussed at some point here, the obvious solution is to use an edge collider... but we all know that doesn't exist in construct2 box2d implementations... but there is another way around it. You can change min penetration without penalty to 0.

    This should be an option. It has its price and so shouldn't be default but it would fix all those game that roll objects across what wshould be a smooth surface and get little bumps.

    If you like to edit code you can change the setting in the behavior for physics.

    I learned about this while using unity today and then confirmed. and I came running back here as fast as I could to share the news for any who care. If only c2 had raycasting I would have never left in the first place (I need to get the angle of surface normals... Which is not in my mind a luxury but a necessity in games - especially when trying to role your own platformer engines on a routine basis).

  • http://gamedev.stackexchange.com/questions/18787/how-does-one-avoid-the-staircase-effect-in-pixel-art-motion

    This has a fix, found it while working with unity. Th op also does a better job explaining the problem too.

Ruskul's avatar

Ruskul

Member since 23 Nov, 2013

Twitter
Ruskul has 2 followers

Trophy Case

  • 10-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • x6
    Coach One of your tutorials has over 1,000 readers
  • Educator One of your tutorials has over 10,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

17/44
How to earn trophies