signaljacker's Forum Posts

  • Games like Ori don't actually have massive backgrounds. They just cleverly layer things. If you look closely, you will notice that it's the same stuff used over and over again, but maybe rotated/scaled differently. They use a lot of little tricks to make it seem fresh. You're thinking like a traditional artist, in that a background is a large static object. You need to think like a game designer in that a background can be made up from many smaller objects that can be repeated/tweaked. This is better for both memory, and allows you more flexibility in making your background more dynamic.

  • I have some old C2 projects that I want to reuse a bunch of actions from. As far as I can tell there appears to be no way to copy and paste actions between Construct 2 and 3, or am I missing something? I tried to open up my C2 project in C3, but it won't allow me to because of some old plugins that were used. Is there some way to bypass that and just proceed so that I can get to the event sheets? Thanks. I understand that the program won't run properly without those plugins but it seems a bit extreme to lock me out of the project completely as there is a whole host of other useful things I can be getting from it.

  • 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 :)

  • 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/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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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!