Scratch

I'll go with LGPL, in that case. (I should probably consult a lawyer, though...)

EDIT: I think GPL is actually better, now that I read the choose a license page.

Last edited by bobbybee (2012-03-22 16:00:08)

bobbybee wrote:

Magnie, I'm working on the Scratch-part. Do you have any suggestions regarding cloning (to support many users in a single room)? After all, you're working on Virtual Space and all.

For games, cloning won't be possible. With a decent speed that is.

For VS I'm limiting each "universe" to 12 players (so 12 sprites for each ship, not counting weapons, planets, etc), but it can support as many universes as the computer/server can handle.

bump. Like the new tutorial?

bobbybee wrote:

bobbybee wrote:

I guess I'll try limiting my rooms. (I'm doing more club-penguin like game, so it would be everyone crammed in the same "universe") If you know a private file sharing site, I can should you something rather ambitious I'm working on (don't want to unveil my secrets 'till they're fully ready)...

I'm beginning work on rooms. So far, so good.

Cheers! Can't wait to see the finished result!

bobbybee wrote:

It's kinda cool. Do you have any advice regarding optimizations? I'm doing some tests and the Scratch-side is slower than erm...heck. Specifically my string handling routines are slow. (the mirror/server-side are definitely fine)

Yeah, I think you see my problem with Virtual Space now. 

I suggest doing something like this:

Scratch sends an update request
Server sends all the sensor-values then server sends a broadcast "updated"
Scratch receives "updated" and tells all the sprites to update to their new positions.
Then after Scratch is done updating, it restarts the process.

If you can make that any shorter, that would be amazing. Also, having the server continually update Scratch with sensor-values won't work very well. You need to somehow regulate the "Update" and "Updated". Continually sending "Update" won't work, at least, not very well.

For Virtual Space, I send "Update" then the server replies "Updated" and all the sprites receive "Updated" and then update all their positions. So if the server stops sending broadcasts, then it will stop running until it receives "Updated".

But as I said earlier, if you can find a more efficient or faster way, that would be great!

bobbybee wrote:

As you complained about on your article about why Scratch Live is bad, you should trade-off recognition for speed. In my case, I'm doing everything from collision-detection to high-scores on the server. Perhaps I might implement a mirror protocol that would do the string manipulation directly (before contacting Scratch, of course.)

That's exactly what I'm doing. I'm doing everything on the server and Scratch just displays the positions and directions of the players, and eventually, the type of ship. Even then, it's really slow (updates about every half-second). Which is why I'm still looking for a faster method.

Using variables might work, but it isn't what I really want to use. Though I think I'll just wait for Scratch 2.0. 

Last edited by Magnie (2012-03-23 21:26:17)

bobbybee wrote:

I haven't tested turbo, though...maybe I'll make a flash player hack for it.

Yes, please make a Flash Player hack! 

Magnie wrote:

bobbybee wrote:

I haven't tested turbo, though...maybe I'll make a flash player hack for it.

Yes, please make a Flash Player hack! 

I found an Adobe product that should let me do everything...and it's open-source.

peterkap wrote:

Im going to use this for my own virtual world, PonderMe. (Official Website here
I need some help. 1) How do you get packet to appear on the sensor values?

You need to run both the server and the mirror at the same time.

bobbybee wrote:

Magnie, I dunno if you've seen this bug before, but I seem to have some issues when 2 packets get sent to the client at once. It seems to only parse the second (last) packet.

Another problem I've had to deal with. 

When the same broadcast is sent twice, the second one will override the first one. Try making a "When I Receive" script and put a forever loop on it. Start the script once, then start is again. It will stop the script then start it again.

That's what happens when you send two broadcasts at once. You'll need to regulate the script to only send the broadcast once the original one finishes. I've done a script like this:

when gf clicked
broadcast [Updated v] // Then the server sends all the sensor-values and then broadcasts "Update"

when I receive [Update v]
broadcast [New Update v] and wait
broadcast [Updated v]

when I receive [New Update v]
go to x:<[p1x v] sensor value> y:<[p1y v] sensor value>

bobbybee wrote:

Wouldn't when I receive Update be called twice, and be overrided?

If you send two Update broadcasts at once, then yes. But I don't see why you would.

bump

Wut?