Mbark seems like a worthwhile project. Whether it was widely used or not doesn't really matter, I think your goal of creating a well-designed engine would serve you well for future game development so Mbark is justified simply by those terms. If it turns out other people can use it, so much the better but it shouldn't be something you care too much about.
Right -- I never really had any expectations as far as usage. I originally built it up as an "in-house" tool. Of course, somewhere along the way I figured "why not" and decided I would push it out with a New BSD license tacked on.
Of course, Mbark doesn't really give me the ability to make the kind of game *I* want to make. Although I don't need bleeding-edge performance, I would really like to have a bit more breathing room as far as processing power. Without any sort of hardware acceleration -- coupled with the degree of abstraction involved -- a 3D game, for example, is possible... but it would have to be flat-shaded for any degree of complexity in a scene. Adding texture mapping would slaughter performance on all but the most rudimentary scenes.
Probably would not be so bad if WebGL were an option. For me, it isn't.
Yeah, either way, sacrifices have to be made. I'm just not comfortable with the sacrifices I've been making recently. To be honest, I would be fine with a software renderer, as long as it can perform. I don't need any uber-fancy hardware shader stuff. I just want something capable of decent performance when it comes to 3D rendering (more along the lines of Quake II, and not necessarily UDK).
As far as solutions, I'm not trying to sell myself as some awesome code guru who is capable of "discovering" groundbreaking algorithms or whatnot. I want to make a game, not a tech demo -- nothing I have in mind is particularly earth-shattering... just a pain in the butt finding a way to get there that doesn't make me pull my hair out every 20 minutes.
Switching platforms seems like a fine idea, but you can already see there are difficulties just in choosing a library that will suit you best. With JS there was no choice, so you just had to forge ahead with something that was not perfect. Yet you still ended up getting far enough with it to have a game at some level of completion and a general purpose JS engine. What I'm saying is, trying to make the right choice upfront is sometimes an inferior way to go, compared with just flipping a coin and adjusting along the way. After all, the most enjoyable part of development for me is the actual development. As long as I'm developing, the other stuff can be left to kind of solve itself (or not, as it may turn out).
I mainly got to that level with JS because things pissed me off.
Which is the problem -- my goal isn't to make engines, but to make games. Then again, this is the way things have gone since my VB6 days. I always fiddle around over-engineering crap, picking up the slack others left me with, and end up getting nothing done until I get fed up and seek greener pastures.
I guess until I can either create an engine that does what I want; or, someone conjures up such an engine and makes it available to the public -- I'm stuck in game development limbo.