Reinventing the wheel is nice when you're learning, but reinventing the wheel when there's already a well known existing solution and you're trying to get people to use your solution instead... well that's most likely a waste of time.
I'm not trying to make you feel bad. But I've seen a lot of "engines"/frameworks started here, and months later they are no longer in development. If you're making it for yourself, great! But don't expect other people to take up your solution when there's already *hugely* popular frameworks out there that have been solving problems for years. If your goal here is to get people to use your framework then I would advise you to get a team together and really hammer out a lot of solid features. Otherwise I wouldn't bother.
Efficiency is king when it comes to development, why would anyone decide to learn an entirely new framework that may not support all the features they used in their old framework? I think most game developers would rather stick with their tools that they already know work, that way they can just focus on making their games. I think part of what you don't understand is that a lot of us have tried to create their own game frameworks. Some of us were successful, a lot of us weren't. But I think in the end most of us learned that they're just for personal use, not to try to get others to use. We *do* have the experience, and a lot of us are trying to help you so you don't stumble before you can take off running (making games). I think everyone here would love to see you make a popular framework or game which is why we are trying to guide you. Every head strong "newbie" that has come through here (you're definitely not the first) always goes down the same route you're going. A couple of them have gone on to work on some really cool projects after they realize they're wasting their time with the whole "try my framework" thing. The ones who didn't realize that might be working on cool projects now too, but it took them longer to get to that goal. If you would seriously just sit down and listen to what some of us have to say you would learn a lot, and it might set you up for success earlier.
I already hate the current coding style we do. You have a main function then hundreds of sets of functions that are called once or twice. So called, "helper functions." I don't really think that is digressing, but you see my point.
What do you even mean by this? Condensing code isn't always the answer, sometimes sprawling code bases are necessary to keep code efficient and re-usable. Trying to force everything into huge functions is exactly what leads to what you're complaining about; unnecessary labyrinths. Not to mention, functions are self documenting when used correctly. Reasonably splitting up code into smaller functions that are properly named and have just the right scope makes code infinitely more readable. Sometimes it's necessary to have a function that is maybe only called once or twice, and I think knowing when to do that is part of moving forward as a programmer. Design is just as important as the actual code you write otherwise you're going to end up writing some pretty god awful spaghetti code.
For the love of god, don't pick apart my response to try to prove me wrong. Read some of the posts your peers here have taken the time to write out to you and really consider them instead of just tossing them aside because they might hurt your feelings a little bit. There are some brilliant people here you could learn a lot from, and not just about game design but about development as a whole. I haven't worked on a game project in years now, but I learned a lot about development and now I'm a professional software developer. I can attribute part of my "success" to some of the users here. Open your mind and seriously consider what people have to say, that's all I'm really asking you to do.