Um. I don't see why you wouldn't be able to control four characters at the same time from a single keyboard. Yes, they all come from the same single command queue, but you're pressing different keys for different characters so it's not really an issue. Heck, even several keyboards would work, as long as you set up different keys for different players. Adding controller support for this would also not be difficult.
That was actually my plan; I was gonna design this for use with game controllers. I was gonna have the 1, 2, 3, 4, 5, 6, 7 and 8 keyboard keys be used as Up, Down, Left, Right, B, A, Select, Start for Player 1, and q through i for Player 2, and a through k for Player 3, and z through , for Player 4.
Linerally like that so you can easily hook the corresponding commands up to the different game controllers you have plugged in.
The main hurdle with having four people on the same keyboard, though, is that most keyboard seem to have a hardware limitation where you can only press 4 to 5 keys at the same time. If you press more keys than that, they're just not sent to the system at all (so this is a problem for any software, any OS, etc). Having multiple keyboards or gamepads could solve this, easy.
No need -- just use a keyboard emulation program like GlovePIE. Indeed, I wanted to specifically design this for use with GlovePIE and Wiimotes. It's a fantastic program, you should take a look at it.
2) When I edit or paste an image into one frame of one direction, it edits or pastes it into all the frames for every direction!
Well there are two views in the spriteset editor, which I guess makes it a bit confusing to first use. There is the direction view and the tileset view. You want to do the manipulations in the tileset view and then change the frames in the direction view. The reason why you see the frames automatically update is because they are all tied to the same graphic in the tileset. Once you realize the tileset graphic and the direction frames are linked then you just create new images for the new frames and go on from there.
Oh! I see. Man, that is NOT made clear anywhere. I know -- I'm gonna make a newbie-friendly tutorial and slap it up on the Wiki as I go along and learn things. That way, nobody else will have to scratch their heads at this stuff, we can just point 'em to my tut.
If it helps, I made a (bit too fast) video tutorial on basic usage of the sprite editor. It explains exactly this. http://youtu.be/3jt8r-KKPkU
Edit: wow, looking back at it, I really need to remake this video tutorial. My previous recording software bugged out, making things too fast and messy.
Heh, nice. I thought of using "directions" as animations, too ^_^ 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.
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.
Either way, I'm gonna get to work on my tutorial.
I also have to say... You've been trying out some not quite conventional stuff that makes me realize that Sphere really needs some new and changed functionality... Hopefully, when TurboSphere and Sphere-SFML are complete, issues like these will be addressed and functionality will be added.
I always push the bounds of any system I use ^_^
I originally got into game programming with Graal Online back in the early 2000s, before they went pay-to-play. That had a C-like scripting system that was so awesome and good, it spoiled me. It had ultra-useful commands like PlayerTouchesMe[Direction], TouchedBy[Entity]. I had to do so little work myself, and got such great results out of it.
Then I got into RPG Maker 2000 and quickly outstretched the limitations of that. Again, so much work was done for me, though, that I got lazy. I got into Game Maker later, but didn't like its closed source.
Actually, funny story, I came across Sphere by complete, utter accident. There's this guy called Musashi who has a website of tabletop RPG and MMORPG-related rants (originally started back in 1995, so it's mostly talking about the original Everquest @_@) and in one article, he mentioned "writing a Sphere shard."
It turns out he was talking about something completely different, some sort of Everquest custom game hosting thing or something, but when I googled "Sphere program editor" I got this.
Sorry to read that the engine isn't quite convenient for some of your purposes right now, though.
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.
Um. I don't see why you wouldn't be able to control four characters at the same time from a single keyboard. Yes, they all come from the same single command queue, but you're pressing different keys for different characters so it's not really an issue. Heck, even several keyboards would work, as long as you set up different keys for different players. Adding controller support for this would also not be difficult.
The main hurdle with having four people on the same keyboard, though, is that most keyboard seem to have a hardware limitation where you can only press 4 to 5 keys at the same time. If you press more keys than that, they're just not sent to the system at all (so this is a problem for any software, any OS, etc). Having multiple keyboards or gamepads could solve this, easy.
For those who are experienced it's not too bad, but I don't know if a newbie can so easily do it. It's not an out-of-the-box thing for Sphere, like single player movement is.
Hmm, a good start I guess:
function Move(name, inputs) {
if (!IsCommandQueueEmpty(name)) return;
if (IsKeyPressed(inputs.up)) QueuePersonCommand(name, COMMAND_MOVE_NORTH, false);
else if (IsKeyPressed(inputs.down)) QueuePersonCommand(name, COMMAND_MOVE_SOUTH, false);
else if (IsKeyPressed(inputs.left)) QueuePersonCommand(name, COMMAND_MOVE_WEST, false);
else if (IsKeyPressed(inputs.right)) QueuePersonCommand(name, COMMAND_MOVE_EAST, false);
}
var inputs = [];
inputs[0] = { up: KEY_UP, down: KEY_DOWN, left: KEY_LEFT, right: KEY_RIGHT };
inputs[1] = { up: KEY_W, down: KEY_S, left: KEY_A, right: KEY_D };
inputs[2] = { up: KEY_U, down: KEY_J, left: KEY_H, right: KEY_K };
inputs[3] = { up: KEY_NUM_8, down: KEY_NUM_2, left: KEY_NUM_4, right: KEY_NUM_6 };
var players = ["player1", "player2", "player3", "player4"];
function Update() {
for (var i = 0; i < players.length; ++i) {
Move(players[i], inputs[i]);
}
}
function game() {
CreatePerson("player1", "player.rss", false);
CreatePerson("player2", "player.rss", false);
CreatePerson("player3", "player.rss", false);
CreatePerson("player4", "player.rss", false);
SetUpdateScript("Update()");
MapEngine("map.rmp", 60);
}
I guess that's the minimum. You'll have to set the people in different places, otherwise they'll be on top of each other. Notice I didn't use AttachInput(), that means triggers won't fire, and NPC's can't be talked to. But there are ways around that. The above is a good start tho.
Whoa, thanks! See, this is always my problem -- I can look at your code there, and open up the API, and I can figure out what's going on. I can understand that code, HOWEVER, I would
never have been able to come up with that code on my own in the first place. I can look and understand and even modify and improve, but I can't generate; I just don't have the mind for it.
But won't using a for-loop lock up the system?
Not that I can't change it. I was messing around in Canvas for awhile, and I figured out a way to print text character-by-character while allowing you to move your player around (ala Chrono Trigger). If you just use a for-loop, when the text starts to print, your character is frozen, and you can't control it again until the text stops printing. But I made a general-purpose iterator that constantly ran in the game loop, and just used it to print the text.
I can easily use that code here. Modified a bit of course, but I actually know how to do it ^_^
Looks like Gauntlet's back on! Thanks