JoeyTheChicken wrote:

That shouldn't be happening. Scratch works in much the same way. Can I see the script?

I'm just gonna start using the first quote since these messages will get huge otherwise :3

That is so much work, wow. I didn't even know you could generate saves, but I can now imagine you could.
And then converting between three lists into one and then doing it back the other way.
Well, what if I told you there was a way to do what I just suggested. I looked it up online and tried it out in my game. It works really well, but it's very.. hacky. Not too hard though, once you do it the first time, it involves editing the files on your desktop and the uploading the project.

GameArchitect wrote:

JoeyTheChicken wrote:

That shouldn't be happening. Scratch works in much the same way. Can I see the script?

I'm just gonna start using the first quote since these messages will get huge otherwise :3

That is so much work, wow. I didn't even know you could generate saves, but I can now imagine you could.
And then converting between three lists into one and then doing it back the other way.
Well, what if I told you there was a way to do what I just suggested. I looked it up online and tried it out in my game. It works really well, but it's very.. hacky. Not too hard though, once you do it the first time, it involves editing the files on your desktop and the uploading the project.

Yeah, editing the JSON files. I've heard of it. I almost mentioned it. But this way it's easier to save levels. It's as easy as defining the necessary coordinates and copying a save code :3 And I've never actually tried to edit the JSON files, but it could be a good experience.

JoeyTheChicken wrote:

That shouldn't be happening. Scratch works in much the same way. Can I see the script?

Ohh, that's what you were saying, now I get it.
Btw, I noticed I don't have access to cloud variables? I know I'm asking a lot of questions, but I'm still figuring out how everything works

GameArchitect wrote:

JoeyTheChicken wrote:

That shouldn't be happening. Scratch works in much the same way. Can I see the script?

Ohh, that's what you were saying, now I get it.
Btw, I noticed I don't have access to cloud variables? I know I'm asking a lot of questions, but I'm still figuring out how everything works

Haha :3 No problem. I come on here and help people out for a reason. You're still considered a “New Scratcher.” New Scratchers are barred from a few things, and Cloud variables are one of them. But it prevents bots and spam, so the rule's in place, I guess. You just have to share a few projects, leave some comments on others' projects and keep doing forum posts to prove you're not a bot account. Even then, I believe it has to be two weeks after the account was created. Kinda harsh, but I guess it's effective.

Hi @GameArchitect, just wanted to throw this out, even if it is not entirely relevant to what you are doing, it may at least be interesting. Scratch “forever” loops have an enforced minimum completion time of 0.033 seconds (when you are running with screen refresh), so the maximum frame rate is always going to be 30fps. Therefore in terms of game ticks it is worth working to the same timings.

My current technique is to effectively run the whole project from one “engine” sprite. This has the one forever loop which drives the project. Effectively it does all the processing and then does a single broadcast and wait to all the other sprites which handle the graphical output. I also time it, so if the screen update takes too long, it will start running multiple ticks of the engine before updating. That way the FPS drops but the speed of the project is maintained. Doing the scripting this way gives a lot more control as I've effectively serialised the program (and as pointed out Scratch is single-threaded anyway) so I know with confidence what is running when and in what order. The Descentipede (and Walkabout iirc) game in my sig uses this method as do the projects I am currently working on.

If that wasn't of interest, then apologies for the thread-jacking

Psiborg wrote:

Hi @GameArchitect, just wanted to throw this out, even if it is not entirely relevant to what you are doing, it may at least be interesting. Scratch “forever” loops have an enforced minimum completion time of 0.033 seconds (when you are running with screen refresh), so the maximum frame rate is always going to be 30fps. Therefore in terms of game ticks it is worth working to the same timings.

My current technique is to effectively run the whole project from one “engine” sprite. This has the one forever loop which drives the project. Effectively it does all the processing and then does a single broadcast and wait to all the other sprites which handle the graphical output. I also time it, so if the screen update takes too long, it will start running multiple ticks of the engine before updating. That way the FPS drops but the speed of the project is maintained. Doing the scripting this way gives a lot more control as I've effectively serialised the program (and as pointed out Scratch is single-threaded anyway) so I know with confidence what is running when and in what order. The Descentipede (and Walkabout iirc) game in my sig uses this method as do the projects I am currently working on.

If that wasn't of interest, then apologies for the thread-jacking

Oh, Psiborg! I've looked at your projects before. I really liked Walkabout :3 That's actually pretty amazing. I've never thought of such a thing–but of course I haven't. I see you around on the forums a lot. And if you jacked this thread, then you've brought far more experience than I have ;D

Psiborg wrote:

Hi @GameArchitect, just wanted to throw this out, even if it is not entirely relevant to what you are doing, it may at least be interesting. Scratch “forever” loops have an enforced minimum completion time of 0.033 seconds (when you are running with screen refresh), so the maximum frame rate is always going to be 30fps. Therefore in terms of game ticks it is worth working to the same timings.

My current technique is to effectively run the whole project from one “engine” sprite. This has the one forever loop which drives the project. Effectively it does all the processing and then does a single broadcast and wait to all the other sprites which handle the graphical output. I also time it, so if the screen update takes too long, it will start running multiple ticks of the engine before updating. That way the FPS drops but the speed of the project is maintained. Doing the scripting this way gives a lot more control as I've effectively serialised the program (and as pointed out Scratch is single-threaded anyway) so I know with confidence what is running when and in what order. The Descentipede (and Walkabout iirc) game in my sig uses this method as do the projects I am currently working on.

If that wasn't of interest, then apologies for the thread-jacking

No no, that was actually really interesting information!

Psiborg wrote:

Hi @GameArchitect, just wanted to throw this out, even if it is not entirely relevant to what you are doing, it may at least be interesting. Scratch “forever” loops have an enforced minimum completion time of 0.033 seconds (when you are running with screen refresh), so the maximum frame rate is always going to be 30fps. Therefore in terms of game ticks it is worth working to the same timings.

My current technique is to effectively run the whole project from one “engine” sprite. This has the one forever loop which drives the project. Effectively it does all the processing and then does a single broadcast and wait to all the other sprites which handle the graphical output. I also time it, so if the screen update takes too long, it will start running multiple ticks of the engine before updating. That way the FPS drops but the speed of the project is maintained. Doing the scripting this way gives a lot more control as I've effectively serialised the program (and as pointed out Scratch is single-threaded anyway) so I know with confidence what is running when and in what order. The Descentipede (and Walkabout iirc) game in my sig uses this method as do the projects I am currently working on.

If that wasn't of interest, then apologies for the thread-jacking

Oh wow, that's actually really enlightening. I wonder why they capped the forever loop though.
That would actually be really effective, I think I might take a look at that project.

Wow, that seed generator is awesome. The most I've ever done is a dungeon generator, but it doesn't have seeds to go with it. I guess a lot of thing really are possible in scratch, although they may require the occasional work around xD. I had to get used to the idea of only using sprites for all the code, cause naturally I'm used to (not trying to get too nerdy here) classes. So the idea of an engine sprite to handle everything sounds like something I should be doing.

GameArchitect wrote:

Oh wow, that's actually really enlightening. I wonder why they capped the forever loop though.

Also any loop which affects screen output has the same restriction. This is why we have the “without screen refresh” option - though there are a load of gotchas to look out for with those, such as don't “broadcast and wait”, don't delete clones etc. I suspect the reason for it is to do with the way Scratch tries to synchronise all the different loops across sprites.

GameArchitect wrote:

Wow, that seed generator is awesome. The most I've ever done is a dungeon generator, but it doesn't have seeds to go with it.

I can't claim any credit for the RNG script itself, that was borrowed from DadofMrLog and I just plugged it into my generator. I had lots of grand ideas for how I was going to use those seed generated islands, but I got bogged down by interface stuff and got bored. Was your dungeon generator for a roguelike or some other crawler?

GameArchitect wrote:

I had to get used to the idea of only using sprites for all the code, cause naturally I'm used to (not trying to get too nerdy here) classes. So the idea of an engine sprite to handle everything sounds like something I should be doing.

It took some getting used to for me too. I grew up with goto and gosub and since then I've only really used scripting languages and hence I'm now trying to squeeze Scratch into my procedural box.