declan_gage's Forum Posts

  • Hey damainman, I know it's an old topic, but in case you want to keep working on go-go-maddi, I have devised a way to work on large games in CC.

    You just have to cut your game in different levels, here is the how-to method here:

    scirra.com/forum/construct-game-from-several-caps_topic44630.html

    In your case it would imply making a copy of the game for each level and strip it of what's not relevant for this level.

    Hope this will be of help to you

  • Actually I have found out that you have to reference with the number of the image point, so if it's the first image point it is sopmething like

    sprite1.ImagePointX(1)

    The quotes don't work

  • I have a sprite "sprite1" where I have defined an image point that I have called "pointA".

    I'm trying to reference it in an event

    system->object overlaps point->sprite1.ImagePointX(Imagepoint),sprite1.ImagePointY(Imagepoint)

    what I am supposed to write in the parenthesis?

    I have tried

    sprite1.ImagePointX(pointA)

    sprite1.ImagePointX('pointA')

    sprite1.ImagePointX("pointA")

    none of these work, so what is the correct way to reference an image point that I have created?

  • there is one such event already

  • no other behaviour, I just set the player number to any number other than player 1.

    It didn't happen in previous versions of CC

  • I think a simple game is easier to get into. For me I have very little time to play anything anymore (despite the fact that I still pre order crap). And then it turns out to be just that - 7-10 hours of crap.

    With an arcade side scroller, you know what you're going to get, you already know if you're going to like it 5 seconds in etc. And it's the attract mode that pulls you to the machine.

    For me I'd rather play any Capcom arcade game excluding the one on one fighters, Konami's old arcade machines, Data East, etc over anything nowadays. They're a quick fix, there is 1000x more quality and dedication put into them. And how often do you walk away from one of those games disappointed with anything?

    I can agree 100% with all that <img src="smileys/smiley20.gif" border="0" align="middle" />

    And the new powers look awesome

  • that's interesting, but isn't this what the construct editor already does under the hood?

  • I have a bug in the platformer behaviour where enemies will fall through platforms after a few seconds(object with the platform attribute)

  • Well done, I must say that your game looks really imperssive despite being simple and inspired by ancient games.

    It's typically the type of projects that is only made possible by a tool like construct, and a lot of dedication. You also have some good pixelling skills.

    Hats off. <img src="smileys/smiley20.gif" border="0" align="middle" />

  • thirded, Scirra falling into the HTML5 trap was my biggest disappointment in years

  • very nice. A couple observations:

    -when walking to the right the picture of the character appears very crisp while he's a bit blurry when walking to the left

    -when walking the animation is lower (he sinks into the platform)

    -is it possible to scale the breathing of the character because it's very exagerrated, it could be nice to berath exagerrately after moving a lot and then progressively scale the breathing down when he's idle.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 1-uncheck "solid" in the hero attributes (it's for the environment, platform characters slide on collision with solid object)

    2-set the enemies' hotspot in thecenter of the character (not in the center of the sprite)

    3-in the "battle" event sheet, try removing the condition that theenemy.Y is greater than the hero bottom.It works better like that.

    there are other problems in the way the enemies are made to move. But now you can jump on them sometimes

  • I can't even use my latest project beuase of the lag. Ver sad.

    I might have found a solution to this. You can use a .Cap file for each level(for multi-level games), see this thread for more details.

  • Okay, so I managed to make this work somehow. It's messy, and it's probably not very orthodox but it does work.

    Basically you have to create an executable for each of your levels and or menus.

    then when you want to switch levels, you launch the new executable (by using the 'File' object) and close the current one (to avoid construct throwing a DX9 error) with system->close.

    If you want to share data between levels (such as scores, lives, passwords, etc...) you can save it in a temp file like a hashtable.

    I suppose there might be problems such as memory consumption, but it's useable , I tested it heavily.

  • Is it possible to create a game by creating each level in a different .cap file and then calling a new cap file at the end of each level?

    I'm asking this because construct tends to become slow and crash-prone when a single .cap file grows larger and I have a game idea that would involve a lot of levels with a lot of graphics.