Lou Bagel's Forum Posts

  • Have you run into performance issues already? I have a feeling you might be overthinking this.

    The example projects seem to loop over all instances, which is fine for the limited scope of the examples but would not work out well for projects with larger levels and lots of instances.

    ...

    Our profiling has shown it's not unusual for even a fairly complex game to spend 10% of the time on the logic, and 90% of the time on rendering

    Quote From: construct.net/en/blogs/construct-official-blog-1/optimisation-dont-waste-time-768

  • I believe it is because you have the scale rate at 0

  • One idea is to define my own borders within a layout at max size but that method would be very complicated and tedious to implement...

    I'm not sure why that would be very complicated and tedious. Can you explain the issues you have with that method?

    I think that is your easiest route. Make the layout very large. What is the downside of having large parts of the layout unused?

    You could cover the unused area with a tiled background, block it off with solid objects, or whatever else you need to do, depending on your game mechanics.

    If you are thinking of issues more so with the level editor part, you could set the area of the tilemap, which would stop them from trying to edit the tiles outside the level. If not using a tilemap and something like drag and drop, you could just have an event to check on drop if the dropped position is greater than the level width/height.

    Maybe there is a way to change the layout size now, but I know in the past it was not possible. Even if it is, I'm still not sure how it would make anything that much easier for you here.

  • I figured it out. I just had to wait for the donut to cook.

    Yes, the Practice bar on the title screen should help you figure that part out.

    Thanks for the screenshots. Looks as expected.

  • everything is very small and it's not clear how to play. I tried to click on the cash register and on the bag of money but was constantly killed by visitors.

    What device did you play it on?

    I haven't tested it across a lot of different devices. I'd be interested to see if something important is not fully visible. A screenshot would be great, too.

    There should be a huge button at the bottom. It is pretty simple - you hit that button.

  • Okay, I wanted to take my time in responding as I answered some of my own questions. Also, my app has made it to the the app store (here) so no big issues.

    Most of the time changes will only be in the www folder.

    This has helped a lot already. Thanks for confirming.

    However some project changes may affect the Xcode project too, such as changing project settings . . . a diff tool can easily show the difference

    I threw the exports in a repo, as I should probably do that anyway, and used git to compare. Indeed things like changing project settings or adding new plugins that require changes to the browser APIs (like touch or audio) will cause other changes. There are some differences in some hashed looking lines, which I threw in ChatGPT asking what it was, and they were identifying build files. So I'm hoping the hash reference changes but the contents stay the same, therefore don't need any update.

    So far, I've replaced only the WWW directory multiple times after making changes to mostly events and have not come across any issue from that process.

    Remote Preview is designed to let you quickly test on mobile without needing to export every time. Is there a reason you're not previewing with that for faster iterations?

    Honestly I forgot about Remote Preview completely when I posted as I was trying to test out the workflow and troubleshoot any Xcode issues up front. So I apologize for making it sound like the normal workflow.

    Although there still are reasons for needing to export:

    • Fullscreen: the remote preview has the navigation bars from the browser. I was trying to decide how I want to use that extra space, such as scale outer and what will actually show, so need to see how it will actually show native in device
    • Device Emulator: Checking it across different devices that a person doesn't own
    • Troubleshooting: Probably more of an Xcode area, but troubleshooting any issues with the project in Xcode
    • Apple Review: Upon Apple rejecting your submission, you will need to make changes and re-export
    • Updates: releasing new versions

    Since re-exports should be expected, I'm hoping to figure out a workflow to minimize the pain points. Personally, I'd prefer to use the same Xcode project file, even if it is just so that I can keep the project open when merging a new export and don't get confused if ever trying to "open recent" or something.

    AFIAK the process for exporting to iOS hasn't changed substantially over the past few years, so the existing documentation should still apply. If anything is out of date then let us know.

    Now that I have worked through it and resolved everything, the Docs still seem relevant.

    When I made the comment I was looking mostly at this tutorial which is 5 years old and I ran into an issue when I got to Previewing in Xcode, which is about a tenth of the way down the page. Then I looked at the comments to see if anyone else experienced the same thing but saw others asking for an update.

    The issue I came across was related to pods. For reasons I can't state, I cannot install cocoapods. Therefore, my workaround was to remove a couple lines of code:

    So far so good, though I do want to look into that more to know what I am removing.

    As far as documentation and tutorials, are there any gaps you see?

    I feel like I've read through most of your blog posts related to this topic, such as how to plan for mobile games with touch controls etc. - so know you have a lot covered.

    I tried to take notes on the steps along the way. Not sure if it is worth the effort to try and make a tutorial - a lot to cover and a lot already covered.

    But maybe I could add value diving into a bit more details on Xcode or the Apple Developer portal side of things. Though I understand it doesn't make sense for Construct to document tools or processes you don't have control over, these are pain points your users most likely come across. If they can't turn to Construct site (forums, tutorials, docs) and need to turn to Apple Docs, that can be rough finding what you are looking for.

  • That is a mouthful of a question, so let me walk through the thought process behind it.

    But first, for anyone who is on the same page as me and thinks they know what I'm getting at, here is the question in short form:

    Is it only the files in the www directory that change upon making changes in Construct?

    iOS/Xcode Workflow:

    1. Export Construct 3 for iOS (Cordova); choose Xcode project for iOS build; download zip
    2. Extract zip; open xcworkspace in Xcode
    3. Make any necessary changes in the Xcode Project. For example, right now, I have to delete some lines of code regarding pods for the build to succeed. With publishing in mind, icons need to be added/updated and developer signatures added.
    4. Test
    5. Upon finding any changes to be made, go back to Construct 3 to update and start this process over again

    Step 3 is the step I am trying to eliminate. It might not sound like much, but any opportunity to improve workflow is a win, especially when it is tedious steps like this.

    So, to my question: which files in the export change upon making changes in the event sheet or layout?

    I'd much rather have an existing project that I continue to use and replace certain files with the newly exported ones. This allows for better organization, automation, and source control tracking.

    On a side note, upon searching, it seems like most documentation on Construct -> iOS is about 5+ years old. If anyone has updated docs or tutorials, feel free to leave links.

    Tagged:

  • Thanks for sharing!

    I don't like having hidden objects/layers that aren't serving any specific purpose...I doubt there is any performance impact worth thinking about at all

    Yeah, I don't think so either and feel the same, plus I always enjoy having fewer objects when using the debug preview, ha.

    I also generate my menu item positions dynamically via events to be flexible

    I'll probably end up doing this, too, as it is less tedious for me to center and evenly space objects in events.

  • Hey all,

    I'm just curious, for people that have added elaborate menus/settings to their game, how they set it up and pros and cons they have found.

    I don't just mean a simple pause menu that is one screen. Think multiple screens or options, whether it is settings like video/audio/gameplay/controls, or gameplay menus like inventory and other sub menus.

    The way I see it, I can think of three different ways to set it up:

    • Layer: Set up the menus on a layer and toggle visibility & interactive
    • Events: Create & Destroy all menu aspects (sprites, text, etc) via events
    • Layouts: Create a separate layout to switch to for these menus/settings

    The first one seems the simplest to setup, with just creating hidden layers for everything. But it also seems the messiest, as the amount of hidden objects in your project will grow. Has anyone run into performance issues with this, or bugs to troubleshoot? (probably user-error bugs, like accidentally destroying/moving menu objects)

    The third one also seems easy to setup, but depending on the game, might have a difficult time switching back to the original layout and having everything where it was before.

    The second one seems optimal to me. But it does seem a tad more tedious if it isn't quite necessary.

    Open floor - Just wanted to throw it out here to learn from anyone else's experiences or see if any of my thoughts are flawed. Feel free to suggest any other ideas or bring up any related points or questions.

    Thanks.

  • ...and some physics to avoid overlapping...he is knocked out of it with some 8-direction values...the player starts moving by itself in the direction it was already moving. Like if the movement key was being pressed...seems like the x and y vector are moving by themself

    It probably has to do with how you set this up - I condensed your post in the quote above to highlight - and without knowing how you set this up, not sure what advice we can give.

    Are you using 8-direction for the "knockback effect"? If so, you probably simulate movement. I'd look at how that is setup to make sure it doesn't keep simulating.

    Are you using a different movement behavior for this? I'm not sure using two movement behaviors at the same time is recommended, as I'd assume it could result in unexpected/unpredictable behavior. I'd recommend only having one enabled at a time (can switch between them by enabling one and disabling the other).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If newly created instances don't spawn with the default properties, that could probably be fixed with a bug report.

    Do you have any instances at all of that particular object that are placed in the layout editor that do have solids set as obstacles? It might be taking from that as the default instead.

    I figured it out based on your two comments - this object was in a different layout, that I hadn't been used recently, so I did not update the settings there as well.

    Once I either updated it or deleted it from that layout, it worked as expected!

    Thank you!

  • You can set default properties by having at least once instance of the sprite places in the layout editor, even if the layout is not used otherwise.

    I did have one instance in the layout but new instances created did not keep those same default properties.

    I figured out a workaround where I can put multiple instances in the layout, one for each container I will need, and they keep the default property. I assume that is because the container uses the existing ones, not creating new ones.

    Not ideal if I want to, for example, dynamically create/spawn enemies using line of sight. For this current situation, I only need a set amount so can continue with this workaround, for now.

    Good note that I can use a different layout, even if not used. I will test that as well.

  • I have a line of sight behavior setup using custom obstacles how I want it.

    New sprites created seem to default to using solids as obstacles. So even if I add the custom obstacles I want, this behavior still uses solids instead of my custom objects.

    There is no action to set the property to custom objects (instead of solids). And there is no expression to even check this.

    Is there a way to have a line of sight behavior created through events (so not in the layout in the editor) to use custom obstacles?

    A further detail in my project - this sprite with the line of sight behavior is in a container. Therefore, it is created via the container functionality.

  • Yes, the tech is all there - but they need to add support for running HTML5 games inside console apps so they can be distributed through the stores.

    Would the concept of how the NW.jS exports basically included chrome work here? Construct exports a console app which bundles a browser that runs the HTML5 game?

  • oh man, I missed these notifications. Thanks everyone!