This whole approach seems like something that would be better suited as a plugin, rather than a native part of Construct. Look at Unity for example, there are some excellent node-based plugins for story development. In my own experience with building a narrative-based game in Unity, these are great for managing high-level chunks of conversations, but get laborious to use for every single line of dialogue.

Not sure if you read the first part of my previous response, but you could implement a similar hierarchy-based system to manage whole conversations, and then write the dialogue lines in JSON. That way you're using small, segmented JSON files that might be easier to manage.

You could also write your story in other software like inklewriter/Twine/etc., and export to JSON (might need a third-party plugin). From there you'll need to build systems to interpret and play back that data to the user.

Regardless of the method you choose to manage and write your story, you're going to need to unpack that data and display it to the user somehow, and that's going to require some serious legwork.

I prototyped an idea I had about this a while ago, unfortunately I lost my file so I can't share it here. But the basic idea is to have a layout per scene, and each layout has a series of parented text boxes with properties like "Actor", "Animation", "BGimage", etc. The actual dialogue is sourced from the text box's text, which uses custom tags to take the user to the relevant text box and/or perform defined actions.

Dialogue flows up or down the heirachy chain depending on defined interactions. It worked okay; definitely requires some effort to build but it's a system that could no-doubt be built to do what you need.

IMO, you're better off building a branching dialogue system using JSON. Similar approaches have been the standard for dialogue-driven interactions in games since such things existed, and only in more recent years have node-based approaches taken off. It's also much easier to translate file-based than node-based dialogue.

I suggest you check out Laura_D's tutorial series on implementing a JSON-based dialogue system: construct.net/en/tutorials/introduction-json-dialogue-2331

You say in your facebook post that you're not using drag and drop for the basket's movement (which would cause the issues as expected), but how are you moving it? Can you share your events?

For super-fast movements like this, "Bullet" should be checked in the object's properties.

You've got the answer right there - use for each object.

My pleasure! I think it's important to highlight different approaches to game development - we're not all in a position to be indies :D

1) They do ask about the dev platforms, but it's usually just for their own frame of reference. I have had to convince clients to accept that I'm not a "traditional" dev, but all it takes is showing them what I've built in Construct (and how quickly) to convince them that it's a viable platform. Most of my clients want browser-based and/or mobile-friendly, so Construct is perfect.

2) I work with a software dev company that handles most of the personnel management, but I do occasionally hire directly for personal projects.

3) This depends on the product. For the most part I work within their framework, be that an app or website. Some clients don't want to get involved in the "publishing" side of things; in that case I recommend a web-based release and handle the hosting on their behalf.

There are plenty of tutorials and forum posts about optimizing performance, but with 40k sprites you're going to have to do a lot to keep the game running smooth. Disable any behaviours on objects which don't need them all the time. Creating/destroying puts a fair bit of strain on the CPU, too, so look into object pooling if you're doing that often. Use render cells where possible.

It's also worth looking into alternative ways of rendering the sprites, like with tiled backgrounds or tilemaps instead of sprites.

More than anything, make sure that you're testing everything that you do. Set up a benchmark with a target FPS, and make adjustments based on evidence. Every project is unique, so there's no real one-size-fits-all solution.

It would probably be more memory-efficient to use a single sprite font object for everything, but that isn't always practical, either technically or in terms of workflow.

But if you do want to, assign each object a local variable that acts as a unique identifier ("textID"), like "playerScore" or "currentLevel". Create a single function that is used to change the text objects as needed. Give it a parameter "textID" and then use that to pick which object to change, and set its text/colour/whatever using more parameters as needed.

That's how I do it, at least. But I often end up needing multiple text objects regardless. As I say it's not always practical to use a single object.

I've been using Construct for about 8 years, the last 3 of which I've been using it full-time. I'd love to say that I have a ton of published games that generate a passive income, but that's not the case.

I work predominately on corporate games - making games for companies to market their products. Any extra revenue is used to buy time to work on my own games.

Here are my answers in your format:

1: Games and apps, with the occasional website.

2: Yes. I work with a team of artists and other devs who provide the graphics/audio/etc., and backend support I need to integrate with corporate systems (customer loyalty, tracking, rewards).

3: I don't! That's the one really nice thing about doing corporate work - they already have the audience :)

4: It's a range of products. I'm usually juggling at least 3 at any one time.

5: I put in at least 40 hours a week. I'm not one for overworking myself anymore. Burnout is real!

6: Start small and never stop networking. Build a reputation while you're building your skills. Don't over-promise, but don't hesitate to challenge yourself.

My biggest piece of advice is to find other people who are good at the things you aren't good at. For example, I suck at business stuff, but I have some wonderful colleagues who are excellent in that field. Without them I don't think I'd be able to do this full-time.

The problem with dragging from the project explorer is it will always take the first instance as the "reference instance". Since Construct doesn't have a typical implementation of prefabs, you need to kind of create your own. Using a separate layout for any object's initial state is the only real way around this limitation.

All of my projects use a layout I call "Parking Lot", which I treat as a prefab explorer. It's not ideal, but honestly it works fine once you get your head around the way Construct instantiates objects.

Any time you copy an object instance, it will use the same properties/values/everything as the starting point for the new instance.

Easiest solution is to just copy a blank instance of the tilemap, rather than the populated instance from your game layout.

I suggest you make a "prefabs" layout with no event sheet. Stick all of your objects there and just take copies from there. This gives you a central location from where all your initalised objects can be taken.

Ah, Thanks! I'm still trying to get my head around Spine's terminology, this is a big help :)

For sure, you could use the same approach to spawn tiled backgrounds or 9-patches. Set their angle however you'd like, and use raycasting to determine their length.

I suggest you also play around with some effects to find one that fits the lighting style you want. Without seeing more of your project, it's difficult to tell exactly what logic is causing problems.