Spherical forums Community for the Sphere game engine

New? Contact Us to register an account!

So I'm trying to make the change from the old sphere to miniSphere, but I'm old, I hate change and somethings frustrate me to the ends of the earth.

Anyways, I think it's a bug, I'm using miniSphere 5.3, and working off a blank tileset and editing it as I go. I frequently load up the game to see how things look and try to see proportions of the surroundings. The problem is that in the editor it updated to the newest iteration, but when i test the game it defaults to an old version. I've tried closing the map, and the project itself.

The top part is cropped from the editor, while the part below is being ran from the engine.

Is there something I'm missing?

This sounds pretty much like the first few text-based games I ever wrote in QBasic.  Variables?  Functions?  What are they?  It was pretty much just a long string of IF..THEN and GOTO for each relevant input

Of course mine weren't roguelikes.  To code a whole roguelike like that... that's impressive.

The first proof of concept of Oozaru is up (running the Spectacles battle engine), check it out:

• https://fatcerberus.github.io

Consider this Alpha 1.  I won't call it a beta, since it's not quite feature-complete yet; sizeable portions of the Sphere v2 API are completely missing and/or inoperable.  Like, the Joystick class exists, but all methods are no-ops.  And almost the entire FS API is missing... that kind of thing.

Thanks for the tutorial. I reciprocate by giving you a link to Uncle Bob. I love his perspective about "new" programming paradigms. Don't want to give too much away, here it is:
https://www.youtube.com/watch?v=ecIWPzGEbFc

And yeah, as a dinosaur, he knows Monads too and has a clojure perspective:

Here are the slides of the presentation:
https://github.com/unclebob/WTFisaMonad/blob/master/Monads.pdf

And... ah, here it is, the presentation itself:
https://www.youtube.com/watch?v=Usxf3aLimtU


don't fall asleep now   (yeah, they are long but fun, for a certain type of programmers fun)

Well, I mean, I do expect people reading a monad tutorial to have existing programming background, that goes without saying.  I will say that I think imperative programmers are better equipped to understand them than functional programmers actually, since we're the ones writing all the boilerplate in the first place.  Think of your Link.js library and the problem it solves

Programmer-to-programmer: the thing is, the monad concept itself is not actually complicated, people just make it seem that way - sure, individual monad types are complex (promises, e.g.), but the monad interface is ridiculously simple:

// entangle/unit/pure/return
let arr = Array.of(1, 2, 3);
let m = new Maybe("foo");
let prom = Promise.resolve(812);

// map
arr = arr.map(x => x * 2);  // we know what this does
m = m.map(s => s + "bar");  // maybe it has a value, maybe not - it's a no-op if not
prom = prom.then(value => newValue);  // just map to new value, no async shenanigans

// flatmap/chain/bind/thru
prom.then(result => new Promise(...));  // promise chaining
m.thru(value => new Maybe(result)); /* alternatively, Maybe.Empty */);  // maybe it can fail
arr.flatMap(elem => Array.of(...));  // one-to-many mapping

That's it.  If you implement that interface and satisfy the identity laws, it's a monad.  Literally.  That's all that's required.  It doesn't matter what kind of abstraction it's an interface *to* (promises, arrays, maybes, eaty pigs...), you just need to implement the interface.  The main thing is that the pattern this interface represents already exists in "nature"--you have to train yourself to recognize it though, and that's the actual hard part.