thomasmahler's Forum Posts

  • I imagine building a balanced fighting system would definitely be darn complex and I'm not whether Construct would make that task particularly easy right now, with collisions.

    If you've never done any game before, maybe try going with something simpler first.

  • 36) Export Layout to Exe

    That'd be pretty awesome. If I wanna show a person just a certain level or another developer a certain problem or whatever, I could hop to the layout that I'd need to show them to, press 'Export Layout to EXE' and the layout would be exported into an exe - just as if I'd run the layout as a runtime only.

  • Haha, what the hey, I didn't even see that Joakim is here too. I guess that pretty much goes to show how awesome Construct already is (and also how small the industry actually is )

    Good to see you here, man.

    Just hope more and more people find out about it and also hope that the industry adapts it at least as a prototyping device, so we can do better stuff in a shorter timeframe.

  • Get another imagehost.

    I don't see anything.

  • Yes, I think that'd work.

    Pretty please?

  • I read a gamasutra interview about Joakim Sandbergs Noitu Love and him saying that he's not a programmer and that he created the whole game in 8 months using Multimedia Fusion.

    So I tried out Multimedia Fusion and thought it was a piece of crap. Then I somehow read about Construct, either on their forums or on whatever and gave it a try and it was exactly what I was looking for.

    That's my Construct story in a nutshell so far

  • 35) Let's extend the picture (sprite) editor to have an optional collision layer on top of each sprite. Or multiple layers. That we could then trigger through events.

    I think that'd be the simplest way to define weapons and stuff for collision events.

    So, in the picture editor, I'd create my sprite and then create a new collision layer (like in Photoshop) that I could fill up with pixels. Then I call my collision layer "swordCollision" for example. If I go to the next frame, it'll automatically copy over the collision layer from the last frame and I'd just do my adjustments. So for the whole animation, I'd have one big collision set of layers that could be triggered through the name of the collision set.

    So, to set an attack event, I could do this:

    If Attack is pressed, if player.swordCollision collides with enemy = decrease enemy private variable 'HP' by 10.

    Simple.

    Being able to have a seperate layer in any sprite that you could fill up with pixels based on what should and shouldn't collide with whatever would be a very, very handy feature.

  • Event sheets go in the event sheet folder? Makes sense to me.

    Displaying them twice is what's confusing me.

  • Wow, it does look great. It's 3D and scripting-based though. Looks like a 3D construct sort of

    It's still a different ballpark.

    Construct is still faster and easier to access for artists. Unity is production proven and ready, which is a big plus, but there definitely is a big difference in how Unity works and how Contruct works.

    Now, if Unity would have something like the event editor and if it'd be as smart as Construct in that regard or even go for a completely nodal system...

  • That's very nice. Only thing I'm wondering is why you've got two layout 1 event sheets. The layout 1 event sheet is directly parented to the layout 1, which makes sense, but why is there another folder with event sheets where there's another Layout 1 event sheet in there? That's a bit confusing.

    Other than that, it looks ace. Will make the organizational part much easier

  • What??? It definitely shouldn't be doing that - I definitely wrote it to scale and rotate collisions too. Submit a bug report!

    Already did

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 13) Okay, I either don't get a feature here or I encountered another bug.

    It's about the timeline this time:

    Basically, I want the player to run across a certain point (if player overlaps...), then start a timeline event that feeds into a textbox, so we can spin the story further if the player has reached a certain point in the layout.

    The problem is: I want the timeline to run once and then be gone. So if I go back and overlap that point again, I don't want to invoke the timeline AGAIN, cause I don't need to hear that part of the story twice.

    So there's a Delete Checkbox in the timeline event and I thought this would be exactly what I'm looking for - so if I run cross that point, it'll run the timeline parameter and delete it afterwards. Then it'll run the next timeline param and delete it afterwards, etc.

    But that's not happening. And if I re-enter the timeline object after I checked the 'Delete' checkbox, it's unchecked again.

    So:

    1) Is this feature supposed to do what I'm thinking it should do?

    2) Is this a bug or am I misinterpreting that feature?

  • Just found out that if you set the collision model to be 'per pixel' and you scale the sprite in the layout editor, the 'per pixel' stuff is still being based on the 1:1 sprite.

    Wouldn't it make more sense to base it off of the actual pixels of how the sprite is being drawn at runtime?

  • 34) I'm currently trying to create an 'Attack' event and I'm wondering how we'd best set this up. Currenly, my setup looks like this:

    On collision between Player and EnemyFamily

    is global variable 'Attacking' Equal to 1

    = enemy: subtract 5 from 'HP' (which is a private variable for each enemyType)

    EnemyFamily: Value 'HP' Equal to 0

    = EnemyFamily: Destroy

    And that sorta works. Now, the problem comes with the collisions themselves. How would I define that only the pixels of the sword actually hurt an enemy - and not the whole playerSprite?

    It'd be really cool if we could create a collision layer for each sprite in the PictureEditor that we could then trigger for events. So for my character, I'd create a collision layer for the 'Attack' Animation and color in all the pixels of the sword. Then I'd name that layer something like "Swordmask"

    Then the event would be:

    On collision between Player.Swordmask and Enemy Family... etc.

    Or is there an easier way to set things like that up that I just don't know of?

  • Yeah, it'd be cool if it could work like a tiled background that we'd just feed with the source data. The current windows-y implementation isn't all that great.