Games made using behaviors = boring and unrpoffesional?

This forum is currently in read-only mode.
From the Asset Store
Make your own platformer for both the web and mobile easy with this Santas Platformer Template, FULLY DOCUMENTED
  • Well knowing how to program a game only counts when you want a job with a big games company.Or if you plan to make wii,xbox360 or ps3 games with thier dev kits.With Indie gaming it does not matter what behaviors you use or what app is used , As long as the game is good then most people won't care how the game was made.

    Ask any gamer if they care about what dev kits were used in a game and they will just say um i don't care.The same goes for behaviors.Well i certainly don't care what the devs used to make gears of war for instance.I didn't even know UDK existed until i got it from one of my friends.

    And as for the guys at game maker downgrading game devs, They are just a bunch of green jealous goblins.Yeah thats what they should be called green goblins right next to the trolls.

  • There is only issue with behaviors. Low FPS makes platform jumping higher and high FPS makes jump lower

  • Hm, it should be timedelta'd...

  • There is only issue with behaviors. Low FPS makes platform jumping higher and high FPS makes jump lower

    As Mipey says, it should be time delta'd so that there's no difference whatever the frame rate.

    But it does bring me back to my original comment.

    If a behaviour does what you want, how you want, then there's no reason not to use it.

    If it doesn't, down to the behaviour not working as it should or it's poorly written, then it should be avoided.

    Bad code is bad code, whether it's written by you or someone else.

    Krush.

  • The more the merrier, even if it is bad code. The beauty of open source is someone can always learn from those mistakes and fix it.

  • I've always thought if people regularly code their own movements instead of using behaviours (e.g. a custom platform movement instead of platform behaviour) then the behaviours should be improved so that everyone uses them. They're not meant to be a toy for newbies, they're actually meant to provide functionality in a useful and accessible way. They should also be customisable enough that you can implement custom functionality to make your game unique and interesting, be that springs or reversing gravity or whatever.

    If you have any ideas on how behaviours can be improved towards this - especially in C2 - do tell us your ideas! I was under the impression most people use the behaviours, even for full games - if that's not the case, I'd be interested to learn why.

    Hey Ashley, would you say the idea behind a C2 Behavior is to make it easier to modify than a C1? The biggest problem I've always found with C1's behaviors is how excluding they were to other code. Leading up to a point where you like most of a behavior but its coding rendered an idea in operable*; requiring the designer to either try to replicate the behavior from scratch or sloppily code around it.

    Also just my suggestion, but the ability to synchronize values from multiple behaviors might be an interesting suggestion toward making them "play nice" especially if you could modify said behavior so one wouldn't have control over an object. So if two values are synchronized then they both share one value making any change to one a change to the other.

    For example. You could synchronize the X and Y velocities of a platform and physics behavior, and then modify the platform movement to not be able to directly affect player movement, but do it through the physics object. But that's just me talking.

    *Example: someone wanted a game using a time-slowing mechanic. The player himself would not be affected by the slow. How do you code around the platform behavior to accommodate this? (Issue with behaviors and timescale)

    *Example 2: someone wanted a platform game where some platform characters would ghost through certain platforms and others wouldn't. I actually did manage to code this, but I had to completely abuse how the behavior worked to accomplish this and it looked kinda sloppy. (Issues with behaviors and collision)

  • For example. You could synchronize the X and Y velocities of a platform and physics behavior, and then modify the platform movement to not be able to directly affect player movement, but do it through the physics object. But that's just me talking....

    *Example 2: someone wanted a platform game where some platform characters would ghost through certain platforms and others wouldn't.

    I've submitted code to the svn that makes these two things possible

    if it gets into the next version, physics will take nonphysics movement into account in a stable, predictable way,

    and platform movement will have an option to ignore certain object types temporarily or permanently, on a per platform movement object basis.

  • Well coming from a guy who seen game maker games source codes and so on, most pro game developers (whether game maker, Construct and presumably clickteam game developmet tools(tgf2/mmf2))

    "Pro game developers" would never use any of those programs... just sayin'!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Actually, not only do casual game developers use them at times for their games, AAA studios have been known to use them at times for prototypes as well!

    Edit: Edited in the bold parts for clarity. I don't know how often they're used.

  • I think you're misunderstanding what I meant. I said prototypes. Like for quickly checking if a gameplay idea for a new game is fun, because often it's hard to tell until you're actually playing the thing. I didn't mean they'd use them for development of the actual game.

    I'm not kidding, pro devs at AAA studios have said that they have used tools like MMF for prototypes. They understand how its often quicker to get something up and running with these tools then it is to program it for scratch.

  • And even then, it would be quickly on to a 3D engine if the game isn't 2D.

    Uh, yeah... that's basically what I said. I still think you're misunderstanding me. :/

    What I think this boils down to is when I said "AAA studios use them for prototypes as well" I think you think I was saying that this practice was used commonly for a large percentage of AAA games. That was not what I meant, and I apologize for that. What I meant was "AAA studios have been known to use them at times for prototypes as well." I don't know how often, but I have heard about it happening. I've edited my post for clarity.

    I actually thought that post was a bit misworded and was trying to edit it but my internet was cutting out and wouldn't let me. By the time I got back online, you had already posted. :/

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)