Dramatics. Wow. I'm guessing I struck a nerve somewhere. Probably my mention of Unity. I'm sure you get that a lot.
Personally though, I'm not a supporter of Unity for 2D game development over GM -- I simply think their team has a better ability to listen to what their customers want -- and then deliver -- much more than YoYo games seems to have. As a representative of Yoyo Games, your tone in your response to me just proves my first point that your ability to listen isn't the best, and the fact that we've been waiting so long for such critical features as a modern room editor so long that multiple freeware programs easily top its ability to provide common features which, in that timeframe, have become standardized and almost necessary for today's market viability, proves my second point that you guys' failed to truly deliver to your users.
After all, if you were truly *listening* to me, your customer, you would have heard that my own tone was a reflection of how painful and frustrating it is to have had high-hopes for you guys' taking over GM and giving it the chance to have the treatment it deserved that would bring it into the realm of becoming an easy to use, professional, game development tool -- time and attention that Mark Overmars couldn't give it all by himself -- only to see one of its most critical features seem to be sidelined for the sake of continuously developing things that only helped your company's bottom-line.
If all you had to do is rewrite the way GM stores and displays its sprites/tiles in order to provide fast/scalable/rotatable/colorable/zdepthsimulated/etc/etc. sprites and tiles, why wasn't that on the top of the list after writing the compiler?? Imagine how many games have been created with this program that are just sluggish and resource-intensive, and even unplayable on certain hardware, that can run other stuff -- even 3d -- just fine. That makes the developer look bad -- not just YoYo Games -- and we developers are looking to *you* to fix that. :/
Getting back to the topic-on-hand, so-called "proper tile maps" wasn't what I was saying should be added. I'm highly aware that GM's current "tiles" aren't "proper tilemaps -- I've programmed them myself inside GM just to have them and I'm aware they're just two polygons drawn with UV coordinates mapped to them from an image -- it's common knowledge if you're at all familiar with 3d graphics 'sprite' drawing capabilities -- and I was around, following GM closely, when Mark implemented them -- so don't talk down to me.
Yeah the current room editor sucks. It has for a number of years now. I haven't seen any solid plans for a rewrite until I saw that post on the blog mentioning GM9's "proper tile map" features like they were some modern marvel of technology. Sorry, but "proper tile maps - where they are regular grids" is NOT the sort of features I'm talking about needing from GM. It's the exact opposite -- "proper tile maps" are old technology that can't keep up with the changing market demands in graphics because of the sheer amount of work it is, even for a skilled artist, to make them do most effectively what every skilled pixel artist aims to do best -- "eliminate the grid". By bringing GM9 back to the 80's with your "proper tile maps", you are working against us and doing the exact-opposite of that goal by enforcing the grid -- don't you see??
What modern artists nowadays need is something *very-much* like this:
http://vimeo.com/2769377
Apparently you didn't fully read my post because I posted that link to that video along with my original post (before calling out YoYo Games, mind you, so it's understandable if you missed it) but listening fully would have explained more clearly - with visuals - as to what I was referring to regarding the ""tile"" system revamp. It would also show you *exactly* where to start with a rewrite -- and you likely would NOT have to throw everything away. After all, most people make grid-based games nowadays only because they feel they *have* to -- C# and Javascript (combined with 3d terminoligy in the case of Unity) is generally overwhelming for non-programmer types -- and pixel art isn't an easy skill to pick up -- so, when even skilled digital painting professionals have a difficult time learning pixel art from the ground up with professional training in pixel art, and I speak from experience in teaching these people, you can't expect people making games for the first time to manage prettiness without giving them the tools to do so easily -- especially when they're non-programmer-types. Learning pixel art just to make games is ridiculous, and oftentimes people making games don't know what else to do because they have Photoshop but are unsure how to translate their drawing/painting skills in order to be able to make assets for their game. People don't want to have to learn pixel art in order to do that anymore. They just want to make games. That's the reason other 2D software like Construct2 and Unity are still valid for 2d games when compared to Game Maker -- they allow you to hand-draw your level graphics as chunks at a high-res and easily throw those individual chunks into the engine to be positioned/rotated/scaled/colored/tinted/mirrored/etc.-- all *arbitrarily* --- however the artist wishes until he gets his levels looking nice in the preview area -- but the cost with Unity or Construct2 is a steep learning curve and/or limited functionality.
Hopefully you've read enough of that to know I'm talking about scaling and rotating large *individual* what GM currently calls """tiles""" drawn at a high-resolution and placed with some faded edges or darkened periodically to help with the appearance of seamlessness. I could give two sh*ts about the low-to-high-res scaling/blur issues that GM currently has right now because there are ways around that. The reason many people have that problem in the first place is because they secretly want to make a high-res game like people using Unity and their ilk so that their games can keep up in the marketplace, but just don't understand the techniques behind it and don't want to go learn another programming language to do so when they inevitibly hit GM's creative walls with its poor handling of the room editor in regards to this sort of graphically-oriented-creativity stuff.
You may not be afraid of Unity stealing your sales -- but I can assure you they are slowly eating away at your market due to the lack of these critical features, and the more you stagnate, the more they will catch up to you. And they've already caught up quite a bit more than you'll let yourself believe. GM9 boasts a "proper tile map" system, but it doesn't sell the idea to me, or any other people looking to use your platform in order to shine professionally -- only the cheap-copycat developers looking to make a quick cash-in on maze games while installing malware and making money from ads want it because it's easy to program on.
If you want professional users -- GM must stay on the edge of technology. Just because GM is a 2d-platform doesn't give you a good excuse to just sit back and let the win roll in from Mark's design while your users look at people on other more modern platforms kicking-ass and making sales with their games, periodically looking back at what they're working with and asking themselves "Is this really the right option for me?? Should I just bite the bullet and just learn Unity/Construct/whateverElseModernDevPackage so my games will look better?"
Just some food for thought -- and hopefully your hubris will let you think about it so that Game Maker doesn't fail because of your false self-confidence. As mean and stupid as you apparently think I am, these hard truths are for your benefit, not mine.
As a Final Note:
I really do urge you to look at the the videos in this post (and download the source-code mentioned again below to run the binary in the "Release" folder to see it in action for yourself) -- and also look up the Gamasutra article for the Braid level editor -- Braid is also an indie game with a similar level editor to the one in my previous link -- because all of these things are solid ideas on how to approach your ""tiles"" as they are now -- and give users the OPTION *later* to use the fancy "proper tile map - where they are regular grids" in the future to work *alongside* this type of tile system. GM can currently do this sort of thing right now if the underlying functions were simply exposed in the current room editor. Also keep an eye on the per-layer z-depth-simulation of the tiles there that I mentioned in a previous message when you look at that video -- it's a pretty nice-looking feature for demoing parallaxing instead of programming it in yourself (another very basic non-game-dependent feature we shoud not have to program ourselves in this day and age).
You should also take a peek at the video mentioned below too regarding the polygonal-mesh generated from a sprite for collisions using simple 2d raycasts -- Unity really does have the right idea here. That alone is a feature many people will love you for if it were added in Game Maker.
As far as a new ""tile"" system -- I'm referring to simply using the 3d polygon planes as you currently use for drawing your ""tiles"" to make this happen (even if these eventually became just sprites / simple objects like you suggest you'd need to implement your "proper tile map" editor, these could still be just special tile map types that can be individually scaled/rotated/mirrored/colored/tinted/etc., as long as they offered something akin to that z-depth-simulation shown in that tile-editor video, we'd be all be happy since these features are needed so badly by so many users it's not even funny.
That aside, GM might be relatively new to YoYo Games Ltd, but other people (like your loyal users) are starting to look at it as a bit dated. Users who remain here are simply waiting for the kinds of visual-editor features other development-platforms have (and for their favorite development platform to catch-up), and most of these very simple features (that we should NOT have to wait any longer for) are shown in the two videos below. You put those in, and your sales will explode.