fisholith's Recent Forum Activity

  • Is it possible to dynamically import all .js files found in a specified subfolder of the C3 project Scripts folder? I think this may work in Node, but in a browser it looks trickier, and might involve C3 scripting API use. Though I'm not sure getting a C3 project folder's file/contents list is supported in the C3 API.

    e.g.

    Suppose, within the C3 project "Scripts" folder, I create an "entity_definitions" folder. In that subfolder, I create several individual js files, each exporting an entity definition. Can I, at runtime, get a list of the files names in that folder, and dynamically import them?

    Motivation

    There are a variety of preset js-objects I want to define, and I'd like to organize these definitions as one definition per .js file.

    I want to collect these .js files in to packs of definitions that all reside in their own folder.

    Roughly speaking, I'll end up with some folders (e.g. "pack1", "pack2", "pack3"), each containing a bunch of little .js files.

    For flexibility and extensibility reasons, I would prefer not to have to hardcode the names of all these files directly into import statements in the game code. (Also kind of nice for modding.)

    My understanding of the Node context so far

    I think this should be possible in a Node context using the core "fs" module.

    That is, if I export for node, or use remote preview for Node, I think this is doable.

    My understanding of the Browser context so far

    However, in a browser context, the file-system is not directly accessible, so I think I'd need to use some C3 API feature to get access to files that were part of the C3 project file hierarchy. I'm pretty sure C3 provides a way to get single files by name, but I'm not sure about getting a list of file names from a C3 project folder.

    Some notes

    It's not a must that the final project work directly in a web browser, but it's a nice-to-have, and it would be convenient to use the default chrome-based preview, instead of remote preview. (Though I do very much appreciate that the remote preview in Node feature exists, as it may turn out to be a critical part of my work on this project.)

    Anyway, any thoughts or suggestions are welcome.

  • Thanks for the replies, R0J0hound and Oosyrag, :)

    What you both mentioned about a 2D world's data growing in memory at a much slower rate than a 3D volumetric one, and possibly fitting entirely in RAM for much longer is a really good point.

    And your caution about getting stuck in the pre-optimization weeds before it's actually solving a concrete problem is good advice, Oosyrag.

    Mainly, I just wanted to check with people more familiar with C3, that streaming to/from file wasn't ruled out by something I wasn't aware of. I figure at some point, an infinite world is going to have to go to disk, and even if it's a problem to solve much later on, I'm just at the engine scouting phase. So it's handy to have an idea of how much a given engine will be working for or against certain aspects of the project, before committing to one.

    It sounds like NW.js would be the way to go for file read/write stuff, which has been my experience with C2. I made a C2 color theme editor quite a while back, and it relied on the NW.js file facilities, though I don't recall if I could invoke a save/load without a prompt using the built-in NW.js C2 object. I could always code a plugin though, if the functionality is available somewhere in NW.js features.

    Anyway, thanks again for the info, R0J0hound and Oosyrag. :)

  • Given a tile-based procedurally generated world, in the vein of Minecraft or Terraria, is there a good way to save and load map data chunks to disk as needed?

    That is if a player travels East, new chunks are procedurally created ahead of them, and old chunks far behind them are saved to disk and unloaded from memory. Then when the player turns back and travels West, the chunks ahead of them to the West are reloaded from disk as needed.

    I know that the browser-based nature of C3 is likely to make this a bit tricky, because browsers don't have free reign to write files for security reasons.

    Ideally I'd be looking for desktop style behavior, where the game stores map data essentially the same way Minecraft does.

    e.g. Loosely speaking, Minecraft streams map chunck data to and from a local folder, which differs slightly by platform.

    • Win: %appdata%\.minecraft
    • Mac: ~/Library/Application Support/minecraft
    • Linux: /home/USERNAME/.minecraft/

    Another benefit of this desktop-style behavior, is that world data stored in the folder isn't vulnerable to erasure by clearing local browser data.

    I'm not sure what the best approach would be, but my initial impression is that this would require exporting for NW.js in order to take advantage of the more desktop-like context NW.js operates in.

    Would an NW.js exported application allow saving and loading of map data, without prompting the user for a save location for each chunk file? I figure that prompting multiple chunk file saves every few blocks would slightly encroach on the spirit of exploration. :)

    I'm not familiar with the nuances of C3, but my experience with the prior incarnations of Construct so far, is that just about anything is possible, with enough insight.

    If there's a better approach, or if it's genuinely not doable, or simply not something that C3 is a good fit for, any thoughts or suggestions are welcome. :)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Thanks Wisdoms. :)

  • Hey Ashley, :)

    Hope you're doing well. I don't know if you remember me, but quite a while back I used to spend a lot of time writing up tutorials and answers to user questions for Construct 1 and 2 in the forums. I've talked with you a few times here and there.

    I just got my C2-based game funded on Kickstarter, and it's still climbing past the original funding goal, and I wanted to thank you and the rest of the Scirra team.

    It's not an exaggeration to say that my dream is becoming real because of you. So thank you, Ashley. :)

    I posted about my game in the "Your Construct 2 Creations" forum, though I know most traffic has likely moved to C3 at this point.

    I would like to share the game with the wider Construct community, but I'm not sure if there's a good place to do that. If you have any advice or suggestions, I'm all ears. No worries if not though.

    This is the post I just made in the "Your Construct 2 Creations" forum.

    Down Ward - an Owl Flight Platformer

    Thanks again, and best wishes for the continued success and growth of Construct 3. I'm looking forward to getting familiar with it in the future. :)

  • Hi all,

    I've been working solo on Down Ward for a few years now, and regularly updating a free version. The game follows Gable, a little owl, exploring her way through overgrown ruins.

    Subscribe to Construct videos now

    The game is on Steam and Game Jolt at the moment.

    Down Ward - Play/Download

    If you're interested, I'm currently running a Kickstarter that will end a few hours after Thursday (April 29th).

    Just for fun, a pixel Portrait of Gable. :)

  • Thanks , much appreciated . :)

  • Hi all,

    I've been working on a C2 game for a while now, called "Down Ward"

    You play as Gable, a little owl, as she sets out to rekindle the dormant relics of a land long abandoned to ruin.

    A video:

    Subscribe to Construct videos now

    Some gifs:

    i.imgur.com/ECoLvnr.gifv

    i.imgur.com/fSq4zfA.gifv

    i.imgur.com/5VQXadf.gifv

    The game:

    Down Ward - Play/Download

    If you're interested I also launched a Kickstarter,

    Down Ward - Kickstarter

    (Please let me know if posting a Kickstarter link in this forum is a problem, I don't want to be breaking any rules.)

  • Down Ward

    Gable, flutters her way through a leafy alcove. :)

  • Okay, just posted a bug report, as per your suggestion.

    Thanks again for helping me look into this Ashley. You're the best. :)

  • Problem Description

    Overview

    In r262 and earlier, Crop mode behaves as expected, but from r263 and onward Crop mode behaves quite strangely in fullscreen, at least on my computer.

    It seems like in r262, "Centered" and "Crop" both act like a "Crop"; and in r263, "Centered" and "Crop" both act like a "Centered".

    (See below for screenshots of the effects described.)

    Details - r262 and before

    In r262 and earlier, the action Browser > "Request fullscreen - Stretch (crop)" mode did no scaling of the game visuals when the window size changed or went full screen. Instead the game visuals stayed at a fixed scale, and the changing size and shape of the window would simply reveal more or less of the layout.

    Also in r262, the action "Request fullscreen - Centered" seemed to produce exactly the same effect as the "Stretch (crop)" action. Though if I understand correctly this was not how "Centered" was intended to work.

    Details - r263 and after - (Where the possible bug began to appear)

    In r263 the fullscreen "Centered" mode was updated to behave as originally intended, such that the game would be rendered unstretched in an "Original Window" sized rectangular area in the center of the monitor, and the surrounding area would be filled solid black.

    However an unintentional change may have also occurred in r263, as now the action Browser > "Request fullscreen - Stretch (crop)" also started behaving like the newly updated "Centered" mode.

    So the "Stretch (crop)" action no longer fills the screen with the unstretched game, but instead restricts it to render only in an "Original Window" sized rectangle surrounded by solid black.

    Additionally, when in fullscreen Crop mode, the System object's WindowWidth and WindowHeight expressions return the width & height of only the "Original Window" sized rendered area.

    (Conversely, when in fullscreen Crop mode in r262, the WindowWidth and WindowHeight expressions would return the dimensions of the current screen resolution, as the game would fill the entire screen.)

    Attach a Capx

    https://www.dropbox.com/s/azvikt5jc23j2kf/r262%20r263%20Crop%20mode.capx?dl=1

    Description of Capx

    This capx makes it easier to test out what I describe above.

    It demonstrates the Browser action "Request fullscreen - Stretch (crop)".

    Controls:

    Mouse:

    Left Mouse = Fullscreen.

    Right Mouse = Exit Fullscreen.

    Middle Mouse = Exit Game.

    Arrows: Move player / camera.

    Images of the capx:

    r262 Windowed, just for reference:

    r262 Normal fullscreen Crop behavior:

    r263 Strange fullscreen Crop behavior:

    Steps to Reproduce Bug

    Run the capx.

    Left click in the game.

    Observed Result

    r263 Strange fullscreen Crop behavior:

    (Note that the updated "Centered" mode in r263 looks identical to this new behavior.)

    Notice that the WindowWidth and WindowHeight readouts are showing the values of the default original window size.

    Expected Result

    r262 Normal fullscreen Crop behavior:

    (Note that in r262 "Centered" mode looks identical to this.)

    Affected Browsers

    • NW.js: YES
    • Chrome: YES
    • FireFox: YES
    • Opera: YES
    • Iron: YES
    • Internet Explorer: (Doesn't go fullscreen at all, probably because IE is IE.)

    Operating System and Service Pack

    Win7 x64 - Pro

    SP1

    Construct 2 Version ID

    Release 265 (64-bit)

    Built at 17:20:47 on Oct 15 2018

    265 Release Notes

  • Thanks for the quick reply! :)

    So I just tried changing the action from,

    "Request fullscreen - Centered"

    to,

    "Request fullscreen - Stretch (crop)"

    (Looks like this now)

    (Tried posting the image several times but it doesn't show up, so linking instead.)

    i.imgur.com/nLuE9q1.png

    but I get exactly the same issue, an original-window-sized rendered area with solid black fill out to the edges of the monitor.

    I got this testing in both r263 & r265 just now.

    After that, I rolled back to r262, to see how the "Stretch (crop)" would work there, and I get the behavior I'm used to, where the game fills the screen.

    So it looks like the fullscreen actions "Centered" and "Stretch (crop)" both do the same thing, at least on my computer. In r262 they both make the game fill the screen, and in r263, they both make the game stay window sized and black-fill the rest of the monitor.

    I tested in NW, Firefox, Chrome, and Iron. I also tried disabling my second monitor and re-testing, just in case that was somehow involved, but there was no difference when using 1 monitor or 2 monitors.

    Updated capx:

    I updated the capx to use the "Stretch (crop)" action:

    dropbox.com/s/wn1h3d2lqwcvwbh/r262%20r263%20Crop%20mode.capx

    Just noticed something:

    Is the "Centered" action actually supposed to do the centered window and black fill that I'm seeing in r263? That would make sense going by its name. The problem I'm running into is that "Stretch (crop)" is also doing the same thing in r263.

    It seems like in r262, "Centered" and "Crop" both act like a "Crop"; and in r263, "Centered" and "Crop" both act like a "Centered".

    Is it possible that's what's going on?

    I could also be overlooking something, so I don't want to get ahead of myself.

    Is there anything else you can think of that might be worth testing?

fisholith's avatar

fisholith

Member since 8 Aug, 2009

Twitter
fisholith has 2 followers

Connect with fisholith

Trophy Case

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

19/44
How to earn trophies