PaulStrife's Recent Forum Activity

  • 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!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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.

  • 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.

PaulStrife's avatar

PaulStrife

Member since 7 Apr, 2012

None one is following PaulStrife yet!

Trophy Case

  • 12-Year Club
  • Email Verified

Progress

13/44
How to earn trophies