The name isn't terrible.  Would be cool to see a brief feature list somewhere.

I'm glad to see more people working on foundational ecosystem pieces.  We need a *lot* more of that.

Synthizer is broken in the latest version I believe.

OK, for anyone who's interested, earwax now has a configuration module, so you can write your game settings in a class and have earwax generate a settings page for you.

It's all there in the documentation page.

Ah. That.  You need to be on Python 3.6 or later, and 64 bit.  If either of those isn't true you'll probably get that error.  Also note that if you're on Python 2, Python 2 isn't ever going to be supported by me, and probably isn't supported by Earwax either.

if that's the brokenness @4 is also referring to, sorry, it's known, it's going to take me at least a day to fix, I have bigger fish to fry first.

@9
I know it's an issue, and if you're volunteering to fight the horrifying intersection of CMake and Appveyor which is currently going wrong even though it shouldn't, please feel free to do so.  Otherwise it's 10 minutes or so per attempt at a fix and there's no way to do it on my machine unless I get very lucky.  Given that 32-bit people are rare and that reverb is super super useful it's not priority at this time.

@11
You can almost certainly click some sort of show other options link or something, but are you sure you're not on a 32-bit install of Windows?

Nah, Earwax probably doesn't support Python2 either, and as I'm relying heavily on type hints, it's not going to either.

Here's a direct link to download Python 3.8.5, 64 BIT.

HTH.

So there's something really far down my prototype the things to see if they work list, but an idea I've been playing around with is actually describing maps in code.  For example:

town_square = Box(width=5, height=5, description="The town square")
fountain = EnvironmentalObject(position = town_square.bottom_left + v(3, 3), sound="fountain.ogg")
western_road = Box(width=20, height=1, description="The western road")
western_road.position(town_square.bottom_left + 3*y)

If you do some overloading of Python operators you can get nice vectors and things to work with, you can detect overlaps by just writing a 2d array and seeing if anything tries to set a cell twice, you can do things like verify_reachable(western_road, town_square) that will throw if it's not reachable, etc.  I don't know how far this goes, thus it being on my to prototype list, but writing something like this is intended to be the Synthizer demo/example project.

We need something better than tiles and grid editors, regardless, whether that's solved by you or not.  They work to a point, but there's such a big emphasis on to a point.  Json and yaml and whatever else editing is too rigid--you can do it but yoi have to work out the coordinates in your head.  When I think about even doing something as complicated as Swamp's most basic maps with the kinds of approaches we currently take I die a little inside, let alone doing (say) a proper small town.  With the grids you can either have giant boxes (in which case your roads are cathedrals) or small ones (in which case it's 200x200) and just, there has to be better.  SO, have my idea for better, maybe you'll make something of it.

@17
Suppose that you decide you want to do grid tiles as 1 foot, which is a reasonable-ish choice for anything inside a building, and ironically somewhat better than meters because 1 foot is about 1 footstep.  If I had to estimate, one floor of my apartment building would be something like 100 by 40 tiles, a very large supermarket is probably 200x200 or so, a city block is easily 500x500.  Arrowing over a grid at those sizes is painful, but more to the point it's also kind of incomprehensible without further description like shades of doom has, "You are in isle 5", "There is a passage to your left", etc.  You also have the problem that yeah, ambiance from 10 to 20 x and 5 to 15 y isn't so bad, but what about when it's 273 x to 279 x?  Good luck reasoning that out.  I call this the spreadsheet problem, because it shows up with any sufficiently large grid, whether that be a game map or a data table or whatever else.

But the second problem is, suppose you want to make a row of offices in an office building.  DO that with yaml and you cut/paste it.  Do that with the grid editor and you're there all day.  Do that with a function and a for loop and it's done, plus also you can edit one of them and all 10 update properly.

But again, I haven't done it.  There's drawbacks.  For example I suspect that you end up with environments that look like a bunch of hallways with dead ends, because that's easy to express when you can just main_hallway.north_exit or whatever else and build off  the previous piece.  But I think that the flip side is that if you ever wanted to build an actual, to-scale city or something like that, things that are bigger than what most audiogames end up with, you need something like this.  I've probably alluded toward my end goal being an MMO; one of the key steps in that, for me, is finding out if I' right about whether or not this can work.

There's a lot of other directions you can go, as well.  For example, if you have terrain types, you could make two of those terrain types sidewalk and street.  Then you could let the user define rules for overlapping, the default being error.  But a perfectly reasonable rule to add here is sidewalk + street = crosswalk, sidewalk plus sidewalk mean "corner of main street and 1st avenue" or whatever, and then you can just throw streets down like that and have a well-described neighborhood or what have you.  There's also much more hypothetical things like bringing in constraint solvers (see cassowary for an example) which would, arguably, let you have auto-fitting hallways and things like that too that just always connect two points.

I'm not sure I'd go trying to attach scripts in the map files themselves, though that's not a bad idea, just an implementation problem.  Writing something that compiles code like this to a 2d tile grid is actually really easy, but it's also potentially slow enough that you're going to want to load the map without having to recompile it every time, and if the only way to get the scripts attached to the objects is to build the map, that's kind of a nonstarter.  But you could probably solve this with some sort of stable identifiers an just not rebuilding the tile grid if you see one cached, or something.  I dunno.  My plan for the long term was to use Lua and have separate files, being as the goal is an MMO and you need a trusted language to stop everyone hacking the server when building areas, and also because one file per scripted object that's just object-id.lua is also not really super bad.

There's a lot of ergonomics and usability stuff that needs designing, like how do you specify positions of objects relative to each other, and how do you easily encapsulate things into functions, etc, that I have ideas on but who knows how good those ideas are.

One of the key difference between audiogame maps, both what people have done and what people would like to do, and sighted game maps, is this.  Sighted game maps don't have metadata layers.  This seems kinda like I'm changing the topic, but I'm not: we also need good ways to handle that aspect.  Sighted tile-based game is you drop some road tiles, but audiogame is also you need to be able to say this is 4th street or whatever.  You're also building a GPS system in, basically, with all the GPS stuff.  I don't think anyone's taken that as far as we could.  And on the whole, proposing this kind of thing, I'm really surprised that no one's just said "let's use a programming language and make it nice to use", it's always "My tile editor but better".  I wonder if there's an actual reason for that, I dunno.

In the prototype of a building game I was making a while ago, I designated the map sintax to be composed completely by javascript callables
So the server would expose objects to the javascript parser, and you could do something like the following>
set_name("city")
set_maxx(500)
set_maxy(500)
set_maxz(500)
add_tile(0, 500, 0, 500, 0, 0, "dirt")

The reason I implemented it that way was because I eventually wanted to allow the map tiles to be bound to events, so you could have in game scripting.
I know this is not exactly what you've been talking about, but perhapps, this is something else than lua  that's worth considering?
The library I've used is [
this one

@19
I used to think like that.  I even had ideas on better tile editors.  But I think that the piece that's missing proves to be sight, in the end.

@20
I'm speaking in a programming language agnostic manner, though it is much easier to come  up with something usable if you have operator overloading in my opinion.

@21
I can't use Python.  I'm also not saying you shouldn't.  My plan was to prototype this in Python, then write a better version using Lua for the MMO.  If you're going to run something multiplayer, you can't use Python because Python can't be sandboxed, which means that you had better 100% trust all your builders not to do anything malicious, and that's just not realistic in practice.  But it's easy to prototype in Python, and if you're not going to be doing an MMO where builders upload directly then it's fine.

I don't know what you want from ambiances.  When I hear ambiance, I think music or background wildlife soundtrack that's just a stereo file. If you want to specifically place them you could do that, but in practice even fixed ambiances are going to need things like occlusion if they're not always just going to suggest an open passage, and somehow you have to get from the mono, panned version to the stereo version when the player enters the area.

I'm not sure that this raises the entrypoint.  In practice, people who don't know how to code can treat it like a data file and just ignore all the coding features that are available to them.  I think that the other open questions with doing something like this are more important than that.

Regardless of whoever tries it first, my interest at the moment is finding out if it's workable.  I expect that there'll be some sort of prototype V1 that determines that and then gets left behind, and a better V2 that people actually like using.

I'll leave packaging decisions up to you.

No one ever thinks to give tools to create interesting features, it's just enter numbers. That's fine, it can be done, but really why do it that way when literally every game since games allowed you to build things lets you do it through use of painting tiles on or dragging out lines and boxes.

Games like Transport Tycoon allow you to drag out your road system. Others like Sim City let you make whole entire zones with one box. The road system is ghost imaged onto the map as you drag, then you release and it is cemented. The construction workers come in and you see it built realtime.

But really, what's missing is the power to make large scale changes quickly by letting us make selections and have tools that fill them in with whatever it is you want to build. Also the example given in a previous post about looping through to make parallel hallways or whatever that way ( read it last night ) can easily be done with a copy or duplicate option.

Let's say I wanted to make four parallel hallways and then join them together with another section of corridor that runs at a 90 degree angle with them at one end. The workflow could look something like this. Cursor over to where you want the first hall to start, then hold shift and move the arrows to drag out a rectangle. You can tap or hold, and each time the selection changes, a small click can be heard which indicates this. Let go of shift once the height and width match what you want them to be, or tap control to have the whole thing canceled and start again. Once you've got your first box, there should be a command to mark it for duplication, use it, then move back to the start of it and use either up or down arrows to select a point vertically and hit the key that performs the duplication. Repeat until you have four in total, then go to the end of one of them and make a box back to the first. Since it passes through each of them, it now connects them.

This is why I do not think making good map requires coding. Of course, it's an option for those who want to do that, but if the right tools were developed, you would be able to mock up your map in short order with minimal effort.