Valhallen's Forum Posts

  • A scale outer integer mode has been asked for before. It would be a great addition so essentialy it would scale to the next integer size outside the window instead of inside as we have it now. Nothing has come of this request though.

    Yes that's more precisely the effect I was searching for. I'm happy to see I'm not the only one trying to do this, and that it actually has a name. Too bad it's gone unimplemented.

    > Found some moderate success using the Crop fullscreen mode, along side Magicam to set the layout zoom on tick based on "round(WindowWidth / GameWidth)", while also keeping the player centered.

    >

    Also, what project settings did you use?

    Basically I've got my Magicam setting zoom based on the size of the window. Anytime the width or height surpasses a multiple of the true game resolution, the zoom increases by 1.

    So if your game is 100 pixels wide, and your window is stretched to 530 pixels wide, it would be zoom = round(530 / 100), which would result in the camera being zoomed to 5x normal. As long as you keep your zoom at integer values, your pixels will stay square. I then have my project's mode set to Crop. I can give you more details once I'm home, but that's really the gist of it.

    I believe I take (windowWidth / nativeWidth) and then compare it to (windowHeight / nativeHeight). Which ever is bigger is what I use as the new zoom. I may do some shenanigans involving checking if the current platform is mobile for some small-format changes, but not much else.

  • Found some moderate success using the Crop fullscreen mode, along side Magicam to set the layout zoom on tick based on "round(WindowWidth / GameWidth)", while also keeping the player centered.

  • Hello,

    I've got an interesting task that I need some help with.

    I need to keep my game pixel perfect, so Integer Scaling works nicely for that. However I am trying to make it so that it doesn't pop immediately to the next multiple down showing large black bars, but instead will crop the game until that next integer multiple is possible, and THEN it will pop to that scale, and continue the cropping. This way there are no black bars, and it will only be cropped if the window is off-aspect.

    Is this possible? I'm struggling to figure out how I might be able to do this by manipulating the camera using the WindowHeight and WindowWidth, but it hasn't been very successful yet.

    Any suggestions are welcome.

  • I found a solution. If I set the project properties to scale for fullscreen browser with letterboxing, and also export it as HTML5 website for embedding, it behaves as I was hoping. The game will treat any wrapper element as the bounds for the scaling and letterbox/pillarbox.

  • Hello!

    I've been commissioned to create a small web game that will act as an interactive roadmap. This game must be responsive in that it will have at least 3 sizes to display at for phones, tablets, and web browsers.

    After reading this article about scaling it seems like Construct 2 may be able to accomplish something like this reasonably quickly.

    So my main question is this: how would I go about making a game that will scale to fit any parent element it is put in while maintaining aspect ratio, similarly to how the fullscreen scaling modes fill the whole browser?

    Is this something that I can set up in construct or will I need to turn off scaling and do it on the html/css side of things?

    The website is already responsive and has lots of responsive elements in scrolling areas etc, so I'm hoping I can create the game in a way that they can simply make this game a child of an existing responsive element, and it will appropriately resize to fit within the bounds of that element.

    I've already created a solution using Unity3D, but the initial load times are far too slow.

    Thanks

  • You could use the wallclocktime expression to get a time unaffected by time scale. Store the wallclocktime when the timer starts, and compare the current wallclocktime to the stored value to determine how much time has passed.

    Alternatively you could you make a family of objects to be slowed down, and set the object time scale for that family instead of changing the global time scale.

  • The light radius is a circular gradient image as a sprite which follows your character (pinned perhaps). This gradient could be used on a layer colored black, and you would use that gradient as a mask to see through the black layer.

    Your character also needs a shadow light object to follow it (pinned perhaps), and all the boxes need a shadow caster behavior. Make the shadow casters cast on a layer above the circular gradient light radius, and the effect should be complete.

    Perhaps see this for guidance on the light radius effect:

    Subscribe to Construct videos now

  • Add the System Condition "Trigger once while true" to the end of the event where you spawn the particle system. It must be the last condition in the event.

    Mouse is down && Trigger once while true -> visible

    Mouse is down (inverted) && trigger once while true -> invisible

    Alternatively use the onMouse pressed and released events, they only trigger once.

  • Here's an idea, I haven't tested it.

    You should be able to use the "Move at angle" action on the new objects when they spawn to move them away from each other in the direction you want.

    Description:

    "Move the object a number of pixels at a given angle in degrees."

    You'll want to get the angle that the original object is moving, then add 90 degrees. Spawn the first new object and "Move at angle" with that new angle by the new object's width for distance. (Or perhaps half-width if it spawns on its center)

    Then take the original object's angle again, and subtract 90 degrees. Spawn the second new object and "Move at angle" with this new angle, again by the new object's width for distance.

    If they still collide, add a bit to the width so that they don't collide.

    Alternatively, if you don't need the spawn placement to be variable, you could specify two image points on either side of the original object, and spawn your two new objects at those image points.

  • This plugin was exactly what I needed. Great job. Thank you!

  • Add the "Trigger Once While True" System condition to the event. It must be at the bottom of the list of conditions.

    It will trigger once, and only trigger again once the condition becomes false, then true again.

    Then to disable this, you could either keep it in a group and deactivate the group in the actions, or use a global boolean as previous suggested.

    I prefer to use groups for activating / deactivating bits of functionality.

  • You definitely want to use the Physics behavior. But it does take some experimentation to learn how to use it.

    Just understand that in order for two objects to collide using Physics, they both must have the Physics behavior. This means your ground will have a Physics behavior, with "immobile" set to true. Your player and your items will have a Physics behavior as well.

    It's not the easiest behavior to work with, but with lots of tweaking and experimentation, you can get some interesting results.

    Also look into the Chipmunk physics plugin if you need more joint types and extra functionality.

  • Hello,

    I've come across an issue in my game, where when you press Shift + Right Click, it opens a context menu from the browser, and ends up locking whatever inputs were being held in the game until the menu is cleared and keys re-pressed. Obviously this is very problematic.

    Is there a way to stop this from happening via Construct?

    EDIT: After some testing, this appears to be a FireFox specific issue.

    Thanks

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I once did something similar, though it wasn't for weapons but could be adapted easily enough. In my case I checked if the object was on screen when the family variable signaled action, so it would only respond if it was equipped, hence in view. Not foolproof but I imagine there's lots of other conditions I could've substituted for something more elegant.

    That could possibly work, but my character has two separate hands for dual wielding, so I'm not exactly sure how I would handle that.

    However I will try to implement this and I'll post my setup if it works or if I find anything more elegant.

    If anyone has further suggestions I'm all ears.

    Thanks

  • The point of having a generic fire function is that each weapon could have an event sheet where it has it's own fire function, which says which projectiles to fire for itself. The player just needs to call CurrentWeapon.Fire() and the weapon handles the rest. No checks necessary.

    Well, perhaps this is just going way over my head but it seems to me like you'd need to run a weapon check at one point or another in the event sheet to know what projectiles to shoot.

    I suppose you can make the shoot sequence something more generic like "On shoot -> set boolean to true" where the boolean is a family variable found in all weapons (in the same family), then code every each weapon to respond differently when their boolean is toggled, if that's what you're after.

    That might be able to work. How would you suggest I keep a reference to the current Weapon family member equipped in order to set the boolean?

    So if you want each weapon to have different actions upon firing, why would you need to call a generic fire function?

    You could ofcourse call a fire function and add the current weapon as a parameter and add the specific actions for that weapon in the function by comparing the parameter..

    I'm not really sure what the question is..

    For that solution, what would I be passing? A string with the name of the weapon? Some number that represents the weapon?