So I've been thinking of starting a beat 'em up engine in Sphere, with the functionality to write multiple different games with different functionality in it. I'm going to use The Simpsons Arcade, since it has a lot of common features of other arcade beat 'em ups, and some that they don't have, allowing for more options.

A nice thing about it I think it would likely be able to use a lot of Sphere's tools, like the map engine (with some stuff for jumping and jumping collision), collision boxes, and character sprites and different sprite animations, like jumping, attacking, etc

What do you guys think? Do you think this would be a good idea, or feasible given the Sphere map engine (with some extra coded functionality? I'd start by replicating the Simpson's Arcade Game as much as I can, and then working on other games, making sure it's possible for it to be portable and flexible, without it being a SAG clone.


For those of you who haven't played TSAG, it's a fantastic arcade game, one of the best, and is a great standard for what beat 'em ups should be, which is the reason I'm using it for a base.

Eggbert, that's a neat idea! Though I will caution, engines like these need to be easy to use and extensible in very user-friendly ways. I myself may have programmed in JS for years, but I learnt it wrong, all wrong.

JavaScript is a wily language. I'd read up on it's plentiful Design Patterns since they may use JS syntax unlike you've seen it before.

I should also say that, uniquely, we are at a position in which you don't need to use the default Map Engine anymore. If you can code the game outside of it, then the better it may turn out to be (and the more 'portable' it becomes).

Eggbert, that's a neat idea! Though I will caution, engines like these need to be easy to use and extensible in very user-friendly ways. I myself may have programmed in JS for years, but I learnt it wrong, all wrong.

Of course. My goal is to make it portable, compatible with elements from different engines, not just the Simpson's, but at the same time, fairly easy to use. And what do you mean you learned it wrong?

JavaScript is a wily language. I'd read up on it's plentiful Design Patterns since they may use JS syntax unlike you've seen it before.

Yeah. I can't find it, but I remember reading an article about all of the weird conventions that it can do, like inconsistent adding of strings and integers, and other silly things.

I should also say that, uniquely, we are at a position in which you don't need to use the default Map Engine anymore. If you can code the game outside of it, then the better it may turn out to be (and the more 'portable' it becomes).

The reason I'm using the map engine is because it's part of the reason it would make things easy to code in Sphere. It has tiles, sprites, event handling, and other goodies that would be difficult to set up in other things. Why reinvent the wheel when you've already got a fairly good one?

Though one issue I can imagine might come up: Arcade beat 'em up levels can be fairly large, even before transitioning to new ones (like downtown to Discount Graveyard). Is there an easy way to have the engine load a new map without any pauses, jumps or anythin like that, keeping the players and enemies in the same locations?

And what do you mean you learned it wrong?

Well I started learning it in 2004/5 and since I was mostly self-taught my first code was bad, but then I learned about it's prototype model and started using it better, but then I learned about those Design Patterns and that's how good JS should look. It's hard to explain, but while there is no 'correct' way to use the language there are ways in which if you use it, you kind of shoot yourself in the foot later and I've learned to try and not do that.

The reason I'm using the map engine is because it's part of the reason it would make things easy to code in Sphere. It has tiles, sprites, event handling, and other goodies that would be difficult to set up in other things. Why reinvent the wheel when you've already got a fairly good one?

Makes sense, but you'll run into a few limitations.

Though one issue I can imagine might come up: Arcade beat 'em up levels can be fairly large, even before transitioning to new ones (like downtown to Discount Graveyard). Is there an easy way to have the engine load a new map without any pauses, jumps or anythin like that, keeping the players and enemies in the same locations?

Like this.

There is a way you can fake it by using RenderMap() and GrabImage() as you go through transition-zones between each map, but it takes careful camera trickery to make it seamless. In Pokemon games people had even resorted to physically cloning the borders of each map to go between "cells".

In more modern Sphere implementations like FJ's or mine you should be able to load in maps, string them together, or load them in part or in whole. FJ would have made a completely in-script version so you could technically tear it apart and completely modify it with minimal effort or with the case of my engine, load any number of maps and draw them wherever on screen. I made that feature for games like yours or Pokémon games that may have a giant gameworld physically built of many smaller maps.