Tokinsom's Forum Posts

  • lucid Well when you put it that way then yeah, it does look a bit simpler :) Still, the thought of having 20, 30,even 40 different objects that are all enemies or bullets worries me. Knowing that all of that can be compressed into a single object is comforting. Plus it keeps the object list very small. After working with MMF and CC for so long, seeing that object list pile up and having to sift through it drives me insane. Fortunately C2 has a search box there.

    I think it's safe to say OUTSIDE of the event sheets using a single object is simpler. With families, if I want to change the values of each bullet or something I'd have to go to the layout editor, find that object, open it's properties, open its instance variables, then change what I want. With a single object I have every single property of every bullet type right there in the event sheet / list.

    I guess I just got used to this when working on Bumper's Quest before there were families, and am having a hard time figuring out why I should go back to them.

    lucid again Yeah that too :P Using a level editor and any "custom" tools I guess can change how you look at and do certain things.

  • I agree with telles0808. even though it's possible to do as you said with single objects, but what about objects with animations? that would definitely be very annoying without families. or if you wanted totally different logic for each enemy, or ui element.

    Sub-Events!

    +Enemy.value=Goomba

    (subevent) Do anything a goomba would

    +Enemy.value=Koopa

    (subevent) Do anything a koopa would

    This single enemy object could contain every behavior that could be activated/deactivated depending on what the enemy variable is. Animations could be set like

    -GOOMBA_Walk

    -GOOMBA_Squished

    -KOOPA_Walk

    -KOOPA_Squished

    Then when the enemy dies? More sub-events

    +Enemy dies

    (subevent) If it's a koopa do this

    (subevent) If it's a goomba do that

    I guess it's just personal preference :\ I like that each time one of my enemy spawners creates an enemy, ALL of its properties are set right there in events. Then I could have yet another sub-event for enemy variations instead of creating a brand new enemy object and putting it in the family just for some minor differences. The same applies to bullets and everything; If the bullet variable is Plasma - give it this strength and that behavior. If the bullet variable is fire - give it this effect with this other behavior.

    I find that easier and more convenient than making totally different objects and putting them in the same family, but to each his own I guess o.o

    Edit: TiledBackground Objects seem to be an exception, as each one can only use a single image. So if you want them to share a common behavior you'll want to use families.

    But then again you could possibly load the image externally based on a variable, and not have to use families at all ;)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I think you're missing the point. You don't have to make multiple objects to have multiple enemies or whatever; you just need one (and sub-events).

    Think of Mario. There are lots of different enemies but you only need a single object for all of them. This single object can contain every enemy animation and every behavior; all you have to do is give it a variable to tell it which ones to use. Then whatever events you apply to that single enemy object applies to every enemy. It's what I did in Bumper's Quest and it's much, much cleaner and easier than using families.

    Same goes for text objects. What if you want a score counter, a life counter, a time counter, and more? You don't need to create multiple text objects to do that; you just need to give one a variable to tell it what it's representing. Blam you just saved yourself a folder for your text objects and numerous properties to set.

  • I'm trying to figure out what the real advantage of using families over single objects is. Say you have a series of collectables in your game..you could just use a single object with each frame or animation representing a different object, then have an instance variable and sub-events to tell the difference. The same goes for enemies, bosses, bullets, particles, anything.

    -It's much easier to manage & quicker than using families

    -Your object folders will have far less objects

    -Apparently implementing & maintaining families in C2 is a lot of work

    Now there's talk of family values and behaviors and such, which will take even more work, and I'm really just wondering why bother? Are families really necessary? Am I missing something here?

  • GM and MMF games have been put on steam, so there should be no problem with CC games.

    Would you mind sharing which games?

    I hear this a lot but often find out later that said games were remade in C++ or something before being accepted (See DustForce) or were never actually made in GM or whatever to begin with.

    -I think VVVVVV is a GM game that got on Steam

    -Noitu Love 2 was rejected by Steam and it's by far the best MMF game I've seen.

    -Crystal Towers 2 was rejected by Steam but accepted by Desura.

    Basically it's a serious hit or miss. I think a game being made in CC/C2/MMF/GM drops the chances of it getting accepted by 99%

  • I mean I'm sure it's possible but I've only seen 1 or 2 commercial games made in CC, and they weren't anything big. Plus it seems a lot of people have a difficult time running CC games. What happens when hundreds of people buy your game and can't even run it? It would be a disaster. Then they'll want Mac and Linux and other versions which CC can't make. C2 solves these issues but marketing C2 games sounds very complicated and difficult.

    On top of that I'm fairly positive CC/C2 games will never be allowed on Steam, Desura, etc. If you want to make a living off your games, you're probably going to rely on them.

    edit: I guess you could take the ad revenue route with C2 games but imo that's tacky and will get you nothing but pennies unless you have thousands and thousands of visitors.

    I'm not trying to be a downer or anything but I just don't think there's a whole lot you can do when it comes to marketing games made with such programs. I would love to be proven wrong though.

  • Nope.

  • Sooo basically it's an insane amount of work that few people are interested in/capable of doing, and each exporter will have to be maintained for as long as C2's lifespan, and there is unbounded room for bugs and inconsistency.

    Sounds great! When do we start?

  • Yeah so my C2 games run substantially better in Chrome than Aurora ^^;

  • lol I tried that too, but my secondary monitor was considerably smaller than my main, so eh. It "worked" but in the end just made it more difficult to navigate C2.

  • I'd create a tool or game in GM the same way I would in Construct. The only difference? I typed the code out in GM and used events in Construct.

    That said, why is one "programming" and the other not? The same techniques are used, the same math is used, if, else, or, and, loops, arrays, strings, functions, the list goes on. Some (a lot?) of this you'd even find in actual programming languages.

    I understand that actual programming languages are a whole other monster and 5,000 times more complex but I'd call that coding before programming.

    Saying there's no programming involved makes people think you clicked a few buttons and slammed your face on the keyboard and ended up with a game. I really hope I'm not the only one who thinks this, especially after spending years figuring this sh*t out ._.;

  • My how time flies.. Happy 1st :)

  • This is why I dont like how the front page says "no programming required". I think it should be "no coding required" as yes, event-based programming is often referred to as "visual programming". I also feel dumb crediting myself as a programmer when people then go to check out construct and see that there is apparently no programming involved ^^;

  • It helps to think in 45� intervals starting at the right

    0 Right

    45

    90 Down

    135

    180 Left

    225

    270 Up

    315

    But then again I made a few Metroidish engines with directional aiming so this has kind of been burned into my brain XD

    Anyway I'm sure some folks might find this useful.

  • Project black sun, dustforce, and dungeon defenders (cant say I see the attraction with that one)

    I really enjoyed PBS but it felt unfinished at times. It relied too heavily on "visual storytelling" which wasnt very good, but everything else was great.

    Dustforce is really cool but I feel it wouldve made a better action/adventure game. Striving for perfection just to progress isnt very fun.

    Dungeon defenders is meh. Another game that wouldve made a better action/adventure. Tower defense is boring.

    Definitely recommend the first two though!