GlovePIE looks interesting, though the political messages about green energy and all that make me not really want to download it.
Lars Ulrich is a douche. Doesn't mean you shouldn't listen to Metallica :p
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.
Oh, nice.
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).
I still can't get it working. I'd really prefer to use it, especially so as I write my newbie guide, I can have directions for the vanilla editor and Sphere Studio.
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.
A ground-up Sphere rewrite by Radnen, you say?
In all seriousness, you should create an exhaustive list of API features you'd like to see added/modified. If nothing else, then for something to think about. Since I'm just beginning (re-beginning, technically), the only major things that're obvious to me that I'd like to see different in the API is multiplayer support, including multiple AttachInputs (for at least four players) and being able to load multiple maps simultaneously (so when playing online with others, you don't all always have to be on the same map).
Since multiplayer gaming is so popular, I think those would be massive boons for Sphere. Though the web-based implementation Radnen (and others?) are currently working on is definitely the best starting place. I can't wait 'til that's finished.
Actually, ooh! Rad, you said it'd be at least a year, right? It should probably take me that long to get something playable churned out. That'll be a happy coincidence.
(Also, since I didn't find it until 2009/2010, I didn't know Sphere was old. How old we talking?)
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.
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.
I wouldn't use SetDefaultMapScript since it'll play each time a map is changed. I'd use:
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.
Woo hoo! That worked! Radnen, you rock. I'm gonna try to see what I can accomplish on my own for a few days. First of all, your demo script doesn't allow diagonal movement -- the characters can only move one, cardinal direction at a time. Secondly, it'd obviously be preferable to have an event handler for all the input rather than hard-coding it.
This is where I excel -- taking working code and tweaking it to my needs.
Thanks again ^_^
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?
Heh, I wonder if we could do what Nintendo did with the SNES Multitap. It doesn't actually add third and fourth player code or functionality. What it does is rapidly switch what the console is interpreting as players 1 and 2 between the first two controllers plugged in, and the second two plugged in. So controller 3 is actually reporting as controller 1, and controller 4 is reporting as controller 2, just at different times than the proper controllers are.
Which is why a game has to be programmed specifically to use the Multitap, 'cause the game code has to be written to interpret player 1/2 and player 3/4 input at different times.
...
Actually, that sounds like a pretty awesome, totally-doable way to do multiplayer in Sphere. Kinda like how biplanes with machineguns had little stoppers to make sure the bullets only fired when the propellers weren't in the way, someone (not me, not good enough yet) could write code that AttachInputs to one player on millisecond 1, 5, 9, 13, etc.; to a second player on milliseconds 2, 6, 10, 14, etc.; a third player; a fourth player.
That way, everyone can use the useful, pre-programmed AttachInput and get its full functionality (triggers, NPCs).