Community for the Sphere game engine

New? Contact Us to register an account!

Being able to grep my way through the source code to find whatever I want to modify is still probably my favorite thing, and if I wanted to, I could totally edit the source code itself instead of using a plugin to encapsulate a group of changes. All it really needs now is decent documentation for all the source code, so I don't have to grep for words and names of things that sound like what I want to change

Completely necessary and relevant image:

Even then, in Sphere under it's software driver, it never reaches 7fps on large maps. So something tells me that they are using an highly un-optimized high level language like Ruby to do the drawing entirely in software. I couldn't see C/C++ being that slow, unless their algorithms are just plain bad. (No tile caching, animation caching, viewport clipping etc.)

You don't even need to use the Steamworks SDK (see this FAQ), but it's there for you to enhance your game if you do.

Looks awesome, but does Steam even accept RPG Maker games?  Not that VX Ace isn't awesome (discounting that it's long overdue for a resolution bump), but it seems like it might be considered too amateurish for a platform like Steam.  I'm not Valve though, so who knows.

Instead of Flows, though I use GameStates and a GameState Manager. This is how a lot of big indie games are made. There are also scene managers for larger games, but my RadLib library does not have a scene manager (yet). A GameState is similar in concept to your Flow concept. My GameStates in basic form, live on a stack. GameStates are things like menus or even actual gameplay. They are pushed on to the stack when required and then popped off when finished. This organizational detail can be used to great affect. Now, all game states have separated render and update loops. This is critical for two reasons: 1, input only works on the top-most state, and 2, it's not process intensive. However, the render loop runs for all states at all times. Now, you may want to have background states update too and that is also a possibility, they just need to be set to update anyways if not top-most and the GameState Manager will try to detect and run those, but generally this is only useful for pure effect states and not input states.

There are a lot of things like the entry point you can't access. This is a limitation that can hopefully be fixed in newer editions of Sphere. My SphereSFML implements Javascript 1.6 (ECMAScript v5.1), and so has the newer features like Array.forEach and the strict mode.

One thing I hated about sphere is that Load* methods do not return proper JS objects. Even CreatePerson is not an object. It'd be neat to natively have this in Sphere:

Code: (javascript) [Select]

var person = CreatePerson("name", "ss.rss", false);
person.talk = function() {
    Msg.show("Hi! I am " + this.name + " how do you do?");
}

// later...

person.talk();

To do that today you'd have to create your own JS wrappers for such objects. But even then, for LoadImage you were not allowed to extend it in any way. In my SphereSFML, you can extend it since now all resources are proper JS objects.

... wait a minute...

You were Slack0228 (or something like that)? The guy who wanted to create a code editor for Sphere? If so it was you who encouraged me to make a proper Sphere Editor (which you can check out and download). In fact I exclusively use my new editor, have not touched the old editor in a very long time (I only use it if I'm doing something that I hadn't implemented yet).