signaljacker's Recent Forum Activity

  • Thanks for the suggestions. Magicam looks great, but a bit worried about using a behaviour that no longer seems to be supported - and is labelled as alpha. It looks solid though - is it pretty reliable? I remember it being around for Construct Classic.

    I ended up ditching the scrollto method used in the tutorial I linked. Put my lookahead camera back in and locked it to half a screen width away from the ends of each zone the player is overlapping - so it lerps a bit in front of the player if they are more than 320 pixels over from the left hand side and less than 320 pixels in from the right and it's working an absolute treat!

  • Hi all, I'm thinking of switching my camera from a free roaming camera with scrollto behaviour to zone based - I really like how the zone based camera works in this tutorial (which also has .capx example):

    https://www.scirra.com/tutorials/747/zone-based-camera-movement

    Because I was using a free roaming camera before I was able to attach a scrollto behaviour to it and use the 'shake' setting to call screenshakes - but this won't work if I use the zone based method as the camera is locked based on player position. If I add another object with scrollto behaviour on it, so that I can call the shake, the focus then shifts to that object, which I don't want. I need a way to be able to call a nice looking screenshake, but also be able to keep the camera pretty much locked to the zone I'm in.

    The only way I can think to do it is to put the zone based camera movement into a group and temporarily disable it when I call a manual screenshake - move the scrollx and scrolly parameters around a bit - before re-enabling the zone based camera and it will lock back in - but I'm having trouble getting a nice screenshake this way, the inbuilt one on the scrollto behaviour looks much better.

    I've got unbounded scrolling on, but I don't seem to be getting very far. Has anyone tackled anything similar to this?

    Thanks for any suggestions :)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • How are you changing the colours at the moment, are you using the "tint" effect or something different?

  • Thanks for the excellent suggestions. Ultimately I would like them to be saved between sessions so I will look into how to do it with local storage. The other methods are really clever too though and will probably come in handy at some point - thanks for the suggestions!

  • I've been working on a title screen which contains a sub menu with options where the player can tweak various things like sfx/music volume and a couple of simple graphics settings before starting the game. I'm storing these settings in global variables. Only problem is, that when the user presses "new game" those global variables are all reverted back to their defaults (by design, as the game needs to do this), so once the game actually starts - whatever changes the user made on the title screen don't carry over. I'm just wondering what the best approach for dealing with something like this is - I'm guessing that saving those variables to an external file and then loading it in and checking it is probably the way to go - considering that I'm targeting Windows desktop - what would the best method be to do this and are there any potential problems I should know about when writing/reading back variables like that?

    Thanks for any insight!

  • Interesting! Ok so I think I understand, but correct me if I'm wrong - you want the transition to be very slow, but also reactive to your movements - so if you were walking from Forest Town to Spirits Zone the background colour would start off green, and then as you walked further to the right more purple and less green would be added until it was completely purple (when arrived at spirit town). A gradual transition like that will certainly be more tricky and yes, I think the only way to do it would be by setting the colours every tick (or at least a very small time increment). I don't know how to do it off the top of my head (although someone else here might have some suggestions). One thing that MIGHT help to visualise it, is looking at how a slider bar is put together - although it is different, there are certainly some similarities to your problem - there is a video here which goes through how to make a slider bar in construct 2

    Subscribe to Construct videos now

    The similarities I see, are that the slider bar needs a minimum value (your initial colour), a maximum value (the colour you want to change to) and a step (how far along your journey you are/how far between start and end colours you are). You would probably need to set up a bunch of variables to keep track of starting and ending colours and then change these depending on what part of the screen you are on (either by checking x,y position in the layout or using collision triggers). It sounds like you may have already set up something like that so I'm not sure if it's any help...

  • Hi! It's a bit hard to give advice without some more info about how your level is set up. I'm also working on a Metroid style game and have divided my different zones into different layouts which are linked. But there is of course nothing stopping you doing everything on one layout - in fact there are many advantages to it as well. Are you backgrounds made up of multiple layers for parallax scrolling or are they just single static images? Do the backgrounds need to scroll both horizontally and vertically? Do the background elements need to change, or only the colours? Does the colour transition need to be smooth, or can it be immediate? A lot will also depend on how you have set up your game's camera. Games like Metroid use a zone based approach, where each screen's boundaries are limited until the player transitions through a door - are you using something similar to that?

  • Rex Rainbow made a lot of very usefull plugins for C2. Many people used them and he did a great job. When my understanding is correct, Rex Rainbow decided a time ago not to port his plugins to C3. I regret his decision very much but have to respect that. However, are we gonna put the future of C3 on the decision of one man? That is not a good idea in my opinion.

    The problem is, Construct still has some deficiencies, and the community does pretty much need to make plugins to bring it up to the capabilities of other game engines in some respects - so if one of the most prolific and reliable developers of these plugins doesn't support it, then it's a big deal. I haven't checked C3 for a while, but when it dropped I was a bit disappointed, and since I'm several years into a C2 project I probably couldn't switch even if I wanted to. There are so many simple plugins that should come as part of the standard package - things like the canvas, move to, music fade, image/perspective distortion etc. The perceived mentality of Scirra seems to be that the community will make all that stuff, but I would be more confident if the base package had more of these quality of life improvements built in, so that we had proper ongoing support from the actual developers. Like I said, I haven't checked out C3 for a while, but last time I checked it still seemed to be missing many things that I would have thought obvious as high priority for people building a game engine that is meant to make things easier.I absolutely hate relying on plugins from sporadic developers, who use a forum like this full of dead links to post their work so I wish Scirra would take more responsibility for useful core behaviours and plugins in this respect as the community files are decentralised and an absolute mess. Community plugins are great, and I love the idea of them, but they should be used to enhance an already great product, not fix it up with sticky tape and glue.

  • Thanks heaps Dop - that is a huge help indeed! Much appreciated :D

  • Hi, I always seem to have issues with making multiple things on screen behave in a timed manner, but to different times.

    I have some columns which pop in and out of the ground - each one has a timer behaviour, an instance variable called "traptimer" and a boolean variable to see if it is active or inactive - at the start of the layout I do a for each loop and set the timers to the "traptimer" instance variable. This then toggles that boolean variable on and off and stuff happens depending on its state. This works fine for one object. But as soon as I have multiple, all hell breaks loose.

    If you look at the attached example, you'll see that there are 3 columns, with their "traptimer" instance variables set to 1, 2 and 3 seconds. If you look at the objects in debug mode, that boolean is being toggled on and off at the correct rate for each of them, yet the animations are going haywire. I can't seem to find what's wrong, if anyone has a moment and could take a look it would be much appreciated. Many thanks :)

    LINK:

    dropbox.com/scl/fi/zefo5il7kzuz49chmo8u5/popup.capx

  • Try putting them on the layout rather than the layer.

  • Zed2100 - thanks very much! It sounds like it could be a good solution. Perhaps sticking the objects into a family and scrolling that is the way to go. The map is made up of an array, 2 tilemaps and a position indicator so could be wrapped up in a family and scrolled without too many problems I think. Now that I think about it I might just be able to pin everything to an invisible bar and scroll that. Thanks for your response, I was probably approaching the issue from the wrong angle.

signaljacker's avatar

signaljacker

Member since 10 Aug, 2011

None one is following signaljacker yet!

Trophy Case

  • 13-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

17/44
How to earn trophies