PaulStrife's Forum Posts

  • 14 posts

  • I figured out what my biggest problem was with this issue. I did not know that you could default platform default controls off. Now that they are off by default, my simulation controls are now respected.

    It's unfortunate how the obvious things can set you back so many hours. :P

    Thanks again

  • Miyavi: Would you mind sharing a capx for your latest version? You solved some problems I'm currently dealing with.

    Thanks

  • How do I go by creating a custom made movement? I'm new to the engine. I would still want to keep platform jumping behaviour. It is also important not to use physics.

    Variables will have no use for me, until I figure out how to disable movement independently from jumping.

    Thanks

  • Thanks for the direction, it definitely will help.

  • I wanted to have my platform character move a limited amount each time the user presses an arrow key. The idea would be to press the arrow keys multiple times to keep the character moving. Holding an arrow key should not have continuous movement.

    The why I tried to do it was to disable platform movement after a small wait period, each time the arrow key is pressed. This is a horrible solution, since it disables jumping along with it; which I did not want to ever be disabled.

    Is there a way to have this sort of "burst" movement; without impacting the ability to jump?

    Thanks

  • Thanks for the links.

    I intentionally left my post vague, it was not due to lack of knowledge of the basic fundamentals of game design or theory. I did not want to sway my general inquiry by focusing the answers around specific details. I'm strictly prototyping at the moment, I'm not looking for polish. I should have specified that.

    As a bit of background, I've actually worked on about two dozen games over the last 6 years, from a design/production standpoint. I'm well aware of the flow of implementing AI into a conventional game. It might surprise you to know that our AI programmers almost never actually launched the game or level environments. Most of their code work was performed in a simple cube environment with very few static meshes. I've never seen AI done at the end of a games lifecycle; although, I imagine each studio has their own approach. I'm only speaking from the perspective of 4 studios I've been involved with.

    Minor tweaks to fake intelligence happen throughout the project, it's largely trial and error. You don't implement AI at the end of a project, it is the most time consuming aspect of most projects. You want your design and test team working with functional AI behaviour from the earliest point you can establish. In fact, most of the level design workflow was designed around the functionality of the AI; not the other way around.

    I have to emphatically disagree with that Halo example. Making your enemies take more damage will end up making your enemies look dumb, not smarter. It is a horrible attempt to cover up how inadequate your AI is at self-preservation. Smarter AI should be able to survive in scenarios where they could die with a single shot. You should see games like Stalker or Killzone 2 (on hard difficulties), especially their tech demos. Another indicator of covering up bad AI is when you have different enemy types who have limited behaviour; instead of giving AI that can intelligently transfer between multiple behaviours. Quantity doesn't make up for lack of quality.

    Most of the rules of traditional games fly out the window in a simplistic platformer, when you are limited to 100 events (I'm evaluating the engine for a personal project). A key reason why I never once used the word AI in my post, was because I'm not concerned with making them appear intelligent at the moment. I hope this post helps clear things up. I'm well aware of the direction of my intended project and have fleshed out exactly how I want my enemies to react in almost absurd detail; most of which is fairly out of the scope for my prototyping.

    1) I was more concerned with how you would physically handle the act of having your enemies fire upwards or downwards. Would you pin their torso/arm and have them automatically face towards the player? Is a better solution to have animations for each enemy where they face upwards or downwards? My question was more centered around handling the sprite, not so much the reasoning behind why they are facing the user. Although, I'd gladly take advice behind engine tips for that as well.

    2) As for the second question, the "for each" answer was what I was looking to find out about. I didn't know the engine had the ability to specify it that easily.

    Thanks again!

  • I've spent quite a few hours looking through the forums and tutorials tonight, but I haven't been able to wrap my head around these 2 issues:

    1) As a side-scrolling platform game, how would you have the enemy shoot at you when you are above or below them on a different platform (and detect that you are)? I'm looking for something realistic, where they are actually visibly aiming at you in the proper direction as they fire.

    2) How do you spawn multiple enemies of the same type, but have them act out the same enemy type events independently? (attack at different times, die, detect player, etc.).

    The examples I have found had all enemies performing the same actions at once, or they had independent events for each instance of a monster; both solutions will not work for my situation.

    My skills are fairly amateur, if you can help me out with a capx file; that would be amazing. Thanks!

  • I see, that makes sense. Thank you.

  • Hey Ashley,

    What are the steps involved in sharing events between layouts/levels? That might be a bit of a noob question, but I'm not seeing the option.

    Thanks

  • I've decided to not use physics, instead relying on Platform behaviour exclusively.

    It would have been nice to have realistic wheel behaviour, but there was just too much unpredictability with physics (as there should be).

    Ignore this thread. I was likely asking for far too much.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If anyone can help on this, that would be appreciated. I can't progress without nailing down the player dynamics.

    Part of the reason behind needing a solution other than physics, is that "jumping" has horrible results on ramps. Especially at 45 degree angles.

  • There is another solution covered in this post:

    http://www.scirra.com/forum/fall-through-platforms_topic48096_page1.html

    I like how there are many solutions to problems in this engine.

    My solution had more steps than it should, because the jumpthru being disabled doesn't immediately reflect on the platform you are currently on.

  • I'm new to the engine, so I'll try to help you as best as I can with my limited knowledge. Luckily, this is something I'm looking to implement myself in the future.

    This may not be an ideal solution, but it works rather well. I'll let you figure out the exact values you want yourself.

    1) First, set a height you'd like to use for your jump. This will be important later. It can't hurt to have control of this.

    Event:

    System - On start of layout - Player - Set Platform jump strength to 600

    Your player will have to have platform behaviour, I assume they already have it.

    2) The next step is to disable Jumpthru.

    Event:

    Keyboard - On S down (or arrow down, whatever fits your case) - Set jumpthru Disabled

    3) The issue with this is that if you are standing on a Jumpthru when doing so, it doesn't register until you leave it or jump. Which is why you should force a jump.

    Adding a new action, to the event in step 2:

    Player - Simulate Platform pressing Jump

    4) It looks a bit unpolished to jump, when your player wants to fall. It's best to change the jump strength to something low. It will not be visible to the player, but it will allow them to fall through the Jumpthru they are currently on, and the jump is not visible.

    Adding a new action to the event in step 2:

    Player - Set Platform jump strength to 1

    5) This is all well and good, but now all your jumpthru platforms are disabled, and you can't jump more than a single pixel. We need to fix that by making a new event, but we want to set a wait period to allow the player to get through the platform (change it to whatever length you want).

    Event:

    Keyboard - On S released - System - Wait 0.3 seconds

    6) Next we want to re-enable Jumpthru platforms:

    Adding a new action, to the event in step 5:

    Jumpthru - Set Jumpthru Enabled

    7) Now we need to fix the jump, this is where setting a strength in step 1 comes in handy.

    Adding a new action, to the event in step 5:

    Player - Set Platform jump strength to 600

    Here is an example capx:

    https://www.yousendit.com/download/M3BubUpUQ0NOMUNFTmNUQw

  • Where I'm stuck is attempting to give a physics vehicle the ability to jump, with a very clear and predictable path. Since the vehicle relies on physics for the wheels, giving the body platform behaviour really causes everything to go crazy. I attempted to instead use a physics solution (impulse), but the jump was incredibly unpredictable. That makes designing a platform game a nightmare.

    Is there any way to use the vehicle in my capx file, and give it the ability to perform a predictable jump (arrow up key)?

    Another important factor was that I do not want the car to ever flip over. When using physics for jumping, I created angle restrictions for the CarBody to never go outside the 20 or 340 degree angle range. I removed that from the attached capx file, since a better jumping solution may not need this.

    Another important thing is that the vehicle should never be able to jump while already in the air. I might have to solve that with an attached helper to the bottom of the vehicle, with a condition event to only allow jumps when it overlaps the ground(again, dependent on a better solution).

    Here is my capx:

    Vehicle capx

  • 14 posts