Skip to main content
↑
↓
Spherical forums
Community for the
Sphere game engine
New?
Contact Us
to register an account!
1 Hour
1 Day
1 Week
1 Month
Forever
Community
Help
Search
Recent Posts
Log in
Contact Us
News
Spherical
Facebook
-
Twitter
-
Discord chat
New?
Contact us
to register an account!
Sphere Development
Sphere General
Future of Sphere: New map engine
1
Print
Topic: Future of Sphere: New map engine
(Read 4242 times)
previous topic
-
next topic
0 Members and 1 Guest are viewing this topic.
Fat Cerberus
Big Chungus
Posts: 2,774
*MUNCH*
Logged
Global Moderator
Sphere Developer
Future of Sphere: New map engine
June 01, 2016, 11:39:08 pm
The default Sphere map engine, even with the enhancements made to it in minisphere, is beginning to get a bit long in the tooth. It's not object-oriented, and extending it often requires awkward hacks.
I would like to introduce a new map engine with minisphere 4.0, one coded in JavaScript from the ground up which is designed from the start to be extensible but nonetheless includes a great deal of functionality out of the box (in order not to sacrifice Sphere's biggest strength of being easy to pick up and start programming). So I'm posting this thread to gather ideas and see what people would like to see in a map engine.
neoSphere 5.9.2
-
neoSphere
engine -
Cell
compiler -
SSj
debugger
forum thread
|
on GitHub
N E O
Hero Poster
Posts: 585
Making it happen!
Logged
Administrator
Senior Administrator
Re: Future of Sphere: New map engine
Reply #1
–
June 02, 2016, 02:08:17 pm
I'm in favor, though I do have some concerns.
Let's assume that there will be some ability to convert, either implicitly or explicitly, Tiled-format maps to Sphere or otherwise write in treating Tiled as native somehow. How do we handle things like per-tile obstructions (especially if we implement a thing like entrance/exit obstructions), possible terraforming, and such if the format ends up so wildly different in implementation than the original Sphere map format? Do we attempt wrappers or bridges, or do we force Tiled hexagonal pegs to fit into Sphere's square holes?
What will be the approach, and how much of it will be C/C++, how much in script?
Fat Cerberus
Big Chungus
Posts: 2,774
*MUNCH*
Logged
Global Moderator
Sphere Developer
Re: Future of Sphere: New map engine
Reply #2
–
June 03, 2016, 02:10:22 am
Theoretically, the whole thing can be done in script, provided the engine has sufficient API surface area to do so--and thanks to things like Galileo and the FileStream API it should. Responsibility for loading resources like spritesets, tilesets, etc. can also easily be moved to script since deep down they're just collections of images.
As for Tiled, your point is well taken, and is one of the big reasons Tiled support hasn't made it into a release yet: It supports all different kinds of tile shapes, customizable render order, etc. that I would either need to support or just take a hardline and say "Nope, you can't use that feature, sorry". For some features this is reasonable: Few would complain if we said we don't support hexagonal maps, but on the other hand placing restrictions on more superficial things like render order (to, say, RightDown-only) to ease implementation might come off as somewhat arbitrary. So it's a fine tightrope to walk.
As for terraforming, it was my understanding that that's something typically handled by the map
editor
, not the engine?
An alternative to Tiled support directly in the map engine would be to implement a converter in, say, Cell, which converted Tiled maps to a more Sphere-friendly format. If we do it that way, then any restrictions on which Tiled features are supported might be a bit easier to swallow--the compiler would tell you ahead of time your map is unsupported, rather than not finding out until the game actually tries to load it.
neoSphere 5.9.2
-
neoSphere
engine -
Cell
compiler -
SSj
debugger
forum thread
|
on GitHub
1
Print
Sphere Development
Sphere General
Future of Sphere: New map engine