I've got a very simple prototype build and basic map together as a very early initial prototype.

I had originally wanted to try using MonoGame & Nez as the development platform for this for no reason other than I just wanted to try it out - I'd tinkered with the managed libraries for DirectX & C# many years ago, and wanted to see where things were now (especially since I learnt that Stardew Valley was built using MonoGame).  I ran into a lot of problems getting things up and running though with MonoGame + Nez - things seemed to work when I followed the very simple examples, but as soon as I started refactoring the code to make things cleaner (e.g. not having everything in Game.cs etc) things started to rapidly fall apart with obscure errors deep inside Nez.  I spent a little bit of time tinkering around and trying to debug things but in the end it was pretty frustrating chasing ghosts that disappeared when you put all your logic into a single "god class".  It was a shame as Nez had some really nice looking built-in things that would have been perfect (namely Tiled map import and GOAP AI).

So I turned to Unity.

Originally I was planning to use Tiled as the map editor, but I struggled to get the SuperTiled2Unity package to import my map correctly - for whatever reason I just could not get the collision data to work despite my map being set up almost identically to the example one.  SuperTiled2Unity is still extremely young at the moment so perhaps I was expecting too much from it at this stage (and I did not want to use the old deprecated package).

So instead I set things up in Unity using their in-built 2D tile editing tools.  Long story short, after a lot of mistakes I learnt a lot about the "correct" workflows for doing tile maps in Unity at the moment - the summary is do not use a sprite sheet for your tile map's sprites since there does not currently seem to be a way to easily "replace" the existing sprite sheet with an updated one without losing your entire map!  This happened at least once, leaving a weird reddish-smudge where my map used to be.  Instead it seems best to import tiles as sprites individually and then you can update individual tiles in the tile palette one-by-one as you need to (e.g. adding new tiles or changing existing ones).

In the end I was pretty happy with the results - I've got a basic map that looks & feels pretty much like the original area you first encounter, simple movement and collision detection - there are even the "signs" that give you some descriptions, but there is no UI for that yet (just logging to console in Unity for now).  Unity really does make this very easy, but I find their (and the community's) penchant for hour-long YouTube videos explaining how to do things to be really quite infuriating  and would much prefer to see more textual tutorials so I can scan through to the bit I am struggling with quickly rather than having to fish through a video and listen to someone talking).

Anyway, some good progress and there is even a simple WebGL demo running on this site now (although at the moment it is extremely jittery - it runs perfectly smoothly as a proper binary).  Next up I plan to look into adding the laser-doors.  This will be interesting since I will need to find a way to animate the door sprites.