Community for the Sphere game engine

New? Contact Us to register an account!

GlovePIE looks interesting, though the political messages about green energy and all that make me not really want to download it.

Quote

Actually, I thought of having 16 x 16 sprites, but actually making them 16 x 32, but only drawing the sprite as 16 x 16 pixels on the lower half of the sprite area, and having the hitbox only be in that area, and using the top half for expression bubbles, like question marks and exclamation points.

There's absolutely no need to do that! Just make your sprite normally, and have your text balloon as a separate spriteset that you show at the appropriate times with CreatePerson(). This will save you a lot of hassle as you don't have to consider every single character/animation/balloon combination.

Quote

I think the main point of confusion is that it's simply not clear at all that the sprite window at the right is part of the process of making a Spriteset.

Agreed; it's not intuitive and causes confusion for pretty much everyone the first time around. I think Radnen's editor does it better (not sure; haven't been able to check it in a while).

Quote

Oh, it's just 'cause I'm such a novice programmer. If I were experienced, I'd easily be able to do anything I want (I mean, Sphere uses Javascript -- look at all the stuff people do with that). It's just, for now, I have to rely so much on built-in functionality of the IDEs I use that if there's not something there, if I have to resort to doing something on my own, I have to find a workaround.

Look, it's not just you being a novice here. I've used Sphere for a long time, and I can find plenty of faults in the API. Some things just aren't intuitive, and ultimately, they really ought to be. Then again, some of the design decisions are pretty outdated (Sphere is OLD!) and could definitely be replaced by much better solutions at this point. All that said, there's a lot I do like about Sphere's API.

Quote

But won't using a for-loop lock up the system?

Why would it? That loop finishes as soon as it's iterated through the entire players array... Only loops that have some condition that can never become false would make the engine get stuck.

I wouldn't use SetDefaultMapScript since it'll play each time a map is changed. I'd use:

Code: (javascript) [Select]

QueuePersonScript("player1", "code();", true);

// ...

function code() {
    SetPersonXYFloat("player1", x, y);
    SetPersonXYFloat("player2", x, y);
    SetPersonXYFloat("player3", x, y);
    SetPersonXYFloat("player4", x, y);
}

The above is just an example you'll need to set the xy's and make sure to put the QueuePersonScript after you create the person but before you call MapEngine(), and put the code() function (which you can rename to anything) somewhere else in the code file.

There used to be an old multiplayer demo of Bomberman for Sphere that may or may not still be useful for learning multiplayer basics with AttachInput. Somebody here still have that?

A ground-up Sphere rewrite by Radnen, you say?

(Also, since I didn't find it until 2009/2010, I didn't know Sphere was old. How old we talking?)

Before the site relaunch, when I first joined the old Sphere forum, I was trying to make Chrono Trigger-style text boxes where you could walk around while they type out the text, and I used a for-loop and it froze player input until the text finished typing.

It would probably be a lot easier to just manhandle the Map Engine and manually set Person positions, check for obstructions, and such. I used to do that sort of thing a lot, even for single player games.

Quote

A ground-up Sphere rewrite by Radnen, you say?

He's doing that; it's called Sphere-SFML. And Flying Jester is writing TurboSphere. Both are pretty promising (and FJ's thing is cross-platform).

Quote

(Also, since I didn't find it until 2009/2010, I didn't know Sphere was old. How old we talking?)

It's been around since a bit before 2000, I believe. Also the reason there's reimplementations being made right now; current Sphere with its old engine and editor has a bunch of different issues (some of which being outdated libraries that don't get updated any more).

Quote

Before the site relaunch, when I first joined the old Sphere forum, I was trying to make Chrono Trigger-style text boxes where you could walk around while they type out the text, and I used a for-loop and it froze player input until the text finished typing.

Ah, I see. It does freeze player input since it's a loop and you're not explicitly checking for any input in that loop, so that's something you'd have to implement yourself when desirable. In this case, though, the loop takes shorter than even a single frame, so...

Quote from: Flying Jester – on December 03, 2013, 07:10:19 am

It would probably be a lot easier to just manhandle the Map Engine and manually set Person positions, check for obstructions, and such. I used to do that sort of thing a lot, even for single player games.

Manually setting Person positions is fine. Manually checking for obstructions? Way beyond me. Besides, what would be the point in using the Map Engine at all if not for its default collision detection?

Quote from: DaVince – on December 03, 2013, 07:14:29 am

Quote

A ground-up Sphere rewrite by Radnen, you say?

He's doing that; it's called Sphere-SFML. And Flying Jester is writing TurboSphere. Both are pretty promising (and FJ's thing is cross-platform).

Oh! I thought Sphere-SFML was merely a thing to make your Sphere games run in a browser, I didn't know it was totally recoding. Will games made with the old Sphere run in SFML (need a catchier name there, Rad) or TurboSphere?

Quick Question
Is function game() the actual game loop for a Sphere game, or would I have to make my own game loop with Javascript? I'm guessing it's not a loop, since in Radnen's sample code, the CreatePerson commands don't happen over and over again, they only happen once.
...
Or do they keep happening? Are they being called every time function game() loops?

Quote from: DaVince – on December 03, 2013, 07:14:29 am

Quote

A ground-up Sphere rewrite by Radnen, you say?

He's doing that; it's called Sphere-SFML. And Flying Jester is writing TurboSphere. Both are pretty promising (and FJ's thing is cross-platform).

Oh! I thought Sphere-SFML was merely a thing to make your Sphere games run in a browser, I didn't know it was totally recoding. Will games made with the old Sphere run in SFML (need a catchier name there, Rad) or TurboSphere?

The function game() occurs once, MapEngine() is what keeps the game running after that, if you want it to loop you'd need game() to call itself at the end.

The function game() occurs once, MapEngine() is what keeps the game running after that, if you want it to loop you'd need game() to call itself at the end.

Quote from: Mooch – on December 03, 2013, 11:52:17 pm

Quote from: Flying Jester – on December 03, 2013, 07:10:19 am

It would probably be a lot easier to just manhandle the Map Engine and manually set Person positions, check for obstructions, and such. I used to do that sort of thing a lot, even for single player games.

Manually setting Person positions is fine. Manually checking for obstructions? Way beyond me. Besides, what would be the point in using the Map Engine at all if not for its default collision detection?

You can ask the map engine if things are/would be obstructed.

Quote from: Mooch – on December 03, 2013, 11:52:17 pm

Quote from: DaVince – on December 03, 2013, 07:14:29 am

Quote

A ground-up Sphere rewrite by Radnen, you say?

He's doing that; it's called Sphere-SFML. And Flying Jester is writing TurboSphere. Both are pretty promising (and FJ's thing is cross-platform).

Oh! I thought Sphere-SFML was merely a thing to make your Sphere games run in a browser, I didn't know it was totally recoding. Will games made with the old Sphere run in SFML (need a catchier name there, Rad) or TurboSphere?

You need to make minor changes for your Sphere 1.x game to work in TurboSphere. Sphere's objects aren't set up in a JavaScripty way. For instance, in Sphere 1.x:

Code: [Select]

var Red = CreateColor(255, 0, 0);

In TurboSphere:

Code: [Select]

var Red = new Color(255, 0, 0);

Or more interestingly:

Code: [Select]

var Picture = LoadSurface("pic.tga");
var Surf = CreateSurface(16, 16, Red);

TurboSphere overloads constructors:

Code: [Select]

var Picture = new Surface("pic.tga");
var Surf = new Surface(16, 16, Red);

I have tried, and it is pretty easy to write scripts to adapt the TurboSphere to run Sphere 1.x code.

But I rather prefer the more constructor-y way.

Quote from: Mooch – on December 03, 2013, 11:52:17 pm

Quick Question
Is function game() the actual game loop for a Sphere game, or would I have to make my own game loop with Javascript? I'm guessing it's not a loop, since in Radnen's sample code, the CreatePerson commands don't happen over and over again, they only happen once.
...
Or do they keep happening? Are they being called every time function game() loops?

I'd recommend putting a game loop inside gam(). I wouldn't recommend recursing game. You will quickly run into errors about being too deeply recursed. Plus...it would be kind of weird.

Quote from: Mooch – on December 03, 2013, 11:52:17 pm

Quote from: DaVince – on December 03, 2013, 07:14:29 am

Quote

A ground-up Sphere rewrite by Radnen, you say?

He's doing that; it's called Sphere-SFML. And Flying Jester is writing TurboSphere. Both are pretty promising (and FJ's thing is cross-platform).

Oh! I thought Sphere-SFML was merely a thing to make your Sphere games run in a browser, I didn't know it was totally recoding. Will games made with the old Sphere run in SFML (need a catchier name there, Rad) or TurboSphere?

You should be able to drop in any old Sphere game and it should just work. But of course, there are problems since I'm not finished yet. It seems to handle newer Sphere v1.5+ games better than the old ones (they just simply crash sometimes). :/ (I think it might be in the dataformats, I only support the latest spriteset, windowstyle, formats etc. That said the new formats are pretty much unchanged since the Sphere 1.* days. So only really old games wouldn't work).

Quote from: mezzoEmrys – on December 04, 2013, 12:01:27 am

The function game() occurs once, MapEngine() is what keeps the game running after that, if you want it to loop you'd need game() to call itself at the end.

Yeah, game() occurs only one, but MapEngine() isn't what keeps the game running after that. That's only the case if you actually run the map engine, but if you create any old loop yourself, that will be what keeps the game running instead. Plenty of non-map engine Sphere games do this!

Quote from: DaVince – on December 04, 2013, 08:51:39 am

Quote from: mezzoEmrys – on December 04, 2013, 12:01:27 am

The function game() occurs once, MapEngine() is what keeps the game running after that, if you want it to loop you'd need game() to call itself at the end.

Yeah, game() occurs only one, but MapEngine() isn't what keeps the game running after that. That's only the case if you actually run the map engine, but if you create any old loop yourself, that will be what keeps the game running instead. Plenty of non-map engine Sphere games do this!

Well, even if you are using the Map Engine, you need your own game loop, don't you? I mean, I suppose ultra-simplistic games might not need a loop, but I can't imagine say, a platformer or an RPG that doesn't have a game loop constantly running certain kinds of code.

Ah. Found out on my own. I tried using addEventListener and it says it's not defined. Unless I just have to use EvaluateScript, but I have no idea what *.js file addEventListener is in, or where or how to obtain it.

Sweet! So tell me something -- when Sphere, any ol' version of Sphere, is running, is it actually running the code of the game as Javascript, or is it converting it into something else before its run?

It depends how you structure it. You can very easily just leave the map engine running the whole time your game runs.

Mostly, you absolutely need a game loop (and not a recursive game function! Don't do that!) if you don't use the map engine in your game, or choose to use it for portions but also close it from time to time and then run it again later.

Quote from: mooch

Ah. Found out on my own. I tried using addEventListener and it says it's not defined. Unless I just have to use EvaluateScript, but I have no idea what *.js file addEventListener is in, or where or how to obtain it.

What's addEventListener? It sounds more like Java's awt event library to me; not JavaScript.

MapEngine() is a function, so it calls some code. What it calls is something with a while(true) loop in it. That loop is what runs forever and why it doesn't quit. The Map Engine looks something like this, at it's very basic core:

Code: (javascript) [Select]

function MapEngine(file, rate) {
    ChangeMap(file);
    SetFrameRate(rate);
    while (true) {
        UpdateMapEngine();
        CallUpdateScript();
        RenderMap();
        CallRenderScript();
        FlipScreen();
    }
}

So when you call:

Code: (javascript) [Select]

function game()
{
    // ... work ...

    MapEngine("file.rmp", 60);
}

Just know it goes into another loop that runs the correct code. So in order for it to do anything while the map engine is running you will have to se the update and render scripts. Now, in a better MapEngine than I showed you (the one Sphere uses) the RenderScript will run at the framerate, and so is ideal for your drawing operations - they will also be drawn above the map and they will be drawn at the framerate desired. Update scripts on the other hand run as fast as they can, and if you were to do any drawing in them; it'll be drawn below the MapEngine.

Now you know Sphere's MapEngine.

Quote from: mooch

Sweet! So tell me something -- when Sphere, any ol' version of Sphere, is running, is it actually running the code of the game as Javascript, or is it converting it into something else before its run?

In the Sphere 1.* engines the code is actually interpreted by the underlying JavaScript engine, so it's just running it. Now, in my SphereSFML, the code is instead compiled to .NET code, so it's quite fast (so it's turning it into something else). TurboSphere on the other hand uses v8 JavaScript and also compiles it, but to assembly and so is faster still, plus it has many keen optimizations in place (because Google is awesome). But the differences in code execution between the two aren't much since graphics are your major bottleneck. /rant

addEventListener is not a part of Sphere's JS--but it is used in web JS (something of the same name exists in Java too, I think). But that's web JS, for web browsers. It's part of the DOM (the API that the layout engine exposes...but we have a Sphere, not a layout engine).

What exactly are you trying to do with it?

Two quick questions...
1) Can I access the player's X and Y without using GetPlayerX/Y? Since it's a function, it's inconvenient to use nested deep in my code. I'd prefer to just do player.x and player.y.

If I just did "player.x = GetPlayerX(blah)" would that work?

Quote from: Flying Jester – on December 06, 2013, 02:20:11 am

It depends how you structure it. You can very easily just leave the map engine running the whole time your game runs.

Mostly, you absolutely need a game loop (and not a recursive game function! Don't do that!) if you don't use the map engine in your game, or choose to use it for portions but also close it from time to time and then run it again later.

Not sure I understand, but then again, I don't really understand how the Map Engine works. Though I get that if you were making, say, an RPG, you could turn off the ME while the player's in battle. Though I can't see what'd be wrong with leaving it running in the background. The computers we're all using are probably plenty powerful enough that that little bit of wasted computing won't cause a noticable slowdown.

I see my problem. I'm thinking in terms of something like BASIC, where the program runs one line of code after another, from the top of the code to the bottom, and only does any looping if you tell it to jump back up in the code. I forgot you can while(true) something and have it keep going while you're doing other things.