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

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/s/23njtqfx1bbx0fd/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.

Hi all, I hope this makes sense, I would post a .capx but it's a bit hard to isolate from my game at the moment, but if anyone thinks they can help and wants to take a look I will do so. Will try to describe first.

My game has several different layers, one of them is a global layer called 'MAP' which is shown when the user presses the M key. When the M key is pressed it pauses the game and it unhides the map/menu layer.

The map/menu layer contains three screens worth of information, so it can't all be displayed at once. Instead I give the player the option to press the left and right arrows and it will smoothly scroll to the relevant point on the screen using lerp(scrollx, target, etc). Because I can't target a specific layer to scroll to, it does the whole layout - it doesn't really matter because the map screen covers the game area so the player would be unaware of this, BUT using this method there is quite a limitation, in that if the current game layout is smaller than the area needed for the 3 menus it can't scroll to them.

So if I have 3 screens wide to fill with my map/menu it takes up 1920 pixels but if the game layout is smaller than that eg 1280 pixels, the scrollto won't work at any range outside of the layout, even if the layout the global map layer is on is larger than this and set to unbounded scrolling.

If I could turn unbounded scrolling on and off with events, or if I could target a scrollto location on a specific layer I might be able to come up with a workaround, but there doesn't seem to be a way to as far as I can see. I could just make sure all of my layouts are at least the width needed for the map/menu - but it will be a lot more mucking about, less easy to maintain - as I'm doing a metroidvania style game with many different rooms/layouts with a map etc, I don't really want to have to pad layouts out like that if I don't need to.

Anyone got any suggestions, or better ways I could go about this?

Many thanks!

I don't think Construct 3 is any more limited, but as John Cutter said there will be less addons (some of which are very useful). A lot of people can't transition over to C3 due to being mid way through large C2 projects with dependencies on such addons, or don't want to because of the rental system. There isn't really a right answer. If you don't mind software rental then I'd say go for C3 as it's where Scirra are focusing their energies and it will only continue to improve. There are some workflow enhancements, and of course it will run on tablets if that's your thing, but there's nothing really that new or interesting feature wise added to C3 yet. That said though C2 is pretty feature complete for a lot of things and will probably be relevant for a while to come - if you design your game without using too many additional plugins there's nothing stopping you building it in C2 and then continuing it in C3 if you ever wanted to - that would probably be the 'safest' route as you will have a perpetual C2 license and the luxury of developing at your leisure but also knowing that you can jump onto the newer platform if you need to at a later date.

On each of your play and exit controls, before the System>go to layout - you can just add an action for the audio plugin to stop - and then put in the tag you want to stop, so in this case stop "game action" it will stop the audio, so in the next layout on start of layout you can put in another audio action to start the relevant audio for that layout.

Rather than attaching a sound to each tile, it's probably better to attach it to an invisible sprite and then place the sprite in an area that needs the ambient sound (tweak the settings so that the distance/volume is correct etc). I usually just create a bunch of these invisible sprites, 1 for a waterfall, one for birdsong etc and then place them strategically on my layout.