PixelRebirth's Forum Posts

  • I know this could probably lag the game at some point. Would it be a good idea to shrink everything by half and at the same time zoom the screen by half? So that when playing, it would seem as if everything is at the same size as its suppose to be.

    If you had a really big layout you'd probably need some kind of system that would create objects if they're about to be onscreen and destroy them when they're off, in order to get good performance.

    As for the shrink/zoom idea... what????

    You would lose detail by shrinking your sprites, not to mention it'll probably look awkward. Sure if you zoomed in they'd take up the same size on the screen, but that's besides the point. Don't do it.

    I still believe it would be very doable with the theory I mentioned. Creating a basic example seems like a terrible chore right now, otherwise I'd try to do it.

  • I'd say for that type of matching puzzle, in a finished version you should disable swaps that don't result in a match. Obviously it's up to the mechanics you want, but being able to move them freely takes some challenge out.

    You have a good point there. I wonder if I should include it in the third part. It wouldn't be terribly difficult to add yourself for somebody who checked out all the examples.

    Actually I'm on the verge of rebooting this whole tutorial in favor of a more array-based approach. While I was creating the first two parts I realized that, while it still worked fine, it is the same old engine I used for Crypta more than half a year ago after all, just a little pimped. So I created a new engine for my game, making much better use of the array.

    I'm uploading now a replacement for the first part of the tutorial. Let me know what you think. Array all the way or rather the third part of the original examples or both?

  • How unexpected. Have to check this out asap! Some good fixes there, thx devs!

  • I'm just answering this because noone else seems to. My knowledge of the binary object is pretty limited. Though I did briefly try to use it. Trying to read anything from it seems to result in a Construct crash (Read byte, Read string, Read float...), which lead me to believe that the binary object is indeed broken.

    Anyone can confirm or deny?

  • I would get completely rid of the idea of having the NPC actually travelling from one layout to the other. Let me give you my current thoughts on this...

    The player obviously will only be in one layout at a time. Now if a NPC is supposed to be in this layout, you simply create him and pull his stats from some sort of database. And respectively, if he should "leave" the layout, save his current stats again to the database. Maybe let him walk to a certain destination on the map and then destroy it. Easy enough theory I guess?! Indeed it's very theoretical without any concrete advice how to do it object/eventwise, but that's the fun part for you to figure out.

  • I think it should be changed to TimeDelta. Things should be TimeDelta compliant whenever possible, yes? As for the broken .cap problem, might I offer up the old "sacrifice for the greater good of 1.0" argument? It doesn't seem like it would be a terribly difficult fix anyway, for a user to change the duration of the flash in his event.

    I second that. TimeDelta all the way baby!

  • Okay folks, part 2 is online now!

    I hope there are not too many typos or even crude mistakes in there.

  • Great fix! Advanced Camera has become obligatory in all of my projects. One of the most essential plugins around. Can't wait for more!

  • Oh linkman I love you! I could have a use for this right away, will make things handier for sure! Thx so much!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Thx to everybody for commenting.

    Just went through it, I noticed you referenced an object as to where to start creation, not totally necessary if you're designing with a grid, you can just do array's current x + 32 for example and it will fill in every spot until it runs out of space. Though your method works just as easily, I don't think one way is better than the other. The tiled bg does make it more 'mobile' for editing where it lays in the layout.

    You're totally right. It's just the way I prefer to do it. You could get rid of the tiled bg with some adjustments anytime.

    Thanks a ton for the tutorial. It's gonna help me get my 'action' puzzler finished up. Just need to figure out if an array is the right way to create my blocks since there will be a constant generation going on from the bottom.

    Spawning of blocks will be the topic of the third part. It should be adjustable to a constant spawning too, depending on the game mechanics you aim for. I don't think an array will pose a problem with that, at least not the (pretty limited) way I use it.

    Expect the second part to be online later today or at least tomorrow.

  • Oh, great that you mention this. I don't know why it is in there. Removed and updated.

    Btw Contrast Plus is a very good FX by jeffro11 you should get it asap!

    http://69.24.73.172/scirra/forum/viewtopic.php?f=16&t=4835

  • Due to popular request: This is a tutorial/example from which you can learn how to make a puzzle game in Construct. One of the kind where you have to match three or more blocks horziontally or vertically.

    Let me briefly mention that I wouldn't recommend this for absolute beginners. So if you installed Construct just yesterday, you should probably get a little more familiar with it before you check out this tutorial.

    This is just my personal approach and doesn't claim to be the way to go.

    <font size="5">Part 1 - Playfield Generation</font>

    <img src="http://dl.dropbox.com/u/2306601/puzzexam1.png" border="0">

    First things first. So we start out with the generation of the playfield. Simply randomized blocks won't do, because we don't want three or more blocks being matched in the beginning.

    So let's use an array, some sweet sweet loops and basically crazy stuff.   <img src="smileys/smiley17.gif" border="0" align="middle">

    All in the cap, all commented, there you go:

    DOWNLOAD PART 1

    <font size="2">(File created with version 0.99.42 of Construct)</font>

    <font size="5">Part 2 - Swapping, Matching & Destroying</font>

    <img src="http://dl.dropbox.com/u/2306601/puzzexam2.png" border="0">

    Now we get to the really important stuff. After all a cool puzzle game can't work if matching blocks aren't even recognized. It's not quite as simple this time, but nothing to worry about either.

    Expect more loops, crazy Else events and... you name it! <img src="smileys/smiley1.gif" border="0" align="middle">

    DOWNLOAD PART 2

    <font size="2">(File created with version 0.99.42 of Construct)</font>

    Oh, this time you will really need the Contrast Plus effect. Go get it here:

    http://scirra.com/phpbb3/viewtopic.php?f=16&t=4835

    <font size="5">Part 3 - Spawning</font>

    <img src="http://dl.dropbox.com/u/2306601/puzzexam3.png" border="0">

    What's left to do is filling up those unwanted gaps with brand-new blocks.

    How is it done? Of course with some nasty events, featuring loops and all the other stuff your parents warned you about! <img src="smileys/smiley4.gif" border="0" align="middle">

    DOWNLOAD PART 3

    <font size="2">(File created with version 0.99.42 of Construct)</font>

    <font size="5"><font color="red">Part 3.1 - Now it even swaps back!</font></font>

    Here's the functionality some of you have been yearning for: blocks are swapped right back if there hasn't been a match. Thank sweet baby jesus!

    Note: All of the newly added comments have green text color on black ground, so you can easily spot them.

    DOWNLOAD PART 3.1

    <font size="2">(File created with version 1.2 of Construct Classic)</font>

    Also still available: alternative first part

    DOWNLOAD ALTERNATIVE PART 1

    <font size="2">(File created with version 0.99.42 of Construct)</font>

  • It may not be always apparent; are you using two instances of Mouse and Keyboard object?

    Hey, that might also explain the old bug I had in the back of my mind. If only I could figure out which cap that was and revisit it...

    Need to keep this in the back of my mind from now on!

  • Where can I download this ''cap'' file?

    It's hidden inside that thread.

    Here you go: Download

  • Pseudo code:

    +For each block

    - Are any of its four neighbors of the same color?

    - Check that block's adjacent block, that is in the same direction

    > Mark these blocks for demolition

    >When done checking all blocks, DEMOLISH! Then re-check all blocks until NONE are marked for demolition and wait for player's move.

    Mipey's theory would absolutely work. But you probably wouldn't want to check all blocks. Just those that have been moved or rather the rows and columns of those blocks.

    That's the stuff I added to mattdubs cap in the mentioned thread. It's just not destroying there, but changing opacity for testing.

    It's not a whole lot different from what I'm doing anyway. I just happen to involve an array to a certain extent.