So... We all know that Sphere is a great game development tool.

And with forthcoming changes it's going to get even better:
- Fat Cerberus is working on high speed JS with chakracore
-> once CC works there's a possibility of full type script support via Cell with CC which could be attractive to some people
- there's already basic 3d support (though i think it may need some fine tuning)
- there are the v2 map/sprite engines I'm working on (including tiled support)
- with a decent tutorial for it the dataReader script from Fat Cerberus can load any basically data type you care to design
- there's the possibility of a web based implementation, Oozaru (though this is a little way off at the moment)
- there's the possibility of Android support from Eggbert.

What does it not have?
- There's no good 0 to everything tutorial or outline anywhere.
- There are very few great demos of what it can do, probably Trial and Error 4 beta and Aquatis Journey to Kiltos are the best we've got
- It doesn't have many active users talking about what they're using it for

How do we fix this?
1. I think the first few things on the improvements list should get finished before we do anything else as they could have some significant impacts on the best way to use Sphere
2. I think we want a 0 to working game tutorial using v2, possibly more than one such to cover a few different game types
3. Accompanying tech demos to go with the above
4. Consider where to share such materials (rpgmaker.net is one obvious place) but is there anywhere else that would be good?

Thoughts? Opinions? Volunteers?

There's no good 0 to everything tutorial or outline anywhere.

The new Getting Started was a start to fixing this, but it goes from 0 to basic, not from 0 to everything. I'd like to have more articles up on the wiki, especially now that miniSphere is quite usable and that much better compared to the v1 API.
Anyway, I very much agree that we need a bigger tutorial.

- There are very few great demos of what it can do, probably Trial and Error 4 beta and Aquatis Journey to Kiltos are the best we've got

Interestingly, once you start digging, there are a lot of interesting Sphere games out there. I kept posting games made with Sphere on the Twitter for a while and had set it to post one a day but then I ran out of free time/interest to create posts for the big list I have of Sphere projects I want to promote. (Big list is here: https://pastebin.com/PzBR0jWT)

Honestly, I want to be more active on social media in general to create more of a presence for both Sphere as an engine and Spherical as a community, as a lot of people can be found specifically on social media these days. Especially Twitter has some potential to pique the interest of game devs. Some specific groups like the Game Dev Facebook group would be a good place too, if any game made with Sphere finds its way in places like those. RPGMaker.net is also a good place, that's where I found a lot of the more interesting/complete Sphere games to begin with.

I've been thinking of starting a thread on another forum unrelated to programming or gaming (though the latter sometimes comes up) encouraging people to try out miniSphere and get them interested in programming. There are some people with artistic talent and others with musical talent, so hopefully we'll get at least a couple newcomers soon.

Sounds good to me. Anywhere where promoting Sphere seems appropriate, go for it.

I think marketing sphere with some kind of notable game, released on steam, would make a lot of sense.  So, some kind of library to support steam achievements (maybe some other platforms) would do a lot to tell indies that sphere is a viable engine to make and release a game.  Once there's attention, that's when good tutorials become really important.

I have been considering a steam release for The Rainis Manuscript.  First I have to finish rewriting the dialog and adding the new scenes, then finish tweaking the new battle engine, then get it working in miniSphere (currently with 1.5 it crashes quite a bit due to what I *think* are segmentation faults, but I haven't looked into the actual error), then consider adding in other features like multiplayer networking, QA and finally release.  Over the past year it's become a lot more compelling, and I'm more excited about it now than I have ever been before.  While there are no modifications needed to release on steam itself, having support for achievements in particular would certainly be nice, even if it's just some kind of external library interface.

I know other indies would be interested in trying out new engines and technologies at game jams when they hear about someone else using it, and at least one person I know was interested in trying it out after seeing me use it at TOJam for the past 9 years (though probably more half-heartedly since he's really used to making games in unity).

Over the past year it's become a lot more compelling, and I'm more excited about it now than I have ever been before.

If you're referring to miniSphere with this, it's about to get even more exciting, as I'm switching to ChakraCore--a modern JS engine with JIT (so performance blows Sphere 1.5 completely out of the water) and native support for pretty much all of ES6 including modules.  With that, combined with already having a real command-line debugger and scriptable build engine, miniSphere is a true modern implementation of Sphere.

Re: Steam integration: This is one of the things I was really interested in implementing back during the early months of the project.  I should probably look into it again.

Steam integration has been often on my mind. So I'm all in for that idea.

I also like the idea of Steam integration. Does miniSphere support external JS modules? I kinda remember one engine doing that at some point, and it would come in perfect when it comes to something like Steam integration.

Not sure what you mean by external modules?  Like being able to load native code?  Plugins?

Yeah, something like plugins. Maybe it was TurboSphere that did that?

Yeah, TurboSphere.  I experimented with implementing it at one point about a year or so ago (around the time I added support for require()) but ultimately decided evolving the engine in other ways was more important.  That seems to be paying off now

If you're referring to miniSphere with this, it's about to get even more exciting, as I'm switching to ChakraCore--a modern JS engine with JIT (so performance blows Sphere 1.5 completely out of the water) and native support for pretty much all of ES6 including modules.

I was referring to TRM instead.  In terms of engine updates, there hasn't been much added since 1.0 that I've needed (a few features here and there but not a lot).  The main benefit of upgrading versions, especially for TRM has been to use an engine that's stable under current operating systems and allocates enough memory to the JS heap to allow the scripts to run (TRM was dead for a while between 1.101984-1.2 [I think, whatever the last crazy version number was] because of this).  Performance hasn't been that important since TRM was initially designed to run on Pentium 2 era machines (300-500mhz), and for the type of stuff I'm interested in doing (mostly pure pixel art, fairly low res), the engine has been fast enough for quite some time.  While performance issues can always (well, usually*) be worked around by being creative, it's the hard limit stuff like the draw order of map sprites (RTD:E**), bugs because of newer OSes, or something like steam integration that is exciting to me.

But getting back the main topic.  A lot of people seem interested in that steam integration, I guess because even if one doesn't really want to commercialize their game, the possibility of doing so is appealing, especially to someone starting out.  Besides that, are there other things that a fully commercialized game should have?  For instance, in Sphere-v1 (I haven't looked deeply into miniSphere yet), while you can change the resolution mid-game, you can't change the graphic drivers, which means you would have to make your own prelauncher to do something like that since most games don't expect you to go to the install folder (or the program files menu) and run a different .exe to change configuration - you just click play in steam or on the desktop icon and then change it in the prelauncher or the game itself.


(*) RTD:E needed to use its own build of sphere to get around the fact that GetPerson calls were being mapped from the person's name to the person_id number via an array lookup.  That's fine for a low number of sprites, but for updating a large number of sprites at once (for example, gore globs or large number of enemies) would quickly slow down with increased numbers of persons on the map.  Rouge Rogue Rabbit Puncher also had this problem, but only after defeating the mid-boss.

(**) The draw order of the sprites on each layer was determined by sorting the y-position of the sprites in vanilla sphere.  This is reasonable for an rpg, but for a platformer where a lot of sprites are on the same y-value and can overlap, it makes a lot less sense when you start seeing the sprites glitch in front and behind each other, so RTD:E set the order to be fixed instead.  By now, it may be reasonable to implement pure js map engines, which would make patching something like yourself this just a matter of loading the js library and overriding some functions instead of asking for a feature request/building the engine yourself.

Right, that's the main benefit to having a fast JS engine, you can implement all the high-level stuff like map engines, etc. in JavaScript.  Sphere 1.5 uses a veritably *ancient* SpiderMonkey version (2003) and it's just not up to the task of running a full JS map engine.

Sphere 1.5 having a built-in map engine written in C++ is a big part of what's given it as much staying power as it has.  Almost all the heavy lifting is done by the engine, so if all you're doing is map-based stuff the slow JS performance isn't a bottleneck.  Once you do anything really code-heavy though, like my Spectacles battle engine, or @Rhuan's map engine, the poor performance of interpreted JS really starts to hurt.

Regarding that resolution switch: I was under the impression you couldn't do that in Sphere 1.x without actually forcibly rewriting the .sgm file and then calling RestartGame()?  miniSphere lets you just do screen.resize(w, h) but I didn't think there was an equivalent function in the Sphere v1 API.

Regarding that resolution switch: I was under the impression you couldn't do that in Sphere 1.x without actually forcibly rewriting the .sgm file and then calling RestartGame()?

Yep, that's called changing resolution mid-game in 1.x.  Also works to limit heap size growth if that's an issue for you and it's 2005.

Doesn't work for changing the graphics driver though.

Well, that "mid-game" part is maybe kind of a stretch since you lose all current state, and end up having to write even more code to save the state of the game and restore it after restarting (and the way the 1.x map engine is engineered sometimes makes that a challenge).  But yeah, I didn't realize that's what you were referring to, thought you knew of a secret API function I didn't know about